Re: Embedding TTF fonts in PS files

[Akira TAGOH <at gclab org>]

Hi,

>>>>> On Thu, 03 Jun 2004 21:12:33 -0400,
>>>>> "OT" == Owen Taylor <otaylor redhat com> wrote:

OT> When working with the Pango code, I happened to notice that right
OT> now we are typically embedding TTF font files verbatim into the
OT> PS files we generate.

OT> The only exception to this is if the TTF embedding code fails,
OT> because, say, the font happens to have a table other than
OT> glyf bigger than 64k.

OT> Concerns:

OT>  - We don't have subsetting for TTF embedding, though we do
OT>    for TTF = > Type1 conversion.

It should be needed to get generating a small size of
PostScript file. but it also causes a problem that too many
words can't be printed out say, unless current code is fixed.

OT>    A small file with Greek, Latin, Japanese, Arabic, Bengali,
OT>    Hebrew and Hindi generated a 1.5M PS file with the
OT>    current code and 1.0M when I forced all fonts to be
OT>    converted to Type1.

OT>    And that's with only the Arabic and Hindi fonts embedded 
OT>    as TrueType. (others either had too big tables or were
OT>    Type1 as source.) The situation could easily be far worse.

OT>  - I'm getting lots of "(process:20138): GnomePrint-WARNING **: Too big
OT>    table in font" spew.

it's warned due to the array's limitation on PostScript, and
it's what gnome-print needs to be fixed. plus, it means
gnome-print gives up to use Type 42 font. instead, converts
a TrueType font to a Type 1 font to embed it on PostScript.

OT>  - Do most PS printers these really have TTF interpreters in them?
OT>    How is this working?

it depends on the targets we would support or if we enforce
to use ghostscript to print it out. since gnome-print used
Type 42 font to generate PostScript, we are assuming the
PostScript printer(or interpreter) should supports
PostScript level 3 specification. PostScript level 2
printers might supports it, though. but it's not MUST.

OT> I'm wondering if we'd be better off currently if we were doing
OT> the blanket conversion to Type1? is there a reason for favoring
OT> embedding TTFs directly currently?

If you mean the fonts shouldn't be embedded with Type 1 and
even Type 42, the reasons AFAICS is because of,

- the result of the printing without the embedding fonts
  depends on the printers and/or the interpreters. and
  WYSIWYG isn't possible on the printing.

- the result of the printing without it might be correct or
  broken, even if CID-keyed fonts and CMap is used. say, due
  to no CMap support for the languages, or no fonts is
  available on the printers.

- the result of the printing without it depends on the
  environment. even if we enforce to use ghostscript, using
  the fonts to print it out might be different. and it might
  breaks the printing layout.

However embedding the fonts also has the problems, though.

- as you said, generated PostScript is too big.

- though it's likely on the opensource world, the embedded
  fonts is ugly a bit than the internal fonts on the
  printers say. people may wants to use it instead of
  embedding the fonts then.


OT> Regards,
OT> 						Owen

OT> P.S. Clearly there are lots of other things that could be done better:

OT>  - Adding TTF subsetting if we want to continue embedding TTF fonts
OT>    (though that is pretty hard)

OT>  - Adding Type1 subsetting when we are embedding Type1 source format
OT>    fonts (should be considerably easier than TTF subsetting, plus
OT>    code exists in various places)

OT>  - Doing a better job at not writing out pages and pages of 
OT>    all-zeros encoding tables when subsetting a large font.

And,

- Adding the option if the fonts is embedded.
  having two way to generate the PostScript might be
  difficult to maintain the code though. and it depends on
  how many people wants to do.


Regards,
--
Akira TAGOH  : tagoh gnome gr jp  / Japan GNOME Users Group
at gclab org : tagoh gnome-db org / GNOME-DB Project
             : tagoh redhat com   / Red Hat, Inc.
             : tagoh debian org   / Debian Project