Created attachment 67335 [details] Test EMF file I have recently been doing working on the EMF import/export capabilities of Inkscape (https://bugs.launchpad.net/inkscape/+bug/988601) and today I got around to trying one of the test files on LODraw 3.6.1.2. There were a few issues found. 1. EMR_SMALLTEXTOUT - not supported 2. Pattern fill (all modes) - not supported 3. Pattern stroke (all modes) - not supported 4. Some discrepancies in textalignment modes (using Windows Preview as the gold standard). 5. After import into LODraw and then "break" dash patterns on lines are lost. 6. Fill winding attribute is broken (see the two 5 pointed filled stars) 7. Font sizes vary on rotated text (see the three roundish clusters of text at the top edge of the diagram.) 8. EMR_GRADIENTFILL - not supported. (Note, this is not supported in Inkscape either, and I have never been able to get the rectangular gradient records to work - all attempts resulted in EMF files which were toxic to Windows Preview.) 9. Graphics errors: line with the purple filled, turquoise lined figures. LODraw does the 5th and 7th figures incorrectly. 10. Graphics errors: the two lines with the same shapes, which are regular and 16bit versions of various records. The first item in the 2nd and 3rd groups is filled by LODraw, but it should not be. The test EMF file was produced by libUEMF 0.8, which is not released yet but will be later today.
Created attachment 67336 [details] Test file as seen in Windows Preview
Created attachment 67337 [details] Test file in LODraw, low magnification
Created attachment 67338 [details] Test file in LODraw, high magnification of one problem area
Created attachment 67339 [details] Test file in LOdraw, high magnification of one problem area
Created attachment 67340 [details] Test file in LODraw, high magnification of one problem area
Created attachment 67341 [details] Test file in Inkscape, low magnification, for comparison
The attachment lodraw_himag3.png was made after "break" - it shows the loss of the dot/dash pattern on the lines. The relevant pieces of code in Inkscape are in the src/extensions/internal directory of that distribution, in the files: emf-inout.cpp emf-inout.h emf-print.cpp emf-print.h uemf.c uemf.h I suspect that items 9 and 10 are due to logic errors in the LODraw equivalent of the code at the top of the main read loop in emf-inout.cpp starting around line 1408. This is the code which determines at what point, during the processing of the EMF file, to stroke/fill each internal object, which turned out to be quite complex. There are also some differences in the handling of EMR_BITBLT between Inkscape and LODraw, but since those operations are very hard to translate to internal objects, I would be hard pressed to say which, if either, is doing it "right".
Sorry, forgot the link to libUEMF: http://libuemf.sourceforge.net/
Created attachment 73863 [details] EMF file with a nonIdentity rotation matrix in the WORLDTRANSFORM record An email exchange with Valek Filippov has turned up an ancient bug in the EMF input implementation in inkscape - EMF WORLDTRANSFORM records with nonidentity rotation matrices result in a mangled drawing. Unfortunately LibreOffice 3.6 (on Windows XP, 32 bit) has much the same issue. The attached file is thoroughly mangled when imported into LODraw.
Created attachment 75058 [details] Well-known Cisco's "router" icon in EMF format. Problem with Polybezier16?
EMF attachment 75058 [details] includes "nested" EMF+(EMF(EMF+)). Drawing outer EMF gives standard router icon with known "1 pxl off IntersectClipRect" problem. Most inner EMF+ has DrawPath/DrawEllipse and FillPath/FillEllipse commands.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.