Re: [ft-devel] controlling FreeType modules

[Werner LEMBERG]

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

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

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


    Werner