Loading
Notes
Study Reminders
Support
Text Version

Set your study reminders

We will email you at these times to remind you to study.
  • Monday

    -

    7am

    +

    Tuesday

    -

    7am

    +

    Wednesday

    -

    7am

    +

    Thursday

    -

    7am

    +

    Friday

    -

    7am

    +

    Saturday

    -

    7am

    +

    Sunday

    -

    7am

    +

The development of the PostScript computer language was pioneered by Adobe in creating the first device independent font files. This invention let consumers typeset their own documents on personal computers and image their documents on laser printers at various resolutions. To achieve WYSIWYG on personal computer screens, the font files needed two parts: screen fonts and printer fonts. Screen fonts were bitmaps that imaged the letter shapes (glyphs) on the computer screen. Printer fonts were vector descriptions, written in PostScript code, that had to be processed by a RIP at the resolution of the printer. The glyphs looked significantly different when imaged on a 100 dpi laser printer than they did on a 600 dpi printer, and both were quite different from what graphic artists/typographers saw on their computer screen. That was not surprising since the shapes were imaged by completely different computer files — one raster, one vector — through different RIP processors, on very different devices. Many graphic designers still do not realize that when they use Adobe type font architecture they must provide both the raster screen font and the vector PostScript font to another computer if they want the document that utilizes that font to process through the RIP properly. This was such a common problem with the first users of Adobe fonts that Microsoft made it the first problem they solved when developing TrueType font architecture to compete with Adobe fonts. TrueType fonts still contained bitmap data to draw the glyphs on a computer screen, and PostScript vector data to deliver to a RIP on a print engine. The TrueType font file is a single file, though, that contains both raster and vector data. TrueType fonts became widely distributed with all Microsoft software. Microsoft also shared the specifications for TrueType font architecture so users could create and distribute their own fonts. The problems with keeping screen font files with printer font files went away when graphics creators used TrueType fonts. The quality of the fonts took a nose dive as more people developed and distributed their own font files, with no knowledge of what makes a good font, and what can create havoc in a RIP. Today, there are thousands of free TrueType fonts available for downloading from a multitude of websites. So how does a designer identify a good font from a bad font? The easiest way is to set some complicated glyphs in a program like Adobe InDesign or Illustrator and use a ‘convert to outlines’ function in the program. This will show the nodes and bezier curves that create the glyph. If there are many nodes with small, straight line segments between them, the font may cause problems in a RIP. Remember that PostScript was meant to be a scalable device independent programming language. If the poorly made glyphs are scaled too small, the RIP has to calculate too many points from the node positions and ends up eliminating many points that are finer than the resolution of the raster image. On the other hand, if the glyph is scaled too large, the straight lines between points make the smooth curve shapes square and chopped-looking. These fonts are usually created by hand drawing the letter shapes, scanning the drawings, and auto tracing them in a program like Illustrator. The ‘convert to outlines’ test reveals the auto tracing right away, and it is a good idea to search out another font for a similar typeface from a more reputable font foundry. Another good test is to look at the kerning values that are programmed into the font file. Kerning pairs are glyph shapes that need the space between them tightened up (decreased) when they appear together. A good font usually has 600 to 800 kerning pair values programmed into its file. The most common pair that needs kerning is an upper case ‘T’ paired with a lower case ‘o’ (To). The ‘o’ glyph must be tucked under the crossbar of the T, which is done by programming a negative letter space in the font file to have less escapement when the imaging engine moves from rendering the first shape to when it starts imaging the second shape. If we set the letter pair, and put the curser in the space between them, a negative kerning value should appear in the kerning tool. If no kerning value appears, the font is usually a poor one and will cause spacing problems in the document it is used in. Another common problem occurred when combining Adobe Type 1 fonts with TrueType fonts in the same document. Adobe was the creator of the PostScript programming language, and although it was easy enough to copy its code and create similar fonts, Adobe has maintained fairly tight control over licensing the PostScript interpreting engines that determine how the PostScript code is rendered through a raster image processor. The RIP stores the glyph shapes in a font file in a matrix that can be speedily accessed when rendering the glyphs. Each glyph is assigned an address in the matrix, and each font matrix has a unique number assigned to it so that the RIP can assign a unique rendering matrix. Adobe could keep track of its own font identification numbers but could not control the font IDs that were assigned to TrueType fonts. If a TrueType font had the same font ID number as the Adobe Type 1 font used in a document, the RIP would establish the glyph matrix from the first font it processed and use the same matrix for the other font. So documents were rendered with one font instead of two, and the glyphs, word spacing, line endings, and page breaks were all affected and rendered incorrectly. For the most part, this problem has been sorted out with the creation of a central registry for font ID numbers; however, there are still older TrueType font files out there in the Internet universe that will generate font ID conflicts in a RIP.Adobe, Apple, and Microsoft all continued to compete for control of the desktop publishing market by trying to improve font architectures, and, as a result, many confusing systems evolved and were discarded when they caused more problems in the RIPs than they solved. There is a common font error that still causes problems when designers use Adobe Type 1 fonts or TrueType fonts. Most of these fonts only have eight-bit addressing and so can only contain 256 glyphs. A separate font file is needed to set a bold or italic version of the typeface. Some page layout programs will allow the designer to apply bold or italic attributes to the glyphs, and artificially render the bold or italic shapes in the document on the computer screen. When the document is processed in the RIP, if the font that contains the bold or italic glyphs is not present, the RIP either does not apply the attribute, or substitutes a default font (usually Courier) to alert proofreaders that there is a font error in the document. The line endings and page breaks are affected by the error — and the printing plate, signage, or printout generated becomes garbage at great expense to the industry. To solve this problem, Adobe actually cooperated with Microsoft and Apple in the development of a new font architecture. OpenType fonts have unicode addressing, which allows them to contain thousands of glyphs. Entire typeface families can be linked together to let designers seamlessly apply multiple attributes such as condensed bold italic to the typeface, and have the RIP process the document very closely to what typesetters see on their computer screen. PostScript is also the internal language of most page layout software, so the same OpenType font files are used to rasterize the glyphs to screen as the printer’s RIP is using to generate the final output. There can be significant differences in the RIP software, but many font issues are solved by using OpenType fonts for document creation. One common font error still persists in the graphic communications industry that acutely underlines the difference between creating a document on a single user’s computer but processing it through an imaging manufacturer’s workstation. Designers usually own a specific set of fonts that they use for all the documents they create. The manufacturer tries to use the exact font file each designer supplies with the document. The problem once again involves the font ID number, as each font file activated in an operating system is cached in RAM memory to make the RIP-to-screen process faster. So the font files the manufacturer receives can be different versions of the same font created at different times, but assigned the same font ID number. For example, one designer uses a 1995 version of Adobe’s Helvetica typeface and another uses a 2015 version, but the two typefaces have the same font ID number. The manufacturer’s operating system will not overwrite the first font matrix it cached in RAM, so it is the first font file that renders the document on screen and will be sent down to the RIP. Usually, there are few noticeable changes in the glyph shapes. But it is common for font foundries to adjust kerning values between letter pairs from one version to the next. So if a manufacturer has the wrong version of the font file cached in RAM, a document can have line-ending changes and page reflows. This is a hard error to catch. There are programs and routines the imaging manufacturer can implement to clear the RAM cache, but many times, more ‘garbage’ is generated before the problem is diagnosed. Modern PDF creation usually includes the production of a uniquely tagged font subset package that only contains the glyphs used in the document. The unique font subset ID avoids the potential for font ID conflicts. Managing fonts on a single user computer has its own challenges, and Apple has included Font Book with its operating systems to help manage fonts in applications on an Apple OS. Adobe offers Typekit with its latest Creative Cloud software to provide greater access to a wide variety of typefaces from a reliable foundry. Third-party font management programs like Suitcase Fusion also help graphic artists manage their fonts for repurposing their documents effectively. It is still the responsibility of individual operators to know how to use the fonts in their documents. They should also make sure that the fonts are licensed and packaged to deliver to other computer systems so that they can drive many different RIPs on a wide variety of output devices.