On Thu, 2004-04-29 at 02:06, Patrick wrote: > On Wed, 2004-04-28 at 22:05, Owen Taylor wrote: > > On Wed, 2004-04-28 at 02:22, Patrick wrote: > > > A simple question, > > > > > > When a shaper returns a PangoGlyphString does the > > > PangoGlyphString.PangoGlyphInfo.PangoGlyphGeometry.x_offset / .y_offset > > > refer to the offset from the base glyph of the grapheme cluster > > > containing the glyph or from the very 1st grapheme cluster of the > > > supplied text? That is, what exactly is the "nominal character position" > > > mentioned in the API documentation? > > > > Note that grapheme clusters have absolutely nothing to do with > > positioning of glyphs. Graphemes are purely related to things > > like allowed cursor positions. > > I thought a grapheme cluster referred to a combination of glyphs used to > represent a unicode codepoint or a basic 'linguistical unit' (you may > notice I'm unclear on standard terminology) of a language - ie. like an > accented 'a' could be made of a base 'a' glyph with an attached accent > glyph. And this being the case, wouldn't the glyphs that compose such a > 'compound glyph' be laid out, in sequence, within the PangoGlyphString > as well? Pango defines Graphemes as in UTR 29: http://www.unicode.org/reports/tr29/ "One or more Unicode characters may make up what the user thinks of as a character or basic unit of the language" this affects editing, but has no interaction with shaping. Pango has a second concept of a "cluster"; a cluster is one or more characters that interact during the shaping process to form one or more output glyphs. This could be base character plus combining glyphs, but it also could be a f and i character combining to form a fi ligature. These clusters are determined in the shaping process but do not affect positioning. A shaper that wants to position base character plus combining character would typically give the base character it's normal width, give the combining character a width of 0 and position it at a negative x_offset. > Can you define some of these standard terms for me? > > > The nomimal positions are gotten by adding up the widths > > of preceding characters > > > > x0 = 0 > > x1 = x0 + glyphs->glyphs[0].geometry.width > > x2 = x1 + glyphs->glyphs[1].geometry.width > > > > And x_offset/y_offset are added to that. > > Ok. That explains why you've said in the past (archive search) that > (metric) kerning would have to be part of the shaping process. I was not > sure whether the shapers only formed what I referred to as a grapheme > clusters / compound glyphs or whether they did all of the glyph > positioning. Glyph positioning is linguistic and font dependent, you have to allow the shaper to do that. > Does this mean that the current Pango shaper engine function must be > extended to pass in additional arguments before any shaper could be > configured to do some of the optional OpenType substitutions (ie. small > caps, swashes, titling alternatives, ligatures), contextual positionings > and kerning? PangoAttributes uninterpreted by the higher layers are already passed to the shaper. > Does this also mean that every shaper would need to redo this work? To some extent. The opentype utilities that we provide in pango-ot.h already do a lot of work for the shaper; this could be extended if we knew how to do that cross-script. (Typographic features are typically different for different scripts. Small caps don't make sense for Arabic, Arabic typographic features don't make sense for Latin) Right now, a simple opentype shaper just needs to: - Choose the features it wants to apply - Put the characters in the order specified by the language-specific OpenType spec, and add them to a PangoOTBuffer - Call pango_ot_ruleset_substitute() and pango_ot_ruleset_position() Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part