Re: [ft-devel] Re: Truetype Collection fonts

[mpsuzuki]

Hi,

On Sat, 05 Jan 2008 15:47:28 -0700
Deron Kazmaier <address@hidden> wrote:
>Hi,
>Sorry. Seems the default for this list is to reply to the author and not 
>the list.

Thunderbird may have "Reply To All" button, please use it.

deron> The issue has been resolved on my end, but for your own information
deron> ftmac.c (amongst other things) will load various resource based font
deron> data and massage the data into a linear representation that
deron> resembles the on-disk format of a Windows TrueType/Type1 font.  That
deron> is (one) of the "conversions" that goes on and is useful for not
deron> only rendering but outputting to PostScript/PDF files.

werner> The same we do for reading Type 42 fonts which are converted to a TTF
werner> internally more or less.  So you are talking not about font conversion
werner> between different formats but conversion between different wrapper
werner> formats (as described in FreeType's `formats.txt' file) -- is this
werner> correct?
werner>
werner> I still think that the result of a wrapper conversion is internal to
werner> FreeType and can't be exposed to the public so that it is useful for
werner> other applications.  However, I don't mind to provide hooks to that
werner> data if it can be done in a sensible way -- can provide patches for
werner> that?

deron> Yes, conversion between wrappers. It would be a pretty simple set of 
deron> changes to ftmac.c at least.

Just I've checked the posts with "TrueType Collection fonts"
since 2007-12-22, but I'm not sure what is expected to be fixed
in future ftmac.c. The basic task of ftmac.c is the identification
of font file format, decapsulation of the file, and getting
standard TrueType font tables or synthesis of standard PFB font
file image from suitcase PS Type1 font. If you have some TrueType
font or PS Type 1 font that cannot be parsed by ftmac.c, please
let me know. It's bug and should be fixed.

As Werner already pointed out, getting a decapsuled or synthesized
TrueType or PS Type1 font is NOT sufficient to make an object image
which is ready to be embedded in PDF (especially for non-Roman fonts).

There are some oversimplified implementation that embeddes
a font file from disk to PDF document without appropriate
conversion. Their PDF output is so problematic that PDF
renderer have to rely their own blackmagic fallbacks.

Example 1: PFA format of PS Type1 font cannot be embedded in
PDF, it must be converted to PFB before embedding. (see PDF
Ref 1.7 p.467)

Example 2: although TrueType font has its metrics information in
hmtx/vmtx table (yes, there's no other source) and these information
can be directly passed by Type42 font format, the handling of
Type42 hmtx/vmtx contents may be dependent with PDF renderer.
Explicitly specification of character width may be expected (Adobe
Distiller does so).

Example 3: if a PDF generator uses coded character to render
a text (instead of preprocessed TrueType glyph indeces),
appropriate /Encoding should be inserted to Type42 dict in
PDF. Please be careful that cmap platform=1 encoding=0
subtable is not always MacRomanEncoding. Some developers
expect that if coded character set is 8bit, the expansion of
cmap platform=1 encoding=0 subtable is sufficient, but not.

Example 4: some fonts are licensed to be embedded under the
restriction "as far as the embedded characters are only
the characters used in the document". Copying of whole font
into PDF is incompatible with the license.

deron>                              I'm still working on a few other font 
deron> related problems and when I get done I'll see what could be done that 
deron> would be beneficial external to freetype not just "bloat". With the 
deron> changes that (mpsuzuki?) is making to generate a mac api less ftmac.c 
deron> perhapo that would make for a good time to implement? I would be happy 
deron> to commit something back if someone else would find it useful.

At present, freetype2 built without ftmac.c (it's default)
can parse dfont format, resource-fork TrueType, resource-fork
PS Type1 font, I think. However, it does not parse FOND content,
so the order of face appearance in dfont/suitcase font may
differs, and it cannot find PS Type1 format from bitmap screen
font (e.g. it cannot find "HelveLTMM" from "Helvetica LT MM").

Following APIs are really specific to Mac OS X and cannot be
implemented without Carbon framework, so I have no idea to
emulate them on POSIX platforms.

FT_New_Face_From_FSSpec()
FT_New_Face_From_FSRef()
FT_New_Face_From_FOND()

FT_GetFile_From_Mac_Name()
FT_GetFile_From_Mac_ATS_Name()
FT_GetFilePath_From_Mac_ATS_Name()

These features are essential for your purpose?

Regards,
mpsuzuki