Source – WIKIPEDIA

Portable document format (PDF), standardized as ISO 32000, is a file format developed by Adobe in
1992 to present documents, including text formatting and images, in a manner independent
of application software, hardware, and operating systems.[2][3] Based on the PostScript language, each
PDF file encapsulates a complete description of a fixed-layout flat document, including the
text, fonts, vector graphics, raster images and other information needed to display it. PDF has its
roots in "The Camelot Project" initiated by Adobe co-founder John Warnock in 1991.[4] PDF was
standardized as ISO 32000 in 2008.[5] The last edition as ISO 32000-2:2020 was published in
December 2020.[6]

PDF files may contain a variety of content besides flat text and graphics including logical structuring
elements, interactive elements such as annotations and form-fields, layers, rich media (including
video content), three-dimensional objects using U3D or PRC, and various other data formats. The
PDF specification also provides for encryption and digital signatures, file attachments,
and metadata to enable workflows requiring these features.

History

[edit]

Main article: History of PDF

The development of PDF began in 1991 when John Warnock wrote a paper for a project then code-
named Camelot, in which he proposed the creation of a simplified version of PostScript called
Interchange PostScript (IPS).[7] Unlike traditional PostScript, which was tightly focused on
rendering print jobs to output devices, IPS would be optimized for displaying pages to any screen and
any platform.[7]

Adobe Systems made the PDF specification available free of charge in 1993. In the early years PDF
was popular mainly in desktop publishing workflows, and competed with several other formats,
including DjVu, Envoy, Common Ground Digital Paper, Farallon Replica and even Adobe's own
PostScript format.

PDF was a proprietary format controlled by Adobe until it was released as an open standard on July
1, 2008, and published by the International Organization for Standardization as ISO 32000-
1:2008,[8][9] at which time control of the specification passed to an ISO Committee of volunteer
industry experts. In 2008, Adobe published a Public Patent License to ISO 32000-1 granting royalty-
free rights for all patents owned by Adobe necessary to make, use, sell, and distribute PDF-compliant
implementations.[10]

PDF 1.7, the sixth edition of the PDF specification that became ISO 32000-1, includes some
proprietary technologies defined only by Adobe, such as Adobe XML Forms Architecture (XFA)
and JavaScript extension for Acrobat, which are referenced by ISO 32000-1 as normative and
indispensable for the full implementation of the ISO 32000-1 specification.[11] These proprietary
technologies are not standardized, and their specification is published only on Adobe's
website.[12][13][14] Many of them are not supported by popular third-party implementations of PDF.

ISO published version 2.0 of PDF, ISO 32000-2 in 2017, available for purchase, replacing the free
specification provided by Adobe.[15] In December 2020, the second edition of PDF 2.0, ISO 32000-
2:2020, was published, with clarifications, corrections, and critical updates to normative
references[16] (ISO 32000-2 does not include any proprietary technologies as normative
references).[17] In April 2023 the PDF Association made ISO 32000-2 available for download free of
charge.[15]

Technical details

[edit]

A PDF file is often a combination of vector graphics, text, and bitmap graphics. The basic types of
content in a PDF are:

• Typeset text stored as content streams (i.e., not encoded in plain text);

• Vector graphics for illustrations and designs that consist of shapes and lines;

• Raster graphics for photographs and other types of images; and

• Other multimedia objects.

In later PDF revisions, a PDF document can also support links (inside document or web page), forms,
JavaScript (initially available as a plugin for Acrobat 3.0), or any other types of embedded contents
that can be handled using plug-ins.

PDF combines three technologies:

• An equivalent subset of the PostScript page description programming language but in

declarative form, for generating the layout and graphics.

• A font-embedding/replacement system to allow fonts to travel with the documents.

• A structured storage system to bundle these elements and any associated content into a
single file, with data compression where appropriate.

PostScript language

[edit]

PostScript is a page description language run in an interpreter to generate an image.[7] It can handle
graphics and has standard features of programming languages such as branching and looping.[7] PDF
is a subset of PostScript, simplified to remove such control flow features, while graphics commands
remain.[7]

