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

[Turner, David]

Hello Behdad,

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

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

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

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

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

  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.


Hope this helps,

- David Turner
- The FreeType Project  (www.freetype.org)



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