[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Devel] Re: OTLBuffer
From: |
Lars Knoll |
Subject: |
[Devel] Re: OTLBuffer |
Date: |
Sun, 18 Jul 2004 00:30:38 +0200 |
User-agent: |
KMail/1.6.2 |
On Saturday 17 July 2004 17:23, Owen Taylor wrote:
> On Fri, 2004-07-16 at 18:26, Lars Knoll wrote:
> > Hi Owen,
> >
> > On Friday 16 July 2004 22:34, Owen Taylor wrote:
> > [....]
> >
> > > 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
>
> OTLBuffer, of course.
>
> > > and TTO_GPOS_Data structures.
> >
> > Sounds good. I guess the OTBuffer contains positioning information as
> > well?
>
> Yes. Basically, it contains two buffers of glyph data that are swapped
> between when applying GSUB lookups and a single buffer where position
> data is written during GPOS.
>
> OTL_GlyphItem in_string;
> OTL_GlyphItem out_string;
> OTL_Position positions;
Ok, that sounds more or less like the cache we have in Qt in the QOpenType
class.
> > > 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?
> >
> > Please do. I'd love to see a merge of our efforts into one codebase (ie.
> > otlayout). Judging from the few minutes I looked at the code it seems as
> > if some work is still required to finish the otlayout module and make it
> > really usable. If there is need, I'd be willing to help with implementing
> > and testing.
>
> As far as I know, the otlayout module is basically in the state
> described in:
>
> http://www.freetype.org/pipermail/devel/2003-August/009608.html
>
> That is, it's the FreeType-1.x code adapted to be standalone but not
> really tested and without any of the patches from
>
> http://people.redhat.com/otaylor/opentype-patches/
>
> I guess the question is whether David is OK with the otlayout module
> being picked up and adapted to fit the needs of Pango and Qt.
>
> If so, I think I can find a couple of days to merge it with the current
> Pango version (*), and then perhaps you can take a look at it from the
> Qt perspective.
Sounds like a good proposal to me. David also had a few proposals for API
cleanups and other things that would need to be done, see
http://www.freetype.org/pipermail/devel/2004-March/010354.html
We should maybe try to have a look at some of these issues at the same time if
we already dive into the code.
Regards,
Lars