PostScript was originally designed for a drastically different use case: transmission of one-way linear
print jobs in which the PostScript interpreter would collect a series of commands until it encountered
the showpage command, then execute all the commands to render a page as a raster image to a
printing device.[18] PostScript was not intended for long-term storage and real-time interactive
rendering of electronic documents to computer monitors, so there was no need to support anything
other than consecutive rendering of pages.[18] If there was an error in the final printed output, the
user would correct it at the application level and send a new print job in the form of an entirely new
PostScript file. Thus, any given page in a PostScript file could be accurately rendered only as the
cumulative result of executing all preceding commands to draw all previous pages—any of which
could affect subsequent pages—plus the commands to draw that particular page, and there was no
easy way to bypass that process to skip around to different pages.[18]
Traditionally, to go from PostScript to PDF, a source PostScript file (that is, an executable program) is
used as the basis for generating PostScript-like PDF code (see, e.g., Adobe Distiller). This is done by
applying standard compiler techniques like loop unrolling, inlining and removing unused branches,
resulting in code that is purely declarative and static.[18] The result is then packaged into a container
format, together with all necessary dependencies for correct rendering (external files, graphics, or
fonts to which the document refers), and compressed. Modern applications write to printer drivers
that directly generate PDF rather than going through PostScript first.

As a document format, PDF has several advantages over PostScript:

• PDF contains only static declarative PostScript code that can be processed as data, and does
not require a full program interpreter or compiler.[18] This avoids the complexity and security
risks of an engine with such a higher complexity level.

• Like Display PostScript, PDF has supported transparent graphics since version 1.4, while
standard PostScript does not.

• PDF enforces the rule that the code for any particular page cannot affect any other
pages.[18] That rule is strongly recommended for PostScript code too, but has to be
implemented explicitly (see, e.g., the Document Structuring Conventions), as PostScript is a
full programming language that allows for such greater flexibilities and is not limited to the
concepts of pages and documents.

• All data required for rendering is included within the file itself, improving portability.[19]

Its disadvantages are:

• A loss of flexibility, and limitation to a single use case.[citation needed]

• A (sometimes much) larger file size.[20]

PDF since v1.6 supports embedding of interactive 3D documents: 3D drawings can be embedded
using U3D or PRC and various other data formats.[21][22][23]

File format

[edit]

A PDF file is organized using ASCII characters, except for certain elements that may have binary
content. The file starts with a header containing a magic number (as a readable string) and the
version of the format, for example %PDF-1.7. The format is a subset of a COS ("Carousel" Object
Structure) format.[24] A COS tree file consists primarily of objects, of which there are nine types:[17]

• Boolean values, representing true or false

• Real numbers

• Integers

• Strings, enclosed within parentheses ((...)) or represented as hexadecimal within single angle
brackets (<...>). Strings may contain 8-bit characters.

• Names, starting with a forward slash (/)

• Arrays, ordered collections of objects enclosed within square brackets ([...])

 • Dictionaries, collections of objects indexed by names enclosed within double angle brackets
(<<...>>)

• Streams, usually containing large amounts of optionally compressed binary data, preceded
by a dictionary and enclosed between the stream and endstream keywords.

• The null object

Comments using 8-bit characters prefixed with the percent sign (%) may be inserted.

Objects may be either direct (embedded in another object) or indirect. Indirect objects are
numbered with an object number and a generation number and defined between
the obj and endobj keywords if residing in the document root. Beginning with PDF version 1.5,
indirect objects (except other streams) may also be located in special streams known as object
streams (marked /Type /ObjStm). This technique enables non-stream objects to have standard
stream filters applied to them, reduces the size of files that have large numbers of small indirect
objects and is especially useful for Tagged PDF. Object streams do not support specifying an
object's generation number (other than 0).

An index table, also called the cross-reference table, is located near the end of the file and gives the
byte offset of each indirect object from the start of the file.[25] This design allows for efficient random
access to the objects in the file, and also allows for small changes to be made without rewriting the
entire file (incremental update). Before PDF version 1.5, the table would always be in a special ASCII
format, be marked with the xref keyword, and follow the main body composed of indirect objects.
Version 1.5 introduced optional cross-reference streams, which have the form of a standard stream
object, possibly with filters applied. Such a stream may be used instead of the ASCII cross-reference
table and contains the offsets and other information in binary format. The format is flexible in that it
allows for integer width specification (using the /W array), so that for example, a document not
exceeding 64 KiB in size may dedicate only 2 bytes for object offsets.

