The attached dump.svg is the output of a preliminary version of my text reassembler. The red text (underneath the black)
represents the original chunks of text read from the EMF file emitted by Inkscape. There is a rectangle drawn around each text record that was present in that EMF, and one big one around the completely reassembled paragraph. The black text is the reassembled text - in one big editable paragraph.
In Inkscape it is very good - the black text is aligned with the red (to the accuracy limit imposed by the EMF representation). However, in all other SVG viewers examined (Firefox, Opera, on Windows and Linux) the black text does not exactly line up with the red when there are two text sources on a line. This is evidently because these browsers are rendering the first piece of text on the line wider than inkscape does - if you open any of them you will see that the first bounding box does not fully surround the text that starts the line. The second chunk of text on the line, in order to be editable in Inkscape, uses a "dx" offset, and if the rendering comes up with a different width than Inkscape does for the preceding text, then the 2nd and later pieces are offset.
The example uses a common font and no especially tricky formatting. (0K and 500K refer to horizontal kerning in the original
file before it was saved to EMF.)
Any thoughts on how the font rendering in those browsers might be different from that in Inkscape?
Here is another example of the problem. In this one the boxes around the first part of the text were drawn manually in inkscape.
In each case the text starts just to the left of the leading period, and ends at the right edge of the last "A". Again, as with the previous case, when viewed in Firefox the text extends beyond the edges of the box. This is quite disturbing because near as I can tell all units are in Pixels, and the font Arial is common, suggesting that Firefox (and the other browsers tested) are doing something quite different with text scaling/