Re: [ft-devel] controlling FreeType modules

[Chris Liddell]

On 06/09/12 07:05, Werner LEMBERG wrote:
> > 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.
>
> This sounds like a good candidate for a property of the truetype
> module...

I think I have a workaround for now, but it would certainly be easier if 
it were supported in the library. I need to look more closely at how the 
Truetype module sets all this up, but it would probably be moderately 
easy to have GID 0 setup as a whitespace glyph.

> > 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.
>
> But this doesn't solve the problem of exposing internal structures to
> the public...

The reality is that it means that the "low level" API will likely extend 
over time - as folks identify new aspects they want to interrogate or 
influence, we add functions to handle those to the API.

It's very much a compromise, but I don't think there is a "right" answer 
which doesn't end up reducing flexibility and increasing the change of 
the code being forked.

Alternatively, we could go a bit object oriented, so (almost?) every 
internal structure includes an accessor function pointer (I'd make the 
accessor the first entry in every relevant structure). Then we can 
change the internal representations any way we want, and just modify the 
accessor function to suit. We can also make additional information 
available through the accessor as required without superficially 
changing the API.

> > 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.
>
> Basically, I agree.  However, the border between font objects and font
> management is fuzzy.  For example, do you consider composite fonts
> like Windows 7's `CompositeFont' objects or PostScript's `FontType 0'
> fonts as something FreeType should handle?  I think it doesn't really
> belong to FontConfig.  Instead, I can imagine a layer on top of
> FreeType which handles such formats.

Hmmm, I haven't really looked into the Windows 7 CompositeFont things (I 
probably will have to at some point). By Postscript Type 0, I assume you 
mean a CIDFont which has been composed with a CMap? From a Ghostscript 
point of view, we handle all the Type 0 font stuff ourselves, so 
Freetype only ever sees the descendant fonts, but in general, I would 
consider combining the CIDFont with the CMap to be part of loading a 
font for use, so within Freetype's remit.

Having said that, given that you need a Postscript interpreter to really 
handle CIDFont/CMap combinations in the general case, I can't imagine 
there being much demand for it, so that may well be moot.

I just think that Freetype should remain an engine which takes a font 
from some source, and uses it to to create outline or bitmap glyphs. I 
would not like to see Freetype getting sucked into loading fonts by name 
(even if that was done by punting off the fontconfig), or gaining any 
kind of layout capabilities.

Chris