Inline images and Type 3 fonts

The PDF page description language consists of operators by which text, graphics and images can be placed onto a blank page. If one wants to paint a raster image onto a page then the image object is given a name and added to the page resource dictionary. The painting operator then refers to the image resource by its name. The separation between operators and resources has the advantage that the page description is short and that the resource can be reused many times, e.g. if the image represent a company logo which is used on each page of a document.

The appearance of the characters (glyphs) of a type 3 font are described with the same operator language that is used to describe the appearance of the page. The appearance of such a glyph is mostly described by a small image mask. Since a font can have many glyphs and they usually have a unique appearance these image masks cannot be reused and the overhead to put each of them in a separate resource object is high. For this and similar use cases, PDF allows for placing small images directly into the operator stream. This feature is called 'inline image'.

Some programmers now argue that these inline images are difficult to parse. Indeed, if the pixel data is a compressed then the length of this image data can only be determined if the data is decompressed by the parser. And, if the parser doesn't know the length of the data then it cannot properly find the next operator. Therefore, an optional length attribute was introduced in PDF 2.0.

However, my personal opinion is that inline images, if used carefully in situations for which they have been design for, are a useful means to reduce the size of a PDF file. Decompressing the images in the parser isn't a real problem since they are usually very small. And, the length attribute doesn't really help since it is optional. Furthermore, the feature worked for more than 20 years.