At the end of a PDF file is a footer containing

• The startxref keyword followed by an offset to the start of the cross-reference table (starting
with the xref keyword) or the cross-reference stream object, followed by

• The %%EOF end-of-file marker.

If a cross-reference stream is not being used, the footer is preceded by the trailer keyword followed
by a dictionary containing information that would otherwise be contained in the cross-reference
stream object's dictionary:

• A reference to the root object of the tree structure, also known as the catalog (/Root)

• The count of indirect objects in the cross-reference table (/Size)

• Other optional information

Within each page, there are one or multiple content streams that describe the text, vector and
images being drawn on the page. The content stream is stack-based, similar to PostScript.[26]
 The maximum size of an Acrobat PDF page, superimposed
on a map of Europe.

There are two layouts to the PDF files: non-linearized (not "optimized") and linearized ("optimized").
Non-linearized PDF files can be smaller than their linear counterparts, though they are slower to
access because portions of the data required to assemble pages of the document are scattered
throughout the PDF file. Linearized PDF files (also called "optimized" or "web optimized" PDF files)
are constructed in a manner that enables them to be read in a Web browser plugin without waiting
for the entire file to download, since all objects required for the first page to display are optimally
organized at the start of the file.[27] PDF files may be optimized using Adobe Acrobat software
or QPDF.

Page dimensions are not limited by the format itself. However, Adobe Acrobat imposes a limit of 15
million by 15 million inches, or 225 trillion in2 (145,161 km2).[2]: 1129

Imaging model

[edit]

The basic design of how graphics are represented in PDF is very similar to that of PostScript, except
for the use of transparency, which was added in PDF 1.4.

PDF graphics use a device-independent Cartesian coordinate system to describe the surface of a
page. A PDF page description can use a matrix to scale, rotate, or skew graphical elements. A key
concept in PDF is that of the graphics state, which is a collection of graphical parameters that may be
changed, saved, and restored by a page description. PDF has (as of version 2.0) 25 graphics state
properties, of which some of the most important are:

• The current transformation matrix (CTM), which determines the coordinate system

• The clipping path

• The color space

• The alpha constant, which is a key component of transparency

• Black point compensation control (introduced in PDF 2.0)

Vector graphics

[edit]

As in PostScript, vector graphics in PDF are constructed with paths. Paths are usually composed of
lines and cubic Bézier curves, but can also be constructed from the outlines of text. Unlike PostScript,
PDF does not allow a single path to mix text outlines with lines and curves. Paths can be stroked,
filled, fill then stroked, or used for clipping. Strokes and fills can use any color set in the graphics
state, including patterns. PDF supports several types of patterns. The simplest is the tiling pattern in
which a piece of artwork is specified to be drawn repeatedly. This may be a colored tiling pattern,
with the colors specified in the pattern object, or an uncolored tiling pattern, which defers color
specification to the time the pattern is drawn. Beginning with PDF 1.3 there is also a shading pattern,
which draws continuously varying colors. There are seven types of shading patterns of which the
simplest are the axial shading (Type 2) and radial shading (Type 3).

Raster images

[edit]

Raster images in PDF (called Image XObjects) are represented by dictionaries with an associated
stream. The dictionary describes the properties of the image, and the stream contains the image
data. (Less commonly, small raster images may be embedded directly in a page description as
an inline image.) Images are typically filtered for compression purposes. Image filters supported in
PDF include the following general-purpose filters:

• ASCII85Decode, a filter used to put the stream into 7-bit ASCII,

• ASCIIHexDecode, similar to ASCII85Decode but less compact,

• FlateDecode, a commonly used filter based on the deflate algorithm defined

in RFC 1951 (deflate is also used in the gzip, PNG, and zip file formats among others);
introduced in PDF 1.2; it can use one of two groups of predictor functions for more compact
zlib/deflate compression: Predictor 2 from the TIFF 6.0 specification and predictors (filters)
from the PNG specification (RFC 2083),

• LZWDecode, a filter based on LZW Compression; it can use one of two groups of predictor
functions for more compact LZW compression: Predictor 2 from the TIFF 6.0 specification
and predictors (filters) from the PNG specification,

