Re: [ft-devel] FT2 and LSB

[David Turner]

Hello Tracy,

On Mon, 4 Dec 2006 09:32:19 -0800, "Camp, TracyX E" <address@hidden> said:
> I'm working on an effort to include the full 'font stack' in the LSB
> (Linux Standards Base see: http://www.freestandards.org/).
> 
> FreeType is obviously an important component of the de-facto 'font
> stack' (along with Pango, fontconfig, Xft and XRender) on linux based
> systems.  Since LSB release 3.1, LSB has included fontconfig and Pango.
> For the upcoming LSB 3.2 release we would like to include freetype, Xft
> and XRender (XRender is complete).
> 
> So a few questions:
> 
> 1) comments concerns, about putting FreeType's ABI into LSB?
>

Putting the public API in the LSB seems a good idea. I'm talking
about the functions that are declared FT_EXPORT() in the source code.

As you probably know, we made a big mistake in the past by installing
the engine's internal headers during "make install", as well as not
preventing non-public symbols from being exported by the FreeType
shared library.

The result has been a number of clients who peeked and poked
at the engine's internals to achieve a number of different things,
even when some perfectly valid public API could be used to do the
same thing.

The consequence was that when we released a new version of the font
engine, whose internals had been modified, this broke certain programs
and libraries in "interesting" ways; even if the public API didn't
change, except for additions.

Another similar mistake was the fact that some parts of the API were
declared experimental (e.g. the cache sub-system), but most client
developers didn't care and started using them in their code. When
we did change some of the experimental functions, other interesting
moments occured.

And sadly, all of this occured without much people telling us about
it. It seems distribution maintainers are so used to patch upstream
releases they don't even report the problem they face, until they're
major show-stoppers. Very fortunately, this attitude seems to have
changed a lot with regards to FreeType.

There is one specific case where we really screwed up the public
API though, i.e. when we added some fields to the FT_Bitmap_Size,
which are typically accessed in arrays. But this was a long time
ago, and we should never do something like that anymore, ever...

The list of publicly exported functions is generated automatically
by our "apinames" tool during the build. The result is in
objs/ftexport.sym, and shall be used to limit the list of exported
symbols from the shared library (however this last "feature" is disabled
to avoid problems with systems that haven't eliminated all rogue clients
yet. It should definitely be part of the LSB builds).

A few of the functions there might not be necessary for the LSB though
(see below).

 
> 2) Are there areas of the FreeType API that would be best left out?
>
I think that the GX/OpenType validation stuff shouldn't be part of the
public API, this kind of code should really be part of the corresponding
table parsers, if only for security reasons.

The FT_Library_SetLcdFilter function is really new, I don't know if you
would want to include it in a first release of the LSB, though I think
the present version is stable and won't change.
 
> 3) Are there any upcoming ABI breakage concerns?
>
As described above, ABI breakage were unintentionnal. I don't think
we plan *any* of these in the future.

We just need to care to not put unsupportable experimental new APIs
in our release. Maybe guard them from compilation with a #ifdef or
something like that.
 
> How LSB works is that it generates an ABI standard from a released
> version of whatever library interface, the standard does not necissarily
> include everything from the API and we really try to obtain 'upstream
> package' guidance on this when possible.  This ABI remains in effect for
> distributions certifying to the particular version of LSB in a forward
> compatible manner for a number of years.  Which means if the ABI where
> to change at some point in the future, the older ABI would still need to
> be supported, or the distribution might be forced to maintain a older
> version of the library.  However this does not preclude new APIs or
> non-ABI breaking changes to the library or even minor semantic changes
> (changing a const qualifier for instance).
> 
> In case you are wonder, in a practical sense the LSB ABI is enforced by
> creating a stub-library that is used at LSB application linking time and
> becomes part of the LSB SDK.  At run-time the application then uses the
> real library as supplied by the LSB certified linux distribution.
>
This seems really finely designed. One topic that hasn't been discussed
here is wether the LSB dictates which features of FreeType need to be
available, since:

- the font format support is done through selectable plug-ins, I don't
  think for example that you would need PFR or WinFNT support in a
  LSB release.

  Personally, I would be happy to see the BDF and PCF font formats
  eradicated from any Linux distribution; these things are just
  *big* memory and CPU wasters (a much better format is TrueType-embedded
  bitmaps, like the ones generated by the fonttosfnt tool, since these
  files can contain several character sizes, be memory-mapped and
  shared between processes, will use a lot less heap memory,
  be very fast to open/load).

- the optional unpatented hinter, which is used to load various commercial
  CJK fonts that require a TrueType bytecode interpreter to load correctly,
  though they happily do not used any of the patented opcodes.
  Should this be part of the LSB release, or an option ?

- I'm thinking about de-activating the postscript hinter, since the
  auto-hinter in CVS now produces results that are often better, except
  in a few cases.

- the issue of activating/deactivating the bytecode interpreter. Since
  this is totally orthogonal to the API, I don't think that the LSB
  should dictate anything here.

- the issue of activating the LCD filtering stuff (i.e. ClearType-like
  rendering). My belief is that this is totally covered by Microsoft
  patents, which means the feature should be disabled by default in
  each of our public releases. Fortunately, the API to use this
  feature has been designed to be as transparent to users as
  possible (i.e. if the feature isn't implemented, you'll get
  results equivalent to anti-aliased rendering, and your code
  that uses FreeType won't break at all)

All of these are options; I think it's best to let the distribution
maintainer wether they should be activated or not; however this is
something to keep in mind when writing tests.

Regards,

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


> Thanks,
> 
> Tracy Camp
> 
> 
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/freetype-devel