RE: [ft-devel] FT2 and LSB

[Camp, TracyX E]

I'm replying in part to this message and the earlier one from mpsuzki
that raised some similar issues...

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

Let me assure you all that LSB only includes public APIs.  In fact I
believe LSB errors a bit on the side of caution here in that some
non-posix libc interfaces have been removed that are still very
necissary - but thats a on-going LSB discussion.

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

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

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.

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

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.


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

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?

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

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


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

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

I'll need some help here it sounds like....

To follow up on a few more questions from mpsuzuki:

1) Cairo is not going to be included (just don't have time this go
around) but very likely will be in LSB 4.0 (late next year sometime).

2) LSB isn't in the business of fixing software that is 'broken' by LSB
(which isn't to say that we don't help folks out and sometimes even send
patches).  We make an effort to produce standards around the public API.
If an application wishes to be LSB compliant, they need to adjust, if
they don't care, well we don't either ;)  LSB isn't a distribution.

3) LSB produces a SDK (and standard) for each architecture (IA32, x64,
IA64, ARM, m68k, Alpha, 3960, PPC32, PPC64...).  Most of those
architectures are only covered by the core LSB spec however.
Architectures actually likely to run desktop apps (IA32, x64) are
covered by the desktop portion of the LSB spec.  A given distribution
could actually certify for the x64 and IA32 LSB specs on the same x64
distro if they liked.


Thanks,

Tracy Cmap

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