On 30 August 2012 15:35, Ken Sharp <ken.sh...@artifex.com> 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
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
