[cairo] [PATCH] Generate Type 1 fonts from glyph outlines
ajohnson at redneon.com
Fri Sep 1 08:01:18 PDT 2006
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
> 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
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.
More information about the cairo