[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] Type 1 dictionary information

From: Chris Liddell
Subject: Re: [ft-devel] Type 1 dictionary information
Date: Wed, 26 Oct 2011 19:05:54 +0100

On 26 October 2011 18:41, Werner LEMBERG <address@hidden> wrote:
> So, is this something amenable to change?

I'm not sure whether this really works.  While you get most
informations from a `standard' Type 1 font with FreeType's parsing
algorithm, there are examples like Adobe's `optima' family where this

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]