EMF containing dashed or dotted objects cannot be unpacked in PowerPoint

Bug #888793 reported by David Mathog on 2011-11-10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Alvin Penner

Bug Description

Drawings that contain an object with dotted or dashed lines, when saved as an EMF, do not import correctly into PowerPoint 2003 (on XP SP3). The problem is that the "ungroup" command does nothing and the imported drawing effectively acts like an image. The attached SVG has this property. Note that the toxic EMF file will ungroup if opened in Inkscape. This suggests that it may be a uniconverter issue.

Inkscape 0.48.0
Windows XP SP3.

David Mathog (mathog) wrote :
David Mathog (mathog) wrote :
su_v (suv-lp) on 2011-11-10
tags: added: emf exporting win32
su_v (suv-lp) wrote :

> Inkscape 0.48.0
> Windows XP SP3

Any reason not to update to the latest bug-fix release (0.48.2)?

> This suggests that it may be a uniconverter issue.

EMF files are not handled via UniConvertor [1], the Windows-port of Inkscape has native EMF import/export routines.

[1] UniConvertor is used for WMF support, if explicitly choosing the file type (there should be two WMF formats listed in the file dialogs on Windows):

UniConvertor-based file format:
- input/output:
'Windows Metafile (*.wmf)'

Internally handled:
- input:
'Enhanced Metafiles (*.emf)'
'Windows Metafiles (*.wmf)'
- output:
'Enhanced Metafile (*.emf)'

David Mathog (mathog) wrote :

Repeated the test with Inkscape 0.48.2r9819 on Windows XP SP3. As before, the problem svg file produces an EMF file that cannot be ungrouped within PowerPoint 2003.

The iffy EMF's produced by either version of Inkscape will open in LibreOffice 3.4 Sdraw, and "break" will take them apart into their objects, but in that case the dotted outline of the rectangle is converted to a solid line.

David Mathog (mathog) wrote :

I have found a workaround.

1. Set dash style on object.
2. Convert object to path (if it isn't already a path).
3. extensions -> modify path -> convert to dashes
4. (IMPORTANT!) set dash style on all of the little pieces back to solid line

At this point an exported EMF can be ungrouped in powerpoint.

Probably step 3 should have performed step 4 automatically, but it doesn't.

Alvin Penner (apenner) wrote :

attached is a modified version of convert2dashes.py. I have deleted the attribute 'stroke-dasharray' from the style after the conversion to dashes has been performed, since it is no longer needed. This should eliminate the need for step 4 in the procedure given above.

in order to use this you will need to copy it into the share\extensions directory and then perform the 'convert to dashes' routine.

Alvin Penner (apenner) wrote :

    fwiw, I do not think the original problem was caused by the Inkscape export routine that generates emf. I think it is a deficiency in the PowerPoint editor. When Inkscape generates the emf and when the linestyle is changed from solid to dashed, the only change that occurs in the emf file is a change in the command EMR_EXTCREATEPEN. This command is modified slightly to contain the lengths of the dashed lines and a few bits are set to specify that the line is dashed, similar to what svg does with the stroke-dasharray attribute. These changes appear to be compatible with the emf spec given by Microsoft, and they would not be enough to explain the change from editable vector graphics to a single uneditable object. When this emf file is re-loaded back into Inkscape, it is found that the original svg form is recovered intact, having survived the round trip. The only obvious change is that there is a bit of round-off error in the dash lengths. The round-off error is rather annoying because it means that a standard 'stock' dash pattern is no longer recognizable as a 'stock' pattern, which has some rather nasty consequences in the Fill and Stroke Editor, leading sometimes to a solid line. However, that's offtopic.
 The reason I think this is a PowerPoint problem is because, if you create a dashed line using the PowerPoint editor and save it as an emf file, then the emf file will _not_ contain the analog of the stroke-dasharray attribute in the style, instead it will be a bunch of short lines with a solid linestyle, which suggests that the PowerPoint editor does not fully support dashed linestyles.
 Proposing to mark this as Fix Committed if it turns out that the convert2dashes.py routine is an acceptable workaround in its new form. (The removal of the dashed linestyle attribute in this routine should have been part of the original submission, and was an oversight.)

David Mathog (mathog) wrote :

PPT 2003 is doing something pretty odd when it saves a dashed line to EMF. On my machine it came back looking like a dashed line, but it wasn't. In the attached example the first slide was made, then exported as an EMF. The second slide is an "insert picture" made from the saved EMF. There was no problem ungrouping the imported EMF. I made one modification to the second slide - changed the color from black to "no fill". Look at it at high magnification - it isn't a line. That's why it no longer has "begin/end style" set. Not quite sure what it is actually, since "edit points" doesn't do anything to it.

Alvin Penner (apenner) wrote :

yes, it looks as if the dashed line has been converted to a series of rectangles that have stroke but no fill. Inkscape sometimes does this, for example if converting text to path, but it would never be the default behaviour in Inkscape, only an option that you might choose if needed.
    In any event, I think this is outside the scope of what Inkscape can deal with. The basic problem is that Microsoft has never seen fit to develop a decent emf editor, I guess the subject of vector graphics does not interest them.

Alvin Penner (apenner) wrote :

new version of convert2dashes.py committed to rev 10774. marking as Fix Committed. please feel free to revert the status if you do not agree.

Changed in inkscape:
status: New → Fix Committed
su_v (suv-lp) on 2011-12-16
Changed in inkscape:
assignee: nobody → Alvin Penner (apenner)
milestone: none → 0.49
tags: added: backport-proposed
David Mathog (mathog) wrote :

apenner said in message 11: Inkscape sometimes does this, for example if converting text to path, but it would never be the default behaviour in Inkscape, only an option that you might choose if needed.

There are no visible options on "convert to dashes". The only option in "save as emf" is "convert texts to paths", which is not checked.

There is still a problem even with "convert to dashes".


1. make a filled rectangle
2. set border to dashes
3. convert to path
4. convert to dashes
5. break apart
6. save as EMF

Import into PPT, the import cannot be ungrouped. Same thing if the object is first converted to a path and then the outline is made into dashes.


David Mathog (mathog) wrote :

Oops, sorry, ignore the rectangle business in message 13. That was on the version that didn't automatically change the dashed attribute back to solid. With that in place the rectangle does not cause ungrouping problems.

Krzysztof Kosinski (tweenk) wrote :

Fixed file copied to stable in 9872

Changed in inkscape:
milestone: 0.49 → 0.48.3
tags: removed: backport-proposed
Ted Gould (ted) on 2012-02-15
Changed in inkscape:
status: Fix Committed → Fix Released
David Mathog (mathog) wrote :

Which fix was committed, the one where "convert to dashes" changes the line attribute back to solid?

Last week I analyzed some EMF files generated both by inkscape and PPT. The PPT ones use a "basic" form of the dotted line,
where an attribute is set to one of solid,dots,dashes,dot-dash. The Inkscape one uses an "extended" form for dotted lines, where the actual pattern is specified. I think this is why PPT cannot deal with Inkscape's dots and dashes - the application only knows about the basic forms of dotted lines. Unfortunately there is currently no way to specify in Inkscape, or in the EMF output routines, that only the basic form should be used. This issue likely comes up in some other graphic file contexts which have predefined line patterns. If memory serves, CGM is like that too.

Alvin Penner (apenner) wrote :

yes, the fix that was committed is the fix that was discussed in comment 8 above

- Alvin

To post a comment you must log in.