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