Inkscape

Bug #948245
Comment #14

Comment 14 for bug 948245

Revision history for this message

David Mathog (mathog) wrote on 2012-03-13:

#14

debug_small.txt Edit (4.1 KiB, text/plain)

Debugging print commands were placed in various locations in the libnrtype code as described in the attache file (see the "in..." lines).

The test file of the preceding post was opened, and then Inkscape closed. Nothing else was done.

One thing I am sure of - this line in FontInstance.cpp

    if ( theFace ) {
        FT_Select_Charmap(theFace,ft_encoding_unicode) && FT_Select_Charmap(theFace,ft_encoding_symbol);
    }

is not doing anything. In the test it was removed and replaced with consecutive tests trying to set unicode, then apple roman, then symbol. Also tests forcing apple_roman or symbol, or not setting any charmap at all (There were hex dunmps of the charmap before and after, these have been edited out of the attachment for clarity). The screen output never changed. Pango is evidently overriding/ignoring the freetype charmap. Also, ft_encoding_symbol sets the charmap in the PUA region 0xF020-0xF0FF, whereas apple roman sets it in 0x20-0xFF. Other than the offset, the maps are the same. Since I already have code to thunk Symbol characters down from the PUA to the latin area on EMF input, I have been using Apple Roman for most of these tests. (Not that it mattered, in the end.) (Yes, tested it with unicode in the PUA range, and those
characters were invisible.)

The first thing we see in the test is that font_instance::InitTheFace is called 3 times with SymbolMT. I'm not sure what calls it. All the calls are for Symbol. (Note, charmap <X> document each call to select_charmap, with a different charmap, with the return status shown. 0 is success.)

This is then followed by several more calls to InitTheFace from Layout::Calculator::_buildPangoItemizationForPara. The first
one calls once with SymbolMT, and the second one calls 3 times with BitstreamVeraSans-Roman.

This is then followed by two more calls to InitTheFace from who knows where, one for SymbolMT one for BitstreamVeraSans-Roman.

Anyway, by this time Pango has done something bizarre to the simple 4 character string, having mapped it onto two fonts
and having changed the glyphs for the two above 0x80. This can be seen in the LoadGlyph calls.

There are then a whole lot more calls to Layout::bounds - 8 sets of 4 (1 per glyph). This follows the set of 4 involved
in the actions of the previous paragraph.

Bottom line:

1. InitTheFace seems to be called many, many more times than is needed.
2. Pango is ignoring Freetype's Charmap and coming up with its own.
3. LoadGlyph works as it should, it is only called once per glyph
4. Layout::bounds is also being called many more times than is needed. (9 times per string)

also...

5. the lines of code cited above use a deprecated flag to set the charmap (not that it matters, as it turns out). Should be
FT_ENCODING_APPLE_ROMAN, FT_ENCODING_UNICODE

I have no experience with this sort of code, but it looks seriously broken to me, with routines being called repeatedly, presumably because the results are not being stored. Or because the code is just wrong. There must be a performance penalty for all of these calls, and this was on an example with just one line of 4 characters!

Debugging print commands were placed in various locations in the libnrtype code as described in the attache file (see the "in..." lines).

The test file of the preceding post was opened, and then Inkscape closed.  Nothing else was done.

One thing I am sure of - this line in FontInstance.cpp

if ( theFace ) {
        FT_Select_Charmap(theFace,ft_encoding_unicode) && FT_Select_Charmap(theFace,ft_encoding_symbol);
    }

is not doing anything.  In the test it was removed and replaced with consecutive tests trying to set unicode, then apple roman, then symbol.  Also tests forcing apple_roman or symbol, or not setting any charmap at all   (There were hex dunmps of the charmap  before and after, these have been edited out of the attachment for clarity).  The screen output never changed.  Pango is evidently overriding/ignoring the freetype charmap.  Also, ft_encoding_symbol sets the charmap in the PUA region 0xF020-0xF0FF, whereas apple roman sets it in 0x20-0xFF.  Other than the offset, the maps are the same.  Since I already have code to thunk Symbol characters down from the PUA to the latin area on EMF input, I have been using Apple Roman for most of these tests. (Not that it mattered, in the end.)  (Yes, tested it with unicode in the PUA range, and those
characters were invisible.)

The first thing we see in the test is that font_instance::InitTheFace is called 3 times with SymbolMT.  I'm not sure what calls it.    All the calls are for Symbol.  (Note, charmap <X> document each call to select_charmap, with a different charmap, with the return status shown. 0 is success.)

This is then followed by several more calls to InitTheFace from Layout::Calculator::_buildPangoItemizationForPara.  The first
one calls once with SymbolMT, and the second one calls 3 times with BitstreamVeraSans-Roman.

This is then followed by two more calls to InitTheFace from who knows where, one for SymbolMT one for BitstreamVeraSans-Roman.

There are then a whole lot more calls to Layout::bounds - 8 sets of 4 (1 per glyph).  This follows the set of 4 involved
in the actions of the previous paragraph.

Bottom line:

1.  InitTheFace seems to be called many, many more times than is needed.
2.  Pango is ignoring Freetype's Charmap and coming up with its own.
3.  LoadGlyph works as it should, it is only called once per glyph
4.  Layout::bounds is also being called many more times than is needed.  (9 times per string)

also...

5.  the lines of code cited above use a deprecated flag to set the charmap (not that it matters, as it turns out).  Should be
FT_ENCODING_APPLE_ROMAN, FT_ENCODING_UNICODE

I have no experience with this sort of code, but it looks seriously broken to me, with routines being called repeatedly, presumably because the results are not being stored.  Or because the code is just wrong.  There must be a performance penalty for all of these calls, and this was on an example with just one line of 4 characters!