• RunLengthDecode, a simple compression method for streams with repetitive data using
the run-length encoding algorithm and the image-specific filters,

• DCTDecode, a lossy filter based on the JPEG standard,

• CCITTFaxDecode, a lossless bi-level (black/white) filter based on the Group 3 or Group

4 CCITT (ITU-T) fax compression standard defined in ITU-T T.4 and T.6,

• JBIG2Decode, a lossy or lossless bi-level (black/white) filter based on the JBIG2 standard,
introduced in PDF 1.4, and

• JPXDecode, a lossy or lossless filter based on the JPEG 2000 standard, introduced in PDF 1.5.

Normally all image content in a PDF is embedded in the file. But PDF allows image data to be stored
in external files by the use of external streams or Alternate Images. Standardized subsets of PDF,
including PDF/A and PDF/X, prohibit these features.

Text

[edit]
Text in PDF is represented by text elements in page content streams. A text element specifies
that characters should be drawn at certain positions. The characters are specified using
the encoding of a selected font resource.

A font object in PDF is a description of a digital typeface. It may either describe the characteristics of
a typeface, or it may include an embedded font file. The latter case is called an embedded font while
the former is called an unembedded font. The font files that may be embedded are based on widely
used standard digital font formats: Type 1 (and its compressed variant CFF), TrueType, and (beginning
with PDF 1.6) OpenType. Additionally PDF supports the Type 3 variant in which the components of
the font are described by PDF graphic operators.

Fourteen typefaces, known as the standard 14 fonts, have a special significance in PDF documents:

• Times (v3) (in regular, italic, bold, and bold italic)

• Courier (in regular, oblique, bold and bold oblique)

• Helvetica (v3) (in regular, oblique, bold and bold oblique)

• Symbol

• Zapf Dingbats

These fonts are sometimes called the base fourteen fonts.[28] These fonts, or suitable substitute fonts
with the same metrics, should be available in most PDF readers, but they are not guaranteed to be
available in the reader, and may only display correctly if the system has them installed.[29] Fonts may
be substituted if they are not embedded in a PDF.

Within text strings, characters are shown using character codes (integers) that map to glyphs in the
current font using an encoding. There are several predefined encodings,
including WinAnsi, MacRoman, and many encodings for East Asian languages and a font can have its
own built-in encoding. (Although the WinAnsi and MacRoman encodings are derived from the
historical properties of the Windows and Macintosh operating systems, fonts using these encodings
work equally well on any platform.) PDF can specify a predefined encoding to use, the font's built-in
encoding or provide a lookup table of differences to a predefined or built-in encoding (not
recommended with TrueType fonts).[2] The encoding mechanisms in PDF were designed for Type 1
fonts, and the rules for applying them to TrueType fonts are complex.

For large fonts or fonts with non-standard glyphs, the special encodings Identity-H (for horizontal
writing) and Identity-V (for vertical) are used. With such fonts, it is necessary to provide
a ToUnicode table if semantic information about the characters is to be preserved.

A text document which is scanned to PDF without the text being recognised by optical character
recognition (OCR) is an image, with no fonts or text properties.

Transparency

[edit]

The original imaging model of PDF was opaque, similar to PostScript, where each object drawn on
the page completely replaced anything previously marked in the same location. In PDF 1.4 the
imaging model was extended to allow transparency. When transparency is used, new objects interact
with previously marked objects to produce blending effects. The addition of transparency to PDF was
done by means of new extensions that were designed to be ignored in products written to PDF 1.3
and earlier specifications. As a result, files that use a small amount of transparency might be viewed
acceptably by older viewers, but files making extensive use of transparency could be viewed
incorrectly by an older viewer.

The transparency extensions are based on the key concepts of transparency groups, blending
modes, shape, and alpha. The model is closely aligned with the features of Adobe Illustrator version
9. The blend modes were based on those used by Adobe Photoshop at the time. When the PDF 1.4
specification was published, the formulas for calculating blend modes were kept secret by Adobe.
They have since been published.[30]

The concept of a transparency group in PDF specification is independent of existing notions of

"group" or "layer" in applications such as Adobe Illustrator. Those groupings reflect logical
relationships among objects that are meaningful when editing those objects, but they are not part of
the imaging model