>
> So, is this something amenable to change?
informations from a `standard' Type 1 font with FreeType's parsing
algorithm, there are examples like Adobe's `optima' family where this
fails...
In general, I hesitate to provide an API to data which can be
sometimes incorrect...
What exactly do you have in mind?
My thought was to provide an API call, for example, FT_Get_PS_Font_Value(), which would take (amongst others) an enum parameter which would identify a dictionary key to return. That would mean the currently private type 1 data structures can remain private, and would make it explicit that only a subset of possible keys are actually available.
The problem we have is that there are now many more type 1 implementations that are independent of a Postscript interpreter. As with the FT one, they tend to be much more "fast and loose" with the Postscript syntax. As a result, we're seeing PDF files with really broken Type 1 font streams which most PDF consumers happily consume.
As we're already using Freetype for glyph rendering, it would make sense for us to use it, rather than write our own or fork the FT T1 code. For reasons I won't bore you with, we do need to be able to create a (fairly) valid Postscript type 1 font dictionary which can be seen by the Postscript interpreter. We're only talking about Type 1 streams from PDF files, in Postscript jobs we have to continue to use the PS interpreter.
Chris