Should Type 3 Font support be dropped from the PDF Specification?

The PDF format has been around for at least 20 years now, and throughout that time it’s continued to add the latest and greatest technologies – from Unicode to OpenType – to its portfolio. This means that the range of fonts now supported are as follows:

  1. Type1
  2. MMType1
  3. Type3
  4. TrueType
  5. Type0
  6. CIDFontType0
  7. CIDFontType2
  8. Type1C
  9. CIDFontType0C
  10. OpenType

Most of the fonts we see inside PDF files are OpenType, TrueType, Type 1 or Type 1C. MMType1, Type0 and CID fonts are all extensions of those formats, which leaves Type 3 as the black sheep of the flock.

Type 3 fonts, along with Type 1 fonts, were first released in 1984 along with the PostScript specification. Type 1 offered a condensed set of PostScript operators, along with special commands for hinting, which gives the renderer some ideas of which features are most important for readability. Type 3, in contrast, offered the full range of PostScript commands but had no commands for hinting. Upon launch, Adobe released full documentation for Type 3 fonts, but kept Type 1 to themselves – they didn’t release any documentation, and used plenty of encryption on their Type 1 fonts.

This set the font world on an interesting course. Font foundries favoured Type 1 but were forced to use Type 3, Microsoft purchased a reverse engineered PostScript interpreter with Type 1 support called TrueImage, and Apple started work on a competing font format.

They later traded access to this format – TrueType – with Microsoft in exchange for a license to use TrueImage. Apple then almost immediately replaced TrueImage with an official PostScript license from Adobe, but both companies started to work on building TrueType support into their upcoming operating systems. (Both Mac OS System 7 and Windows 3.1 would feature TrueType support upon their release in 1991 and 1992 respectively.)

Adobe’s response to the looming emergence of a rival format and their loosening control over Type 1 technology was obvious – in 1990, they released the Type 1 specification to the font foundries and Type 1 quickly overtook Type 3 as the format of choice. To this day Type 1 and TrueType technology remain popular, although admittedly primarily through OpenType, which combines features from both.

Type 3, however, has all but vanished. Though it has advanced features like full colour, bitmaps and shadings, I have only ever come across six or seven Type 3 fonts, and not a single one of them used any features which can’t be matched by Type 1 fonts. In addition to this, the PDF specification lets you use text as a clip for other drawing, so any features within Type 3 fonts could be emulated within PDF files.

Realistically, I don’t expect Type 3 fonts will ever disappear from the specification – Adobe has been known to remove features from the specification, but it certainly isn’t a common occurrence. I can’t help but wonder if Type 3 adds anything, though – and if it does, I’m yet to see it.

Do you disagree? Have you used Type 3 fonts in any of your documents? Let us know in the comments!

This post is part of our “Fonts Articles Index” in these articles we explore Fonts.

If you’re a first-time reader, or simply want to be notified when we post new articles and updates, you can keep up to date by social media (Twitter, Facebook and Google+) or the Blog RSS.

Related Posts:

The following two tabs change content below.
Sam is a developer at IDRsolutions who mostly specialises in font support and conversion. He's also enjoyed working with Java 3D, Java FX and Swing. His other interests include music and game design.
SamH

About Sam Howard

Sam is a developer at IDRsolutions who mostly specialises in font support and conversion. He’s also enjoyed working with Java 3D, Java FX and Swing. His other interests include music and game design.

5 thoughts on “Should Type 3 Font support be dropped from the PDF Specification?

  1. Leo Taro

    Found your article while searching for how to implement a Type 3 font in a PDF. We sell software online. When a customer buys the software, we just take their email address so we can send them the license (payment is handled by a third party). If they want an invoice, we have a web page where they can enter their name and address and download a PDF of their invoice. The PDF is generated by a php script and only uses standard Postscript fonts (Helvetica and Courier) so they don’t have to be embedded. The PDF files are about 2.5 kilobytes.

    The problem comes when the user enters non-ascii characters in their name or address (e.g. Kanji). My understanding is that we could handle this by creating a Type 3 font and we would only have to provide bitmap representations of the characters that are actually used (using GNU Unifont Glyphs). This would keep the size of the PDF to a minimum. Is this a valid use of a Type 3 font or would there be a better way to achieve the same result?

    • It would work but the Type3 font is effectively embedded and not searchable. would personally embed an image or EPS to hold the data.

      • Leo Taro

        Thank you for your reply. I got it working using a Type 3 font. One issue is that you can select the text and copy to another document, which gives the characters you are replacing in the Type 3 font. So if you start your replacement from A, when you copy and paste “I love 日本”, you get “I love AB”.

        Then I thought about your suggestion of embedding a image for each multibyte character as I have the bitmap data anyway. The problem is that text and drawing commands have separate coordinate spaces within a PDF and there seems to be no way of getting the current text position. This means that if you have a line of text that contains both single and multibyte characters, you either have to convert the single byte characters to images as well or somehow keep track of the text position based on the width of the single bytes characters. Or were you suggesting something different?

        I think I will probably go with the type 3 font, but change the first replacement character to something after 128, so the multibyte characters look like garbage when you copy and paste them and the user will just think it is a font issue!

        • If you want to cut and paste the text, type3 is a bad choice because it lacks proper encoding.

          • Leo Taro

            I don’t want to copy and paste from the generated invoice, but it is possible a customer might try to do it.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>