Re: [ft-devel] controlling FreeType modules

[Chris Liddell]

On 30 August 2012 15:35, Ken Sharp <address@hidden> wrote:
> At 10:26 30/08/2012 -0400, Alexei Podtelezhnikov wrote:
>
>
> > Can we ask FreeType users what do they want to have and have simplified in
> > API?
> > What do they not need too?
> >
> > By users I mostly mean:
> > - Cairo and Pango (Behdad ?)
> > - Qt
> > - fontconfig
> > - ghostscript (Ken Sharp ?)
>
>
> Should be Chris Liddell for Ghostscript now, though (obviously) I'm still
> lurking and still interested :-)

Well, a few thoughts just off the top of my head (I suspect my 
preferences won't be terribly popular....).

As far a our use with Ghostscript is concerned, I would like more access 
to the "internals" of Freetype and each font type, not less. For 
example, the API calls I added (and Werner kindly accepted) to let the 
application interrogate the contents of a Postscript Type 1 font 
dictionary (other PS font types pending....).

Another example that I recently stumbled across (and haven't yet 
investigated fully) is the rendering of notdef glyphs. For Truetype, 
Freetype is (correctly) using the TTF notdef glyph (the empty 
rectangle), but for Postscript/PDF/PCL/PXL, the notdef is a non-marking 
glyph. So, in the event that we're using a TTF in a PS/PDF/PCL/PXL 
context, we'll need a way to influence that behaviour.

Generally, there are two ways for a library to allow that kind of 
access: keep a small, very simple function call API, and open up the 
data types, making the (currently internal/private) structures public. 
That can be a problem as it restricts future development, fixes and 
improvements in the internal representations can't really be applied 
because those representations are now part of the public API.

The other way is to use "accessor" functions, and allows those internal 
representations to remain private, but results in a more complex set of 
API function calls to interrogate and influence those internals.

My preference is to have a "dual level" API: where you might have a 
simple "high level" interface, which includes the very simplest use 
cases and hides the vast majority of the details of what the library is 
doing from the calling app, and users need very little knowledge to use 
it. Then you have a "low level" API, where users need a lot more 
knowledge of what they're doing, but they then have the ability to 
access and influence a lot more of the behaviour of the library.

Note that Freetype already effectively has that "double layer" type API, 
it's just not documented that way, or clearly delineated in the code at 
the moment.

Also, a note on the fontconfig interaction mentioned: I'm not clear on 
what that proposal involves, but I would urge against Freetype 
interacting directly with fontconfig. I feel Freetype should continue to 
be purely a font scaling/rendering library, and shouldn't get involved 
in "font management", or other "peripheral" functionality.

Lastly, a note on the comment about (paraphrasing) "after all these 
years of digital typography, surely the use cases have stablised". I 
think that's a nice theory, but it falls down in practice, in my 
experience. The other way to look at it is that after all this time, we 
have more implementations out there that, on various platforms, get used 
as the "reference" - the Windows font interpreter is subtly different 
from the Apple one, which is subtly different from the Adobe one (and 
the Monotype one, and the Bitstream one, etc etc). And none of them 
exactly follow the various specifications involved. And, in practice, 
Freetype has to make a decent job of handling all those variations.

Also, the needs of rendering for a 4096dpi monochome hard copy printer 
will be quite difference from rendering for a 600dpi four colour 
printer, which is different from a 72dpi CRT display, which will be 
different again from a 100dpi LCD display.

Finally, even in our (in-development) use of Freetype in 
Ghostscript/GhostPDL: Postscript/PDF has subtle differences from 
PCL/PXL, and both have subtle differences from XPS.

Chris