Bug 55058

Summary:	List of EMF import bugs with examples
Product:	LibreOffice	Reporter:	mathog <mathog>
Component:	Drawing	Assignee:	Not Assigned <libreoffice-bugs>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	medium	CC:	frob, rodo, volker.berlin
Version:	3.6.1.2 release
Hardware:	x86 (IA32)
OS:	Windows (All)
See Also:	https://bugs.freedesktop.org/show_bug.cgi?id=61083 https://bugs.freedesktop.org/show_bug.cgi?id=48916 https://bugs.freedesktop.org/show_bug.cgi?id=39327 https://bugs.freedesktop.org/show_bug.cgi?id=37281 https://bugs.freedesktop.org/show_bug.cgi?id=31814 https://bugs.freedesktop.org/show_bug.cgi?id=47243 https://bugs.freedesktop.org/show_bug.cgi?id=39053
Whiteboard:
i915 platform:		i915 features:
Attachments:	Test EMF file Test file as seen in Windows Preview Test file in LODraw, low magnification Test file in LODraw, high magnification of one problem area Test file in LOdraw, high magnification of one problem area Test file in LODraw, high magnification of one problem area Test file in Inkscape, low magnification, for comparison EMF file with a nonIdentity rotation matrix in the WORLDTRANSFORM record Well-known Cisco's "router" icon in EMF format.

Description mathog 2012-09-18 16:46:02 UTC

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.

Comment 1 mathog 2012-09-18 16:46:47 UTC

Created attachment 67336 [details]
Test file as seen in Windows Preview

Comment 2 mathog 2012-09-18 16:47:33 UTC

Created attachment 67337 [details]
Test file in LODraw, low magnification

Comment 3 mathog 2012-09-18 16:48:02 UTC

Created attachment 67338 [details]
Test file in LODraw, high magnification of one problem area

Comment 4 mathog 2012-09-18 16:48:31 UTC

Created attachment 67339 [details]
Test file in LOdraw, high magnification of one problem area

Comment 5 mathog 2012-09-18 16:49:01 UTC

Created attachment 67340 [details]
Test file in LODraw, high magnification of one problem area

Comment 6 mathog 2012-09-18 16:49:51 UTC

Created attachment 67341 [details]
Test file in Inkscape, low magnification, for comparison

Comment 7 mathog 2012-09-18 17:00:03 UTC

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".

Comment 8 mathog 2012-09-18 17:02:01 UTC

Sorry, forgot the link to libUEMF:

http://libuemf.sourceforge.net/

Comment 9 mathog 2013-01-29 18:24:35 UTC

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.

Comment 10 Valek Filippov 2013-02-18 16:41:51 UTC

Created attachment 75058 [details]
Well-known Cisco's "router" icon in EMF format.

Problem with Polybezier16?

Comment 11 Valek Filippov 2013-02-18 16:53:25 UTC

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.