Layout-TNG-Compute figures out glyphs, spans, etc. for screen output. But when and where is that information actually drawn to the screen?
I have been working on EMF, R->L output and various other things, and discovered that Pango sometimes really goes to town breaking text fields into smaller "unbroken spans". These are necessary for screen display, since it must find a glyph/font pair for each unicode character, but some of the results are overkill for the "print" output functions, which typically need to know where the resulting glyph is, but most likely do not really care what (substitute) font was used. That is true for EMF output, and presumably for the other supported output formats as well.
Example, when the following 7 unicode characters are entered, all in Arial font:
(a) (grave accent) (b) (acute accent) (c) (circumflex accent) (d)
pango_itemize breaks it into 3 pieces:
(a) (grave accent) (b) (acute accent) (c) (circumflex accent) (d)
because Arial (on the test system) did not have a glyph for circumflex, so it fell over to DejaVu Sans. These 3 smaller pieces are then fed one by one into pango_shape() and etc., until the information is ready for the screen. This is all well and good for screen display, but the same graphics structure is also used for "print" output (other than SVG, I think). The second fragment, in particular, is likely to be mishandled by whatever reads the file output, since that is a Mark, nonspacing unicode character, and should always follow a normal character in the same text record.
In the print context the font substitution used within Inkscape is irrelevant for the construction of the output file. In all likelihood no or a different font substitution may take place in the target system. Breaking text strings that are in one "tspan" in the original SVG, down into several in other output formats, is certainly not the desired result!
To work around this problem layout-Compute would need to keep two sets of books, as it were: setting up the fragments that eventually go to the screen, and the simpler set of fragments that go to print. The glyph<->character map is the same, but the print spans are merges of 1 or more screen spans. Inkscape would need to make a distinction between drawing to the screen, and drawing to a file, and send the appropriate set of spans to the appropriate target. Near as I can tell, at present it just sends the same structure to both destinations. (This effect is not seen with SVG output, because nstead of working from the screen's graphics structures, it just saves the stored XML.)
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech