> 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 _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel