RE: [ft-devel] FT2 and LSB

[David Turner]

Hello Tracy,

> >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).
> 
> Can you tell me more?  This would actully be helpful to me to ensure
> that I only pull in the correct symbols.  Typically this is done by
> trolling through the .so's debugging data and pulling out all the
> symbols that are GLOBAL and then cross-comparing with the contents of
> header files that I feed into a tool we have.  Somethings a few things
> slip in that shouldn't be there (I do manually review all this, but I am
> human).
> 

We use the FT_EXPORT() macro in the FreeType headers to distinctly
declare public API functions, as in:

FT_EXPORT(result)   function_name(parameters..);

src/tools/apinames.c is the source of a small tool that is used to
parse the header files and extract the list of public functions. It
is built and used by the build system to generate a file named
"objs/ftexport.sym", which is simply a text file, containing one
public function name per line.

normally, the file should be used to strictly limit the list of
exported symbols in libfreetype.so. However, we disabled this feature
to be able to link the shared library with old "rogue" clients which
happen to call internal functions directly.

we're probably going to activate this in the near future. In all cases
you can use this file for the LSB, that should be a lot easier than
peeking within the .so file.

> >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.
> 
> We are going to base the LSB standard off of the concensus FreeType
> version being shipped as a .so by the various distro today...  So given
> that, would you include it or not?  LSB doesn't look backwards, but we
> try to make it easy for a distro to be in compliance from day-one.
>
I would encourage you to include it, but this would mean that a LSB-compliant
should have at least version 2.2.2 of the library (or wathever numbering
scheme we come up for the upcoming release)

that's not a problem for me, just be aware of it.
 
> New APIs are totally okay, so long as the LSB APIs remain stable.  The
> run-time version of the library doesn't matter too much so long as it
> looks like the LSB version to the application that uses it.
>
OK, no problem here then
 
> 
> >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:
> 
> LSB isn't really able to mandate semantics in the ABI standard, however
> we do produce conformance tests and will test for semantic correctness
> when possible.  So with regards to the various hinters, formats etc.  Do
> they actually represent a change in ABI?  Sorry if this is an obvious
> question, I'm new to freetype and looking at it from an orthoginal point
> of view than most of you.
>
The change in internal modules (where each module is responsible for
implementing a given feature, like hinting, rasterizing, font format
support, etc...) doesn't change the public API.

The API provides public functions that basically search for the module
that implements it, or returns an error otherwise.
 
> If they don't have an ABI implication, I would really appreciate some
> fine grained guidance on what you would like to see LSB mandate in its
> conformance tests.  This would be handled by adding test cases to the
> test suite I'm working on (the first test case which I'm having trouble
> with at the moment is just a API coverage case).
> 
> mpsuzuki mentioned that the patented subpixel rendering alg. was
> important for some CJK fonts.  Would it be possible to leave this out in
> the LSB ABI and conformance tests, but still allow distros that have
> done LSB certification to turn it on in their shipped version of
> freetype?
> 
There are only two patent-related issues here
- the "full" TrueType bytecode interpreter, which infringes on Apple patents
- subpixel rendering, which, I believe, infringes on Microsoft patents

the problem with CJK fonts is that some of these require a bytecode interpreter
to load properly. Very fortunately though, none of them seem to use any of the
patented algorithms described by the TrueType spec (which is only a small part
of the spec).

what this means is that it's possible to write a non-infringing bytecode
intepreter that cannot load standard TrueType fonts correctly, but will work
well with this CJK fonts. We call it the "unpatented interpreter"

in the current CVS code, the "unpatented interpreter" is compiled by default,
but only used when we detect at load time that the font is one of these tricky
CJK ones; otherwise, the auto-hinter is used as usual. The idea is to make
all things "just work" transparently to the user.

in previous releases, using the unpatented hinter was much more difficult,
which is why distribution maintainer preferred to simply activate the bytecode
interpreter to deal with it. Hopefully that shouldn't be the case very soon.


the subpixel rendering issue is not related to CJK fonts at all. The idea is
that in a default build, the LCD filter/decimator is disabled in a way that
guarantees that you don't need to modify client code that may use it.
However, FreeType will generated sub-pixel bitmaps that are strictly
equivalent to normal "gray" anti-aliased ones when displayed on a screen
(even if they're 3 times larger in memory, this is simply done by returning
LCD bitmaps with R=G=B for all pixels).

By simply changing a #define, we allow the FreeType internals to produce
subpixel-optimized glyph bitmaps, without changing the graphics stack above
it.

> A little bit off-topic, but you guys probably have some opinions: We had
> talked within LSB about including a set of fonts in the LSB standard, so
> that applications can count on both being able to render fonts, but
> actually having fonts to render.  We decided its a hard problem and that
> we probably didn't have the resources to solve it.
> 
> However the X11 fonts (sadly) appeared to be best positioned to step in
> since they are widely available, had full unicode coverage and due to
> their ugliness actually render with a fair degree of predictible
> precision.  There just is no clear winner in the truetype/opentype
> format that provides complete unicode coverage a reasonable set of
> sytles and is integrated in a large number of distributions.
> 
> Also display issues such as KDE & Gnome both making different decisions
> about the display resolution etc. get dragged in (running KDE apps on a
> Gnome desktop leads to really BIG fonts sometimes since KDE went the
> msft route of a fixed 96DPI resolution and Gnome varies it apparently -
> all heresay on my part however...)
> 
>
I don't think it's reasonable to impose a standard font set at the moment.
Most distributions ship with DejaVu, but this only covers a fraction of
international scripts. For non-latin ones, seems to vary widely between
distributions, and I don't see any likely clear winner...
 
> >- 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 ?
> 
> Are the mutually exclusive?  Again from an ABI standard, can application
> tell?  Can we leave this decision up to the distro?
>
Leave the decision to the distro author. Clients can generally know
which features are implemented (e.g. by calling a function a see if it
returns FT_Err_Unimplemented_Feature, or through other means)