freetype-devel
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]