Sorry for the late reply; I haven't had time to do much Inkscape stuff this week.
On Thu, 2004-05-27 at 05:22, fred wrote:
That's about right; the plan is:
ok. currently trying to do classes for 3) for typeset, to test code in isolation before hitting libnrtype.
That makes sense. Good job. ^_^
Part of the reason for the gradual approach is that there are a lot of (potentially important) minor tweaks in libnrtype (e.g. the special unicode mapping Lauris added for "symbol fonts" for Lilypond-generated SVG); we want to understand all the code we're replacing so we won't have regrets later.
good you tell me that! where is it located? i can't find it
I'm not totally sure either; I only remember it from discussion on the Sodipodi list when Lauris comitted it.
Basically, in the case of "special" symbol fonts, they may or may not have a unicode map. Different programs tend to generate SVGs that expect either:
* Unicode codepoints are mapped directly to font glyph indices
or
* the font glyph indices are mapped into the Unicode private use area
so we needed to cover both cases.
I think part of this code is in e.g. nr_typeface_ft2_lookup, but I will have to admit an incomplete understanding of what it is trying to accomplish.
IIRC there are actually three private use areas in Unicode:
* Private Use Area: U+E000 through U+F8FF
* Supplementary Private Use Area A: U+F0000 through U+FFFFD
* Supplementary Private Use Area B: U+100000 through U+10FFFD
It looks like the code only concerns itself with the first two, although the range for the second looks wrong.
The mapping logic appears to be:
1. if the unicode codepoint is anywhere above U+F0000, subtract 0xf0000 and map directly to a font glyph index
or
2. if the font has no unicode table, subtract 0xe000 from the codepoint and map directly to a glyph font index
or
3. if the font has a unicode table, but the codepoint is in the (first) private use area and the font provides no glyphs in that area, subtract 0xe000 and map directly to a font glyph index
or
4. otherwise, let freetype do the codepoint -> glyph mapping as it normally would
I don't think that logic is entirely correct (in particular #1 and #2 seem deeply wrong to me), but due to differing expectations by SVG creators, I think we do indeed need to do something special with symbol fonts and the private use areas.
(this may mean needing to subclass or wrap a Pango backend)
from what i see, pango shaper fill the x_offset/y_offset/width of the glyphs in the geometry element. width is meant to be the advance (ie kern_glyph tweaks these values by adding/substracting the kerning). i'm not 100% sure of what i said, tho. after having a look at the GPOS/GSUB/JSTF tables of the OpenType spec (which pango partly implements) i fear there may be more complex stuff going on.
Indeed.. essentially the "actual" advance is very context-dependent.
(a simple example for western languages would be where the same font glyph is used for both the composing and non-composing versions of a diacritical character)
-mental