Text objects fragment when saved to EMF, noninteger point sizes

Bug #939688 reported by David Mathog
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
Undecided
Alvin Penner

Bug Description

Inkscape 0.48+dev (and 0.48.2) on Windows XP SP3

Longish text which has an integer point size (ie, like 40px = 32pt, or even 41.25px = 31pt) when saved as an EMF will be one
long text object, assuming there are no font or style changes within it. This is as it should be. However, if text is stretched uniformly (hold down control and drag a corner or center arrow on bounding rectangle) or scaled (for instance, multiplied by 111.111%) then saved as EMF it will be broken into many smaller text elements. There will be one big chunk at the front, then progressively smaller chunks until each character is in a separate text object. This can be seen when the EMF is imported back into Inkscape, or when it is imported into PowerPoint or any other program which reads EMF files. This fragmentation is taking place above the level of the EMF output methods. While working on other EMF problems I found that the EMF text output method was being called separately for each text fragment.

Removing manual kerning (there should not have been any) on the affected text does not resolve the problem.

The integer point sizes, when represented in pixels,, have values = N*(5/4). These have an exact floating point representation.
My guess is that the text sizes which are affected have pixel sizes that cannot be exactly represented in a floating point representation, and this leads to rounding errors which in turn lead to the fragmentation problem. Text scaled by
9/8, 17/16, 33/32, 65/64, and 129/128 all stay in one piece when exported, which fits the hypothesis, since these have exact floating point representations. (The last two were accomplished by editing the SVG file, as the transform/scale did not have enough decimal places to hold those numbers).

The workaround, at present, is to set the font to a size with an exact representation. It would probably be acceptable to
round font sizes, whenever these are changed, to the nearest exactly representable floating point number, which might be, for instance, the closest multiple of 1/4096. The resulting error would be at most 1 pixel in a display 4096 pixels wide.

Revision history for this message
David Mathog (mathog) wrote :
Revision history for this message
David Mathog (mathog) wrote :

This is what the exported EMF looks like once it is imported back into Inkscape, following an ungroup and select all. Notice how the 2nd and 3rd lines are composed of multiple text objects, but all the rest are single text objects.

su_v (suv-lp)
tags: added: emf exporting win32
Revision history for this message
Alvin Penner (apenner) wrote :

confirmed on Windows XP, Inkscape rev 11003

Changed in inkscape:
status: New → Confirmed
Revision history for this message
Alvin Penner (apenner) wrote :

it appears that the problem was caused by numerical roundoff error.
- fix committed to rev 11020

Changed in inkscape:
status: Confirmed → Fix Committed
Kris (kris-degussem)
Changed in inkscape:
assignee: nobody → Alvin Penner (apenner)
milestone: none → 0.49
John Smith (john-smithi)
tags: added: precision
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.