[cairo] [PATCH] Generate Type 1 fonts from glyph outlines

[Adrian Johnson]

Carl Worth wrote:
> This looks like a non-trivial amount of new code to add to cairo, and
> I'm not sure how significant the benefits are. Can you help me
> understand them better?
>
> For example, how big are the file size improvements?

The following examples show the file sizes of a page
of glyphs generated by both the PS and PDF backend.
Each glyph on the page is printed once and only one scaled
font is used in the file.

Times New Roman 26 glyphs:
       Type 3          Type 1     Reduction
-------------------------------------------
PS      48,686          16,615      65%
PDF     47,019          11,767      75%

Times New Roman 250 glyphs:
       Type 3          Type 1     Reduction
-------------------------------------------
PS     310,606         111,275      64%
PDF    290,628          70,784      75%

There is the potential to further reduce the size of the Type 1
files as I have not taken advantage of the horizontal and vertical
versions of the path construction commands.

I was going to test if there is any noticeable difference in
the time taken to print these files however the Type 3 files
would not print on my printer.

> Are these
> significant in light of the other known inefficiencies of text output?
> (emitting a new font for every scale, emitting absolute positions for
> every glyph even when offset by exactly the advance values of the
> previous glyph, etc.) And, yes, I do realize that you are already
> submitting patches for some of these other inefficiencies.

Yes it is significant as the above test shows. The question of
which inefficiency is the most significant depends on what is being
printed. The glyph positioning inefficiency would be the most
significant when printing a document that has mostly the same scaled
font. I would expect the Type 3 font inefficiency to be the most
significant when printing CJK text. Improving the efficiency of the
text output requires fixing all three of these problems.

I considered the Type 1 patch to be the the precursor to fixing the
embedding of every font scale problem as it provides a method of
creating a font from an unhinted unscaled outline without the rotation
matrix bug.

> Beyond the file size improvements, are there other benefits besides
> the xpdf rendering issue? The xpdf thing sounds like just a poor
> implementation strategy in that application, (that it doesn't do
> antialiasing for vectors in type 3 fonts while its use of freetype for
> type 1 fonts does provide antialiasing).

xpdf is one viewer that has trouble with Type 3 fonts. kpdf also doesn't
do antialiasing on Type 3. gpdf, ghostview, kghostview, gv, and gs all
fail to display cairo generated PDFs with Type 3 fonts.

I suspect part of the reason why so many viewers don't handle Type 3
well is very few applications output Type 3 outline fonts. The only
applications I have seen that output Type 3 outline fonts are using the
qt3 library. However this has been fixed in qt4 which no longer outputs
Type 3.

One of the problems with embedding Type 3 fonts is that users or
developers trying out cairo will see how poorly the fonts are rendered
in their favorite viewer, see how well fonts from other applications
are rendered in the same viewer, then conclude that it is a cairo problem.

It would be better to ensure we output to the most portable format that
is guaranteed to work everywhere. PDFs generated by cairo are going to
be around for years and we don't know what software is going to be used
to view or print the PDF.


In another email Behdad asked when the Type 3 fallback is used. The
Type 3 fallback is used for:

 - OpenType/CFF fonts on all platforms
 - Type 1 on Windows (when FreeType is not used)
 - TrueType and Type 1 on Mac (when FreeType is not used)
 - Any other scalable formats supported by FreeType excluding TrueType
   and Type 1

TrueType subsetting on the Mac can be very easily fixed by a Mac developer.

I've spent some time looking at Type 1 on Windows and have not been able
to work out how to get at the raw Type 1 data.