On Tue, 2004-05-25 at 02:54, fred wrote:
the fact that the work needed is still a bit blurry probably doesn't motivate people; also, i'm less and less sure of the first step you put in the roadmap that consists of doing a pango libnrtype backend to eat libnrtype from the inside; libnrtype main use is to get glyph outlines and advances, something i cannot get pango to spit. on the other hand, nr-type-directory and nr-typeface are almost 1/1 mappings to PangoFontMap and PangoFont
That's about right; the plan is:
1. C++ify libnrtype to make it easier to refactor
2. introduce an NRTypeFace subclass that wraps PangoFont (and hides any platform/pango-backend-specific details)
3. remove the other NRTypeFace subclasses
4. jettison NRTypeDirectory and NRTypeFace, using Pango directly (moving any facilities not directly provided by Pango into a separate set of C++ classes)
To get glyph outlines and advances in Pango, you need to use backend-specific functions to get a "font handle" native to the underlying API (e.g. Freetype or Win32). IIRC, PangoGlyph in turn is just an integer containing the native font glyph index. At that point you can use the "native" API to get what you want.
Of course, SPTypeset, SPText etc. should not have to care about the native API; the intent is that the NRTypeFace subclass in #2 and later the supplemental classes in #4 will provide an API hiding those details.
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.
Another reason is so we can easily evaluate Pango without causing the breakage a wholesale replacement would. For example, I think the freetype backend should work on Win32 (i.e. it should pick up the Win32-installed fonts), but we need to make sure there aren't any gotchas.
(an ideal goal is to get the same code working on Win32 and Unix, but we have yet to see if that is possible..)
If at that point all the changes are "contained" by the libnrtype API, if it turns out to work badly, we can switch to using the win32 pango backend on Windows without disrupting the rest of the code.
isn't such info already contained in a glyph string? maybe diacritical marks have a special treatment (0 width, x_offset and y_offset?) in pango, i dont seem to locate rasterization-specific stuff for arabic; once the text has passed through the shaper, the glyphstring doesn't change.
Yes. I think I misunderstood the stages of Pango before. Doesn't the shaper output include the advance, then?
-mental