A About fonts
With PDF HandShake you can use complete PDF documents in the printing business or in an OPI workflow. PDF documents – in contrast to images such as TIFF or Photoshop files – may already contain text elements using included or referenced fonts. So, with PDF HandShake, we have to find a way to read the font information from a given PDF file and to use this information for printing (and for layout generation if you use HELIOS ImageServer).
Section A.1 “PDF font processing” gives an overview of how the fonts in a PDF document are handled by PDF HandShake during printing and during layout generation by ImageServer. The paragraph is a quick reference.
Section A.2 “Font types in PDF” gives some more background information about fonts, explains the problems that could arise, and illustrates the workflows when handling fonts. This chapter is meant for those who “want to learn more”.
Appendix B “The fonts we deliver” lists all the fonts we deliver with our product.
A.1 PDF font processing
PDF HandShake can only use the fonts that are embedded in a given PDF document or those that are available on the server or printer. For OPI layout generation, the fonts must be either embedded or accessible on the server.
Whenever a font is embedded in a PDF file, it will be used by PDF HandShake. This is why we recommend to always embed all fonts when creating PDF files – at least if you are working on different systems.
The fonts we deliver together with our software package are meant to ensure high-quality printing for all PDF files, even for those that do only contain font references and thus are dependent on the available system fonts.
There are different categories of fonts, namely PostScript fonts and TrueType fonts. Even though PDF HandShake requires PostScript printers (which usually require PostScript fonts), the program can also handle TrueType fonts.
PostScript fonts are also divided into different categories. The most frequently used PostScript fonts are “Type 1” and “Type 3” fonts.
PDF files with PostScript Type 1 or Type 3 fonts do not cause any problems. Printing can only fail if a font is not embedded and is not available on the server or printer either. In that case, the print job will be aborted or the printer will replace the missing font with Courier.
PDF files with TrueType fonts are handled as follows:
If the TrueType font is embedded, PDF HandShake transforms the TrueType font into a PostScript Type 1 font and prints the PDF file correctly. The output quality can be enhanced if the printer has a built-in TrueType rasterizer (see TrueType fonts below).
If the TrueType font is not embedded, PDF HandShake tries to find a corresponding PostScript font – one with the same name – on the system, and uses the PostScript font for printing.
With ImageServer, fonts are not only required for printing, but also for layout generation.
The generation of layouts should never fail for PDF files
that contain PostScript Type 1, Type 3 or TrueType fonts.
Non-embedded missing fonts will be replaced with Courier
for the screen preview part of the EPSF layout. The printable
part of the layout only becomes relevant if you want to
print the layouts instead of the high-resolution PDF files. In
that case, fonts are handled the same way as if printing
high-resolution files. This means that they might be
replaced with Courier (see The handling of fonts during printing above).
To avoid font replacement during printing, you should
always activate the Check Fonts option on your printer queue
(see the respective chapter in the HELIOS ImageServer manual).
A.2 Font types in PDF
The PDF file format allows the following font types:
PostScript
Type 1
Type 3
CID-keyed fonts with Type 1 glyphs
(CIDFontType0)Multiple Master font (Type 1 font extension)
TrueType
Non-CID-keyed TrueType fonts (standard)
CID-keyed TrueType fonts (CIDFontType2)
OpenType
OpenType based on TrueType
OpenType based on CFF
Font subsets can be generated from all of the font types listed above. Font subsets contain less glyphs than the original font it is derived from and have a different name, e.g.:
Original font name: Times-Roman
Subset font name: LCIFOK+Times-Roman
Before discussing the different types of fonts – at least those that are allowed in PDF documents – we want to define some specific expressions that will be used later:
A.2.1 Bitmap fonts vs. outline fonts
In bitmap fonts, the characters are represented by a pattern of pixels. Angled or curved character elements have a serrated shape that becomes more and more obvious when scaling a bitmap font. Therefore, to avoid heavy serrations, the character patterns have to be different for every point size. This would consume a lot of memory. So, bitmap fonts are not very well suited for digital printing.
In outline fonts, the shape of each character is described geometrically by lines and curves. Outline-format characters are infinitely scalable, and are therefore not limited to a particular point size. Nearly all font types we discuss below, are outline fonts. Type 3 fonts are the only exception; they can be either in bitmap or in outline format.
PostScript fonts are very successful in the printing business because each character of a font is handled like a graphical object. PostScript interpreters apply complex algorithms to the fonts and thus are able to transform them into a pixel pattern for a specific output device.
Type 1 is a font format for single-byte Latin fonts. It can be used with PostScript printers. Type 1 fonts use a specialized subset of the PostScript language that is optimized for performance and compact representation. The Type 1 operator set includes so-called “hint information” to generate accurate bitmaps for small sizes and low resolutions. In general, Type 1 fonts guarantee the most accurate results on printouts. All PostScript fonts we deliver with our software package are Type 1 fonts.
Type 3 fonts can use the full PostScript language to draw their glyphs. Thus, Type 3 fonts can use features such as shadings, multiple colors, and fill patterns, which are not supported in Type 1. One drawback is that Type 3 fonts are not optimized for size or performance like Type 1 fonts are, and there is no built-in method for adding “hint information”. Type 3 fonts look slightly bolder than they would if expressed as a Type 1 font. Type 3 fonts can be useful for special-purpose or very complex fonts (such as complex logos). The format also provides a way to represent bitmap characters.
Type 3 fonts are extremely rare in modern prepress environments.
TrueType fonts are rather wide-spread. Nevertheless, they
can cause problems in high-quality printing. When converting
PDF files to PostScript for a printer, TrueType fonts
within the PDF file can both be transformed to PostScript
Type 1 fonts and be left unchanged for printers with a built-in
TrueType rasterizer. A TrueType rasterizer is an optional
feature of a PostScript RIP, which enables direct processing
of TrueType fonts. A PostScript printer without TrueType
rasterizer cannot process TrueType fonts.
The transformation of TrueType fonts to PostScript Type 1
fonts is only an approximation, which results in a slight
loss in quality. PDF HandShake generates both a Type 1 font
approximation and an unchanged TrueType font in PostScript
for each TrueType font in a PDF document. The unchanged
TrueType font is embedded in a PostScript
Type 42 font
envelope. A printer with TrueType rasterizer can be
recognized by the following PPD entry:
*TTRasterizer:Type42
Multiple master font formats are considered extensions to the Type 1 format. Usually, one font file only contains one representation of a specific font as far as weight and width are concerned. For example: Font1-Light, Font1-Regular, Font1-Bold, Font1-CondensedLight, Font1-ExpandedLight. Multiple master fonts include two or more “master” fonts within a single font file. This allows users to interpolate many intermediate “instances” of the typeface. PDF HandShake does recognize multiple master fonts but cannot use them or transform them into a usable format. The only thing PDF HandShake can do is to try and find a PostScript Type 1 font of the same name on the server or to replace the font with Courier.
CID-keying is a method of defining multiple-byte encoded fonts. CID-keying is available as an extension for Type 1 fonts (CIDFontType0) and for TrueType fonts (CIDFontType2). Glyphs are accessed by their character ID instead of by their glyph name. CID fonts are mainly used by some applications, e.g. Adobe InDesign, and for fonts with large character sets such as Chinese, Japanese, and Korean (CJK) language fonts. PDF HandShake supports CID fonts that are embedded in the document. They are converted to PostScript Type 0 fonts for output.
OpenType is an extension of the TrueType format that allows inclusion of CFF fonts (Compact Font Format, a compressed representation of a Type 1 font). OpenType fonts based on CFF are treated the same way as Type 1 or CID-keyed Type 1 fonts. OpenType fonts based on TrueType are treated the same way as TrueType or CID-keyed TrueType fonts.
PDF HandShake recognizes fonts in PDF documents by name. The naming conventions for fonts are not standardized for all font types and systems, meaning that even though a font is identical on two systems, the font names can be different. A PDF file, for example, can contain a reference to a font called “Times,Italic”, whereas the corresponding font on the server is called “Times-Italic”. PDF HandShake provides a mechanism that allows handling the different naming conventions. There are two searching strategies:
The original font name from the document is used
Otherwise, if the font name used in the document contains a comma, the comma is replaced by a hyphen and the new font name is used. The comma–hyphen replacement is sensible for most of the documents coming from a Windows PC because in Windows (TrueType) font names the font attributes are often separated by a comma. In PostScript font names, there is no comma; font attributes are usually separated by a hyphen
The tables below summarize how PDF HandShake deals
with the different types of fonts. The first table describes
the handling of fonts during printing, the second one
describes the handling of fonts during OPI layout generation.
The tables are followed by a flowchart (Fig. A.1)
which illustrates what exactly happens on the server and
printer when a PDF file is being printed. Please note that the
Check Fonts option – which is mentioned in the tables – is
available to ImageServer users only.
Printers can handle missing fonts very differently. In most cases, printers use their default font if they receive a print job with missing fonts. For most printers the default font is Courier. Most printers deliver a warning message when they substitute a missing font. Some devices abort incomplete jobs completely or halt them and deliver a message so that you can install the missing font.
| Font type (Status) | Printing / Layout generation – Print preview |
|---|---|
| Type 1 (embedded) | Embedded font is used. |
| Type 1 (by reference) | Corresponding Type 1 font
from the server or printer is used – if available. Otherwise, if the font is missing, there are two options: If Check Fonts is active the job is aborted completely.If Check Fonts is not active the handling of the job depends
on the printer’s default settings; the printer might use Courier,
abort the job or hold the job and deliver a warning. |
| Type 3 (embedded) | Embedded font is used. |
| Type 3 (by reference) | Not relevant (Type 3 fonts are always embedded). |
| TrueType (embedded) | Font is transformed into Type 1. Both the Type 1 and the Type 42 font are sent to the printer. The Type 42 font is used if the printer has a built-in TrueType rasterizer. |
| TrueType (by reference) | PostScript font of the same name is used – if available on the server. Otherwise, … (see “Type 1 (included by reference)”). |
| Multiple Master (embedded) | PostScript font of the same name is used – if available on the server (very unlikely). Otherwise, … (see “Type 1 (included by reference)”). |
| Multiple Master (by reference) | PostScript font of the same name is used – if available on the server (very unlikely). Otherwise, … (see “Type 1 (included by reference)”). |
| CID (embedded) | Font is transformed into Type 0. |
| CID (by reference) | Not supported, the job is aborted. |
| Font type (Status) | Layout generation – Screen preview |
|---|---|
| Type 1 (embedded) | Embedded font is used. |
| Type 1 (by reference) | Corresponding Type 1 font from the server is included – if available. Otherwise, Courier is used. |
| Type 3 (embedded) | Embedded font is used. |
| Type 3 (by reference) | Not relevant (Type 3 fonts are always embedded). |
| TrueType (embedded) | Font is transformed into Type 42. Type 42 font is used. |
| TrueType (by reference) | PostScript font of the same name is used – if available on the server. Otherwise, Courier is used. |
| Multiple Master (embedded) | PostScript font of the same name is used – if available on the server (very unlikely). Otherwise, Courier is used. |
| Multiple Master (by reference) | PostScript font of the same name is used – if available on the server (very unlikely). Otherwise, Courier is used. |
| CID (embedded) | Font is transformed into Type 0. |
| CID (by reference) | Not supported, the job is aborted. |
