[EMF to SVG conversion]: text overlapping

Hello,

I am a colleague of Kanstantsin. Would it be possible to have an initial review of this bug? It is urgent to a solution (large-scale deployment) at a top 10 banking client. If more details or clarifications are needed, please let us know and we will be happy to provide whatever is needed.

Thanks -- Steven

@David Mathog - any chance you could take a closer look at this EMF-related report for trunk?

That is a clipping issue. The text always overlaps, but the reason you didn't see it was because the draw of the long text was clipped in the generating application. Inkscape is supposed to handle clipping on import from EMF, but not on export to EMF. So it should have been able to read this properly. There are clipping commands in the EMF, I will need to see if they are doing something unusual.

Please simplify the example down to just a single line (for instance, the top one) and post that EMF. The extra lines just make it harder to debug.

You do not need to make that example, I found part of the problem. That led to another more difficult bug outside of the EMF import code, so it will take at least another day to solve.

The attached patch "fixes" the error in text clipping. Unfortunately it exposes a latent bug: conversion from SVG in memory to a document does not come out the same as the same SVG from a file. That will be posted as a new bug in a moment.

This patch is committed as revision 13468. After that new bug is posted I will add a post here directing further work towards it.

For the people who needed this fixed ASAP: modify src/extension/internal/emf-inout.cpp at line 3498 to direct "d.outsvg" directly to a file. That will work for your purposes. The files produced are properly clipped when read in by Inkscape or viewed with Firefox.

The conversion issue is bug #1348417.

This patch makes the same changes as above but for WMF input files. It also includes a slight correction for clipping path names, so that clipping paths from EMF and WMF have different names. Committed as revision 13473. As before, bug #1348417 messes up the generated SVG, but one can see that it was correct if the debug line in Wmf::open is uncommented, to copy the generated SVG to stdout, and then read it back in as a normal SVG file.

Hi,

Could you please provide any update on the issue?

Thanks in advance!

The long answer is that long ago Inkscape had its own way of laying out text where it looked up the glyphs, their widths, and so on, and figured out how to lay out the glyphs. Later on there was "pangoification", where the task of figuring out where to place the glyphs was assigned to pango. The problem is that most of Inkscape was not changed at that time, so it still goes back to figure out things like bounding boxes based on the glyph's widths. There are are other dependencies too, like for cursor motion. For languages that map 1 character to 1 glyph, possibly with accents or other modifiers on that one glyph, this all works fine. So European languages and Hebrew worked. The method falls apart for Indic languages, where instead we find multiple characters mapping to a logical cluster consisting of multiple glyphs. Moreover, the character order for Indic languages is not 1:1 with glyph orders (character 3 may result in a different glyph being used for character 1.) My patch, above, papered over this problem, but the more I look into it, the more it looks like the correct thing to do is to complete the pangoification, and always use pango's functions to find these values instead of the ad hoc methods that Inkscape currently uses. That is a pretty big change to the code and I have not had time yet to address it.

Resetting bug status to 'Triaged' and removing milestone based on comment #10.