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

2008-01-06 Thread mpsuzuki
Hi,

On Sat, 05 Jan 2008 15:47:28 -0700
Deron Kazmaier [EMAIL PROTECTED] 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



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel


[ft-devel] Re: Truetype Collection fonts

2008-01-05 Thread Deron Kazmaier

Werner LEMBERG wrote:

[Please stay on the list.]

  

Hi,
Sorry. Seems the default for this list is to reply to the author and not 
the list.

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



The same we do for reading Type 42 fonts which are converted to a TTF
internally more or less.  So you are talking not about font conversion
between different formats but conversion between different wrapper
formats (as described in FreeType's `formats.txt' file) -- is this
correct?

I still think that the result of a wrapper conversion is internal to
FreeType and can't be exposed to the public so that it is useful for
other applications.  However, I don't mind to provide hooks to that
data if it can be done in a sensible way -- can provide patches for
that?


Werner

  


Yes, conversion between wrappers. It would be a pretty simple set of 
changes to ftmac.c at least. I'm still working on a few other font 
related problems and when I get done I'll see what could be done that 
would be beneficial external to freetype not just bloat. With the 
changes that (mpsuzuki?) is making to generate a mac api less ftmac.c 
perhaps that would make for a good time to implement? I would be happy 
to commit something back if someone else would find it useful.


I have not looked into fonts from zip files.

Anyway, thanks for your help.

Deron



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel


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

2008-01-01 Thread Werner LEMBERG
[Please stay on the list.]

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

The same we do for reading Type 42 fonts which are converted to a TTF
internally more or less.  So you are talking not about font conversion
between different formats but conversion between different wrapper
formats (as described in FreeType's `formats.txt' file) -- is this
correct?

I still think that the result of a wrapper conversion is internal to
FreeType and can't be exposed to the public so that it is useful for
other applications.  However, I don't mind to provide hooks to that
data if it can be done in a sensible way -- can provide patches for
that?


Werner


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel


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

2007-12-31 Thread Werner LEMBERG

 The thought I had was that since FreeType is reading this
 information already, that instead of reproducing that functionality
 some way might exist to use freetype to normalize the issue.

This `normalization' is done for rasterizing, not for font
manipulation.

 For example, creating a Type42 from a TrueType font I use a technic
 that is much like lilypond uses (thanks for the pointer Werner
 Lemberg).  Which is the kind of solutions I am looking for.

But as you've seen, there's a lot of additional coding.  We are not
going to integrate such stuff into the library.

 One was reading out the font from a Mac resource fork to output a
 TrueType to PDF or Type1 to either PDF or PostScript.  I know that
 FreeType does this in ftmac.c

Does it?  Why should FreeType convert the font format?  It seems I
don't understand what you are referring to.

 but the raw data is not available in a public interface.

The same: I don't understand what you mean here.

 The other problem is outputting to PDF from a TrueType font
 collection, ie parsing out the specific font.  This also falls under
 a bigger umbrella of subsampling a larger font.

You can use FreeType's FT_Load_Sfnt_Table to get all the SFNT tables,
but the rest of the conversion is up to you.


Werner


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel