[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Devel] OTLBuffer
From: |
Owen Taylor |
Subject: |
[Devel] OTLBuffer |
Date: |
Fri, 16 Jul 2004 16:34:29 -0400 |
The way that OTL_GlyphVector and OTL_Ruleset work in the the
otlayout/ module in freetype CVS is roughly based on
PangoOTGlyphString and PangoOTRuleset work in Pango-1.2, but
for Pango-1.4 I redid that.
To review, in Pango-1.2, the way it worked was that you
added both GPOS and GSUB features to a PangoOTRuleset, then
called one function:
void pango_ot_ruleset_shape (PangoOTRuleset *ruleset,
PangoGlyphString *glyphs,
gulong *properties);
That first applied the GSUB handling then the GPOS handling.
There were a couple of problems with this:
- It's quite inefficient if you want to handle input glyphs
a few at a time or apply rules one at a time, because
each call to pango_ot_ruleset_shape() has to allocate
separate temporary strings.
(This was a problem when Qt borrowed the code from Pango,
so Lars redid the feature application process.)
- Callers may need to do custom processing between GSUB
and GPOS handling.
So for Pango-1.4 I replaced the direct usage of PangoGlyphString,
which was simply a linear vector of glyphs with PangoOTBuffer
which has unspecified internal state. An except from the
PangOTBuffer API looks like:
struct _PangoOTGlyph
{
guint glyph;
guint properties;
guint cluster;
gushort component;
gushort ligID;
};
PangoOTBuffer *pango_ot_buffer_new (PangoFcFont *font);
void pango_ot_buffer_add_glyph (PangoOTBuffer *buffer,
guint glyph_index,
guint properties,
guint cluster);
void pango_ot_buffer_get_glyphs (PangoOTBuffer *buffer,
PangoOTGlyph **glyphs,
int *n_glyphs);
void pango_ot_buffer_output (PangoOTBuffer *buffer,
PangoGlyphString *glyphs);
There are separate calls for GSUB and GPOS:
void pango_ot_ruleset_substitute (PangoOTRuleset *ruleset,
PangoOTBuffer *buffer);
void pango_ot_ruleset_position (PangoOTRuleset *ruleset,
PangoOTBuffer *buffer);
The full API can be seen at:
http://cvs.gnome.org/viewcvs/pango/pango/pango-ot.h?rev=1.8&view=markup
This Pango-like API actually wraps a FreeType style API called for
a structure called OTLBuffer, which has a similar API, except that
it's missing the "_output" step and exposes the internal structure.
http://cvs.gnome.org/viewcvs/pango/pango/opentype/otlbuffer.h?rev=1.1&view=markup
Then I modified the TT_GSUB_Apply_String() and TT_GPOS_Apply_String
to take a PangoOTBuffer and got rid of the separate TTO_GSUB_String
and TTO_GPOS_Data structures.
My hope was that doing it this way is going to be efficient and flexible
enough to use for Pango, for Qt, and for other consumers. What do
people think? Should I look at what would be required to merge this
into the otlayout module?
Regards,
Owen
signature.asc
Description: This is a digitally signed message part
- [Devel] OTLBuffer,
Owen Taylor <=