Re: [Devel] OpenType futures

[Owen Taylor]

On Tue, 2004-08-10 at 22:42, Werner LEMBERG wrote:

> > Either way could be managed for Pango, the second is easier
> > to deal in the short term, certainly. I'd really like to hear
> > from David and Werner what they think the path forward
> > should be.
> 
> I strongly prefer the latter.  Do we agree that FreeType's job is to
> validate the tables, and that the otlayout library expects validated
> tables?  This is, the stuff in FreeType's src/otlayout directory
> should be made working, serving as a basis for the otlayout library.

To make sure that we are all on the same page:

 otlayout/ module in freetype CVS.

  Port of freetype1 code from streams to raw tables by David

 freetype2/src/otlayout/ on the main branch:

  Older attempt by David to redo OpenType handling from scratch
  using a two-pass validate-then-parse approach. Parsing is
  done at time of feature application so memory usage is potentially
  much smaller.

 freetype2/src/otlayout/ on the LAYOUT branch

  Includes *both* the stuff from the main branch and the freetype1
  code in its Pango-1.2 form. Only the  freetype1/Pango code is
  compiled or used.

I think the two-pass approach requires basically an entire rewrite
which is a major project. It clearly can be a lot more memory 
efficient, but I don't have a good feel for the relative speed of
feature application. Does the smaller memory footprint make up
for byte-swapping and lots of offset computation?

If we set up things correctly, it probably is possible to basically
seamlessly transition in the future from the working
freetype1/Pango/Qt currently to a such a rewrite if someone wanted 
to do it. I'd rather see something less ambitious in the short term.

Regards,
                                                Owen

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