Comment 9 for bug 888793

Revision history for this message
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.)