RE: [ft-devel] Starting work on the OpenType code

[Behdad Esfahbod]

On Fri, 1 Apr 2005, Turner, David wrote:

> Hello Behdad,

Hi David,

> I think having you working on the OpenType code is very good news.
> I'll only make a few comments there:

Thanks.

> - I don't think there is a need for a complete library at the
>   moment. There should be no problem hosting this code on the
>   FreeType CVS, though I don't see what would be wrong with
>   freedesktop as well. Pick your preference.

Ok, I'll go with freedesktop.org, for more exposure, but if you
don't mind, I prefer to keep discussions on this list, since a
new list would be simply duplicating the members' list for this
list, or so I guess.

> - The main reason why the code was left out of the library is
>   that it is a _lot_ of _complex_ code; I prefer to see
>   different releases / bug reports for both modules.
>
>   Also, one bug in FreeType will not necessarily ripple to the
>   OpenType parser, so they can be tested indepedently, at least
>   in theory. That's also why I'd favor code that doesn't
>   directly depend on FreeType. Feel free to duplicate code
>   where it makes sense. including 'otvalid'.

Ok, that's good news to me.


> - I'm also not very fond of putting the 'otvalid' module within
>   FreeType, but Werner's work is valuable in at least one scenario:
>   someone using FreeType with ICU, which provides its own C++
>   OpenType parser that doesn't perform a single check with regards
>   to table validity.

Sure, having code around doesn't hurt.  Actually I'm getting the
feeling that I'm not going to do complete validation either.
Just enough to be on the safe side.  So 'otvalid' would have some
bits to offer anyway.  Whether that belongs to FreeType or not is
another question.


> - If you intend to rework the internals later to parse the tables
>   directly, I'd suggest first reworking the current API to hide as
>   much details as possible. This would allow you later to make
>   drastic changes without requesting yet another big change to
>   both Pango and Qt.

Well, my current approach is a bit different:  Work something out
of the current code with minimal change, such that Pango and Qt
can deal with the 2.1.10 release in a backward compatible way.
Almost only changing namespace on the applications' side.   Then
after that go over the rewrite for everyone's favorite
enhancements, that would introduce a bigger change to the
applications, but I don't see myself at a position to fix the API
for that stage right now.


>   Actually, I must have some unfinished code to implement the
>   memory-mapped parser on my USB keychain. Let me know if you're
>   interested, I'll send it to you.

Sure.


> Hope this helps,
>
> - David Turner
> - The FreeType Project  (www.freetype.org)


Thanks again,
behdad





> >
> > Hi,
> >
> > Like Owen already mentioned, I'm starting to work on the Opentype
> > (a.k.a otlayout/) code that is copied into Pango and Qt among
> > other systems.
> >
> This is very good news :-)
>
> > - At the moment I don't plan to release a library, for not adding
> > yet another dependency, just a shared code base that Pango and Qt
> > can synch with one in a while.  Is it what people are most
> > comfortable with for the time being?
> >
> I don't think it's a problem at the moment.
>
> > - The next issue is where to host it.  I'm fine with
> > freedesktop.org, but starting a project there may take a while
> > (basically you need to find someone on IRC, otherwise email
> > doesn't work).  Hosting it in FreeType CVS is another option.
> > What do people recommend?
> >
>
> > - Another one is, for code to be shared between Qt and Pango, it
> > probably means that I cannot use glib, right?  That's a little
> > pain all the time.
> >
> Most of the code there is already disciplined enough to check for
> error codes, you shouldn't have a very hard time to get rid of the
> small number of GLib allocations that Owen put in there.
>
> I don't see why you would like to keep using GLib on such project.
>
> > Since I'm not releasing a library, I can simply use my own symbols
> > and Pango and Qt maintainers need to define them to match their
> > system.  What's wrong with depending on FreeType still, but
> > just not the private headers?
> >
>
> > - What is the timeframe people expect/need to see this commno
> > codebase out?
> >
> No answer there. I would say ASAP, but it's not like there's fire
> in the house at the moment :-)
>
> >
> > For a longer term plan, I wish to rewrite the code to use mmapped
> > OpenType tables from the font itself instead of loading them im
> > memory.
>
> This is a noble goal. Ideally, you could reword the API in order
> to hide as much implementation detail as possible. This would allow
> you to radically change the internals later without touching Pango
> and Qt.
>
> > For this, people suggested that I can use the otvalid/
> > module to validate the OpenType tables.  This raised the
> > following questions for me:
> >
> > - Why was the opentype code removed from FreeType originally?  Is
> > it going to join back or not?
> >
> Mainly because it is a _lot_ of _complex_ code. It's better to have
> two separate modules so that each one can be debugged / updated
> separately.
>
> I'm not fond of having the otvalid module within FreeType. I can
> see that it's usable in at least one scenario though: using FreeType
> with ICU, which provides its own OpenType parser that doesn't
> perform a single check regarding table validity.
>
> Also, I'd like to be able to use this code with older versions of
> FreeType, like the one in some versions of my company's products,
> where upgrading the font engine isn't an option at the moment.
>
> > - How is the opentype code usable without FreeType?  In other
> > words, if we need otvalid/ from FreeType, the most reasonable way
> > is to make the opentype code a FreeType module too.  To rephrase
> > my question, does Pango and Qt work on any platform without
> > needing FreeType (but needing the opentype code)?
> >
> I can see some places where this would be possible. E.g. Pango on
> Win32 without FreeType, in the case where UniScribe is not available.
> But others are more likely to give good examples.
>
>
> >
> > Regards,
> > --behdad
> > http://behdad.org/
> >
> >
> >
> > _______________________________________________
> > Freetype-devel mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/freetype-devel
> >
>
>

--behdad
http://behdad.org/