Comment 2 for bug 988601

> However, since this code has only been tested on Windows I
> cannot exclude the possibility that it might do something
> untoward on another platform.

Testing 'multiple.patch' on OS X 10.7.2 Lion (64bit, llvm-gcc-4.2, debug build) against r11296:

1) patch does not apply: 'newfile' is created in topdir and overwritten for each newly added file

$ patch -p0 --dry-run < ../../_patch/todo/988601-emf-omnibus-multiple.patch
patching file ./build.xml
patching file ./src/CMakeLists.txt
patching file ./src/extension/internal/emf-win32-inout.cpp
patching file ./src/extension/internal/emf-win32-print.cpp
patching file ./src/extension/internal/emf-win32-print.h
patching file ./src/libnrtype/Layout-TNG-Output.cpp
patching file ./src/Makefile.am
(Stripping trailing CRs from patch.)
patching file newfile
(Stripping trailing CRs from patch.)
patching file newfile
(Stripping trailing CRs from patch.)
patching file newfile
(Stripping trailing CRs from patch.)
patching file newfile
(Stripping trailing CRs from patch.)
patching file newfile
patching file newfile
$

2) working around issue 1, 'make' fails due to error in 'src/Makefile.am':

automake-1.11: cannot open < src/libunicode-convert/libunicode-convert: No such file or directory
make[2]: *** [../../src/Makefile.in] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

3) after fixing issue 2 (typo in 'src/Makefile.am'), 'make' fails with this error:

src/libunicode-convert/Makefile_insert:8: bad characters in variable name `libunicode-convert_libunicode-convert_a_SOURCES'
src/Makefile.am:131: `src/libunicode-convert/Makefile_insert' included from here
src/libunicode-convert/Makefile_insert:8: variable `libunicode-convert_libunicode-convert_a_SOURCES' is defined but no program or
src/libunicode-convert/Makefile_insert:8: library has `libunicode-convert_libunicode-convert_a' as canonical name (possible typo)
src/Makefile.am:131: `src/libunicode-convert/Makefile_insert' included from here
make[2]: *** [../../src/Makefile.in] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

No idea how to correctly address this: I did manage to get 'make' succeed by renaming all instances (file names and references) of 'libunicode-convert' to 'libunicodeconvert', but I don't know if that's the appropriate fix, nor what exactly causes automake to fail (possibly the error is related to <http://www.gnu.org/software/automake/manual/html_node/Canonicalization.html#Canonicalization>)

During compilation, I get this warning:
  CC libunicodeconvert/unicodeconvert.o
../../src/libunicodeconvert/unicodeconvert.c: In function ‘table_filler’:
../../src/libunicodeconvert/unicodeconvert.c:1004: warning: comparison between signed and unsigned

Question: Does this new library have to be built and linked to on platforms other than Windows at all? Or could it be useful outside of EMF import/export for enhanced font support?
- Internal EMF import/export support in Inkscape is proprietary to the Windows port of Inkscape and not available on other platforms (the 'emf-win32-*' sources are not compiled).
- AFAICT, the specific font configuration file 'fontfix.conf' gets neither installed on non-windows platforms, nor found (based on the sources trying to read it using a Windows path syntax).
- The location of the configuration file doesn't seem correct to me: a (font-related) config file does not belong into the 'extensions' directory - better put it into a new directory inside 'share', similar to the recently added 'share/attributes' directory (merge of last year's GSoC project), or maybe into the already existing (but unused) 'share/fonts' directory (its originally intended use needs to be investigated though)

Attached a modified version of the patch which applied on OS X and successfully compiled - I can't tell though whether the changes to 'src/libnrtype/Layout-TNG-Output.cpp' have any negative impact on non-Windows platforms (Layout-TNG-Output.cpp doesn't look specific to EMF support to me - rather it seems a part of Inkscape's text layout engine (?)), nor whether it makes sense to compile libunicodeconvert on platforms without EMF support.