Re: [Devel] OpenType futures

[Lars Knoll]

On Wednesday 11 August 2004 16:27, Owen Taylor wrote:
> 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?

I think it could be about as fast, since you can drop a lot of the error 
checking code we now have all over the place. Offset calculation shouldn't be 
slower than a pointer lookup (the cache miss usually involved when looking up 
the pointer takes a lot longer than the addition of the offset). So (even 
though we can't really know), I don't think speed would be a problem. 
Rewriting a big part of the code might be.

> 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.

I have to agree here. It would be very good to unify the three code bases on a 
rather short term basis. Both Owen and I have applied quite some fixes and 
made changes to our codebases. It would be a great help to unify these so 
both projects can benefit from bug fixes.

How about a two stage approach: We first start going towards a unified 
otlayout library, using the code that is there. With some redesign of the 
public API, we can hide the fact that the tables are preparsed. 

This would make it possible to change the underlying model to validate the 
tables at load time, and use a nonvalidating parser that operates on the 
memory buffer as a second step.

Cheers,
Lars