Re: [Devel] FT_Set_Hint_Flags problem

[Werner LEMBERG]

> > But anyways, from *my* perspective, if we use something that 
> > isn't in the public API, or is marked experimental, and you 
> > break it, that's our problem, and if people complain, just point 
> > them at us. It's my responsibility to:
> > 
> >  A) Make sure that things as well as possible in each version.
> > 
> >  B) Make sure that things work when upgrading between Red Hat
> >     versions.
> >
> I understand your point of view, but mine is that 99% of users who
> encounter this kind of problem will think it's either their own
> fault, or that of FreeType.  Only a fraction will ask about it on
> the mailing list, or dare to look at the archives for more
> information.  The rest will just grow frustated.

Mhmm, this point of view is perhaps a bit too conservative...

> Would you be interested if we provided in FT2 an API similar to what
> FT1 does and the code you ported from there to Pango?  I was
> thinking about performing the following:
> 
>    - providing an API similar to what FT1 provides to manage
>      OpenType Layout tables.  This assumes you didn't make too many
>      changes to the code when "porting" it to Pango + FreeType
>      internals.

It depends on how much work this is.  FT1's OpenType interface is far
from being elegant IMHO.  Actually, I've never looked into Pango's
code so I don't know how it is used -- Owen, can you describe what
interface you need?  Have you ever done a comparison with ICU?  I
believe that ICU is really up to date with its OpenType
implementation (since Eric Mader still works on it) contrary to FT1's
OpenType stuff which is dormant.

>    - bringing back the old stream functions within the library, as
>      simple calls to the new ones. this, to avoid "breaking" old
>      Pango installations when upgrading FreeType.

Do you really think this is necessary?

>    - maybe even bring back a dummy FT_Set_Hint_Flags for the
>      same reasons :-)

Urgh.

> I've re-started working on "src/otlayout" but the final code will
> not be available before long.  In the mean time, sort of porting the
> old FT1 code to FT2 should be easy, even if the implementation is a
> bit intimidating..

The intention of the implementation was to prove the concept.  It is
neither elegant nor effective.  As I've mentioned a few times on this
list already, I'm bad at developing APIs.


    Werner