PDF Reference sixth edition, Adobe Portable Document Format Version 1.7 (book 2) — page 8
883
SECTION 10.7
Tagged PDF
404 0 obj
% ID tree leaf node
<< /Limits
[
( Chap1 ) ( Sec1.3 ) ]
% Least and greatest keys in tree
/Names
[
( Chap1 ) 301 0 R
% Mapping from element identifiers
( Sec1.1 )
302 0 R
% to structure elements
( Sec1.2 )
303 0 R
( Sec1.3 )
304 0 R
]
>>
endobj
10.7
Tagged PDF
Tagged PDF (PDF 1.4) is a stylized use of PDF that builds on the logical structure
framework described in Section 10.6, “Logical Structure.” It defines a set of stan-
dard structure types and attributes that allow page content (text, graphics, and
images) to be extracted and reused for other purposes. It is intended for use by
tools that perform the following types of operations:
• Simple extraction of text and graphics for pasting into other applications
• Automatic reflow of text and associated graphics to fit a page of a different size
than was assumed for the original layout
• Processing text for such purposes as searching, indexing, and spell-checking
• Conversion to other common file formats (such as HTML, XML, and RTF)
with document structure and basic styling information preserved
• Making content accessible to users with visual impairments (see Section 10.8,
“Accessibility Support)
A tagged PDF document conforms to the following conventions:
• Page content (Section 10.7.1, “Tagged PDF and Page Content”). Tagged PDF
defines a set of rules for representing text in the page content so that characters,
words, and text order can be determined reliably. All text is represented in a
form that can be converted to Unicode. Word breaks are represented explicitly.
Actual content is distinguished from artifacts of layout and pagination. Content
is given in an order related to its appearance on the page, as determined by the
authoring application.
• A basic layout model (Section 10.7.2, “Basic Layout Model”). A set of rules for
describing the arrangement of structure elements on the page.
884
CHAPTER 10
Document Interchange
• Structure types (Section 10.7.3, “Standard Structure Types”). A set of standard
structure types define the meaning of structure elements, such as paragraphs,
headings, articles, and tables.
• Structure attributes (Section 10.7.4, “Standard Structure Attributes”). Standard
structure attributes preserve styling information used by the authoring applica-
tion in laying out content on the page.
A Tagged PDF document must also contain a mark information dictionary (see
Table 10.8) with a value of true for the Marked entry.
Note: The types and attributes defined for Tagged PDF are intended to provide a set
of standard fallback roles and minimum guaranteed attributes to enable consumer
applications to perform operations such as those mentioned above. Producer appli-
cations are free to define additional structure types as long as they also provide a
role mapping to the nearest equivalent standard types, as described in Section
10.6.2, “Structure Types.” Likewise, producer applications can define additional
structure attributes using any of the available extension mechanisms.
10.7.1
Tagged PDF and Page Content
Like all PDF documents, a Tagged PDF document consists of a sequence of self-
contained pages, each of which is described by one or more page content streams
(including any subsidiary streams such as form XObjects and annotation appear-
ances). Tagged PDF defines some further conventions for organizing and mark-
ing content streams so that additional information can be derived from them:
• Distinguishing between the author’s original content and artifacts of the layout
process (see “Real Content and Artifacts” on page 885)
• Specifying a content order to guide the layout process if the page content must
be reflowed (see “Page Content Order” on page 889)
• Representing text in a form from which a Unicode representation and informa-
tion about font characteristics can be unambiguously derived (see “Extraction
of Character Properties” on page 891)
• Representing word breaks unambiguously (see “Identifying Word Breaks” on
page 894)
• Marking text with information for making it accessible to users with visual im-
pairments (see Section 10.8, “Accessibility Support)
885
SECTION 10.7
Tagged PDF
Real Content and Artifacts
The graphics objects in a document can be divided into two classes:
• The real content of a document comprises objects representing material origi-
nally introduced by the document’s author.
• Artifacts are graphics objects that are typically not part of the author’s original
content but rather are generated by the PDF producer application in the course
of pagination, layout, or other strictly mechanical processes. Artifacts may also
be used to describe areas of the document where the author uses a graphical
background, with the goal of enhancing the visual experience. In such a case,
the background is not required for understanding the content.
The document’s logical structure encompasses all graphics objects making up the
real content and describes how those objects relate to one another. It does not in-
clude graphics objects that are mere artifacts of the layout and production pro-
cess.
A document’s real content includes not only the page content stream and subsid-
iary form XObjects but also associated annotations that meet all of the following
conditions:
• The annotation has an appearance stream (see Section 8.4.4, “Appearance
Streams”) containing a normal (N) appearance.
• The annotation’s Hidden flag (see Section 8.4.2, “Annotation Flags”) is not set.
• The annotation is included in the document’s logical structure (see Section
10.6, “Logical Structure”).
Specification of Artifacts
An artifact can be explicitly distinguished from real content by enclosing it in a
marked-content sequence with the tag Artifact:
/Artifact
/Artifact propertyList
BMC
BDC
…
or
…
EMC
EMC
886
CHAPTER 10
Document Interchange
The first form is used to identify a generic artifact; the second is used for those
that have an associated property list. Table 10.17 shows the properties that can be
included in such a property list.
Note: To aid in text reflow, it is recommended that artifacts be defined with proper-
ty lists whenever possible. Artifacts lacking a specified bounding box are likely to be
discarded during reflow.
TABLE 10.17 Property list entries for artifacts
KEY
TYPE
VALUE
Type
name
(Optional) The type of artifact that this property list describes; if present, must
be one of the names Pagination, Layout, Page, or (PDF 1.7) Background.
BBox
rectangle
(Optional; required for background artifacts) An array of four numbers in default
user space units giving the coordinates of the left, bottom, right, and top edges,
respectively, of the artifact’s bounding box (the rectangle that completely enclos-
es its visible extent).
Attached
array
(Optional; pagination and full-page background artifacts only) An array of name
objects containing one to four of the names Top, Bottom, Left, and Right, specify-
ing the edges of the page, if any, to which the artifact is logically attached. Page
edges are defined by the page’s crop box (see Section 10.10.1, “Page Bound-
aries”). The ordering of names within the array is immaterial. Including both
Left and Right or both Top and Bottom indicates a full-width or full-height arti-
fact, respectively.
Use of this entry for background artifacts is limited to full-page artifacts. Back-
ground artifacts that are not full-page take their dimensions from their parent
structural element. An example of such a background artifact is a colored back-
ground for a sidebar.
Subtype
name
(Optional; PDF 1.7) The subtype of the artifact. This entry applies only when the
Type entry has a value of Pagination. Valid values are Header, Footer, and
Watermark. Additional values can be defined for this entry, provided they com-
ply with the naming conventions described in Appendix E.
The following types of artifacts can be specified by the Type entry:
• Pagination artifacts. Ancillary page features such as running heads and folios
(page numbers).
• Layout artifacts. Purely cosmetic typographical or design elements such as
footnote rules or background screens.
887
SECTION 10.7
Tagged PDF
• Page artifacts. Production aids extraneous to the document itself, such as cut
marks and color bars.
• Background artifacts. Images, patterns or colored blocks that either run the en-
tire length and/or width of the page or the entire dimensions of a structural el-
ement. Background artifacts typically serve as a background for content shown
either on top of or placed adjacent to that background.
A background artifact can further be classified as visual content that serves to en-
hance the user experience, that lies under the actual content, and that is not re-
quired except to retain visual fidelity. Examples of this include a colored
background, pattern, blend, or image that resides under main body text. In the
case of white text on a black background, the black background is absolutely nec-
essary to be able to read the white text; however, the background itself is merely
there to enhance the visual experience. However, a draft or other identifying wa-
termark is classified as a pagination artifact because it does not serve to enhance
the experience; rather, it serves as a running artifact typically used on every page
in the document. As a further example, a Figure is distinguishable from a back-
ground artifact in that removal of the graphics objects from a Figure would de-
tract from the overall contextual understanding of the Figure as an entity.
Tagged PDF consumer applications may have their own ideas about what page
content to consider relevant. A text-to-speech engine, for instance, probably
should not speak running heads or page numbers when the page is turned. In
general, consumer applications can do any of the following:
• Disregard elements of page content (for example, specific types of artifacts)
that are not of interest
• Treat some page elements as terminals that are not to be examined further (for
example, to treat an illustration as a unit for reflow purposes)
• Replace an element with alternate text (see Section 10.8.2, “Alternate Descrip-
tions”)
Depending on their goals, different consumer applications can make different de-
cisions in this regard. The purpose of Tagged PDF is not to prescribe what the
consumer application should do, but to provide sufficient declarative and de-
scriptive information to allow it to make appropriate choices about how to pro-
cess the content.
888
CHAPTER 10
Document Interchange
Note: To support consumer applications in providing accessibility to users with dis-
abilities, Tagged PDF documents should use the natural language specification
(Lang), alternate description (Alt), replacement text (ActualText), and abbreviation
expansion text (E) facilities described in Section 10.8, “Accessibility Support.”
Incidental Artifacts
In addition to objects that are explicitly marked as artifacts and excluded from
the document’s logical structure, the running text of a page may contain other el-
ements and relationships that are not logically part of the document’s real con-
tent, but merely incidental results of the process of laying out that content into a
document. They may include the following elements:
• Hyphenation. Among the artifacts introduced by text layout is the hyphen
marking the incidental division of a word at the end of a line. In Tagged PDF,
such an incidental word division must be represented by a soft hyphen charac-
ter, which the Unicode mapping algorithm (see “Unicode Mapping in Tagged
PDF” on page 892) translates to the Unicode value U+00AD. (This character is
distinct from an ordinary hard hyphen, whose Unicode value is U+002D.) The
producer of a Tagged PDF document must distinguish explicitly between soft
and hard hyphens so that the consumer does not have to guess which type a
given character represents.
Note: In some languages, the situation is more complicated: there may be multiple
hyphen characters, and hyphenation may change the spelling of words. See Exam-
ple 10.24 on page 944.
• Text discontinuities. The running text of a page, as expressed in page content
order (see “Page Content Order,” below), may contain places where the normal
progression of text suffers a discontinuity. For example, the page may contain
the beginnings of two separate articles (see Section 8.3.2, “Articles”), each of
which is continued onto a later page of the document. The last words of the
first article appearing on the page should not be run together with the first
words of the second article. Consumer applications can recognize such discon-
tinuities by examining the document’s logical structure.
• Hidden page elements. For a variety of reasons, elements of a document’s logical
content may be invisible on the page: they may be clipped, their color may
match the background, or they may be obscured by other, overlapping objects.
Consumer applications must still be able to recognize and process such hidden
elements. For example, formerly invisible elements may become visible when a
889
SECTION 10.7
Tagged PDF
page is reflowed, or a text-to-speech engine may choose to speak text that is not
visible to a sighted reader. For the purposes of Tagged PDF, page content is con-
sidered to include all text and illustrations in their entirety, regardless of wheth-
er they are visible when the document is displayed or printed.
Page Content Order
When dealing with material on a page-by-page basis, some Tagged PDF consum-
er applications may wish to process elements in page content order, determined by
the sequencing of graphics objects within a page’s content stream and of charac-
ters within a text object, rather than in the logical structure order defined by a
depth-first traversal of the page’s logical structure hierarchy. The two orderings
are logically distinct and may or may not coincide. In particular, any artifacts the
page may contain are included in the page content order but not in the logical
structure order, since they are not considered part of the document’s logical
structure. The creator of a Tagged PDF document is responsible for establishing
both an appropriate page content order for each page and an appropriate logical
structure hierarchy for the entire document.
Because the primary requirement for page content order is to enable reflow to
maintain elements in proper reading sequence, it should normally (for Western
writing systems) proceed from top to bottom (and, in a multiple-column layout,
from column to column), with artifacts in their correct relative places. In general,
all parts of an article that appear on a given page should be kept together, even if
it flows to scattered locations on the page. Illustrations or footnotes may be inter-
spersed with the text of the associated article or may appear at the end of its con-
tent (or, in the case of footnotes, at the end of the entire page’s logical content).
In some situations, a producer that intends to generate Tagged PDF may be un-
able to generate correct page content order for part of a document’s contents. This
can occur, for example, if content was extracted from another application, or if
there are ambiguities or missing information in text output. In such cases, tag sus-
pects (PDF 1.6) can be used. The producer can identify suspect content by using
marked content (see Section 10.5, “Marked Content”) with a tag of TagSuspect, as
shown in Example 10.16. The marked content must have a properties dictionary
with an entry whose name is TagSuspect and whose value is Ordering, which in-
dicates that the ordering of the enclosed marked content does not meet Tagged
PDF specifications.
890
CHAPTER 10
Document Interchange
Example 10.16
/TagSuspect <</TagSuspect /Ordering>>
BDC
% Problem page contents
EMC
Documents containing tag suspects must contain a Suspects entry with a value of
true in the mark information dictionary (see Table 10.8). Consumer applications
encountering this entry should process the TagSuspect marked content in an
manner appropriate to their use of Tagged PDF.
Sequencing of Annotations
Annotations associated with a page are not interleaved within the page’s content
stream but are placed in the Annots array in its page object (see “Page Objects” on
page 144). Consequently, the correct position of an annotation in the page con-
tent order is not readily apparent but is determined from the document’s logical
structure.
Both page content (marked-content sequences) and annotations can be treated as
content items that are referenced from structure elements (see Section 10.6.3,
“Structure Content”). Structure elements of type Annot (PDF 1.5), Link, or Form
(see “Inline-Level Structure Elements” on page 905 and “Illustration Elements”
on page 911) explicitly specify the association between a marked-content se-
quence and a corresponding annotation. In other cases, if the structure element
corresponding to an annotation immediately precedes or follows (in the logical
structure order) a structure element corresponding to a marked-content se-
quence, the annotation is considered to precede or follow the marked-content se-
quence, respectively, in the page content order.
Note: If necessary, a Tagged PDF producer may introduce an empty marked-content
sequence solely to serve as a structure element for the purpose of positioning adja-
cent annotations in the page content order.
Reverse-Order Show Strings
In writing systems that are read from right to left (such as Arabic or Hebrew), one
might expect that the glyphs in a font would have their origins at the lower right
and their widths (rightward horizontal displacements) specified as negative. For
891
SECTION 10.7
Tagged PDF
various technical and historical reasons, however, many such fonts follow the
same conventions as those designed for Western writing systems, with glyph ori-
gins at the lower left and positive widths, as shown in Figure 5.4 on page 394.
Consequently, showing text in such right-to-left writing systems requires either
positioning each glyph individually (which is tedious and costly) or representing
text with show strings (see “Organization and Use of Fonts” on page 388) whose
character codes are given in reverse order. When the latter method is used, the
character codes’ correct page content order is the reverse of their order within the
show string.
The marked-content tag ReversedChars informs the Tagged PDF consumer appli-
cation that show strings within a marked-content sequence contain characters in
the reverse of page content order. If the sequence encompasses multiple show
strings, only the individual characters within each string are reversed; the strings
themselves are in natural reading order. For example, the sequence
/ReversedChars
BMC
( olleH ) Tj
−200 0 Td
( . dlrow ) Tj
EMC
represents the text
Hello world .
The show strings may have a space character at the beginning or end to indicate a
word break (see “Identifying Word Breaks” on page 894) but may not contain
interior spaces. This limitation is not serious, since a space provides an opportu-
nity to realign the typography without visible effect, and it serves the valuable
purpose of limiting the scope of reversals for word-processing consumer applica-
tions.
Extraction of Character Properties
It is a requirement of Tagged PDF that character codes can be unambiguously
converted to Unicode values representing the information content of the text.
There are several methods for doing this; a Tagged PDF document must conform
to at least one of them (see “Unicode Mapping in Tagged PDF,” below).
892
CHAPTER 10
Document Interchange
In addition, Tagged PDF documents must allow some characteristics of the asso-
ciated fonts to be deduced (see “Font Characteristics” on page 892). These Uni-
code values and font characteristics can then be used for such operations as cut-
and-paste editing, searching, text-to-speech conversion, and exporting to other
applications or file formats.
Unicode Mapping in Tagged PDF
Tagged PDF requires that every character code in a document can be mapped to
a corresponding Unicode value. Unicode defines scalar values for most of the
characters used in the world’s languages and writing systems, as well as providing
a private use area for application-specific characters. Information about Unicode
can be found in the Unicode Standard, by the Unicode Consortium (see the Bib-
liography).
The methods for mapping a character code to a Unicode value are described in
Section 5.9.1, “Mapping Character Codes to Unicode Values.” Tagged PDF pro-
ducers should ensure that the PDF file contains enough information to map all
character codes to Unicode by one of the methods described there.
An Alt, ActualText, or E entry specified in a structure element dictionary or a
marked-content property list
(see Sections
10.8.2,
“Alternate Descriptions,”
10.8.3, “Replacement Text,” and 10.8.4, “Expansion of Abbreviations and Acro-
nyms”) may affect the character stream that some Tagged PDF consumers actual-
ly use. For example, some consumers may choose to use the Alt or ActualText
value and ignore all text and other content associated with the structure element
and its descendants.
Some uses of Tagged PDF require characters that may not be available in all fonts,
such as the soft hyphen (see “Incidental Artifacts” on page 888). Such characters
can be represented either by adding them to the font’s encoding or CMap and
using ToUnicode to map them to appropriate Unicode values, or by using an
ActualText entry in the associated structure element to provide substitute charac-
ters.
Font Characteristics
In addition to a Unicode value, each character code in a content stream has an as-
sociated set of font characteristics. These characteristics are useful when export-
893
SECTION 10.7
Tagged PDF
ing text to another application or file format that has a limited repertoire of
available fonts.
Table 10.18 lists a common set of font characteristics corresponding to those used
in CSS and XSL; the W3C document Extensible Stylesheet Language (XSL) 1.0
provides more information (see the Bibliography). Each of the characteristics can
be derived from information available in the font descriptor’s Flags entry (see
Section 5.7.1, “Font Descriptor Flags”).
TABLE 10.18 Derivation of font characteristics
CHARACTERISTIC
TYPE
DERIVATION
Serifed
boolean
The value of the Serif flag in the font descriptor’s Flags entry
Proportional
boolean
The complement of the FixedPitch flag in the font descriptor’s Flags entry
Italic
boolean
The value of the Italic flag in the font descriptor’s Flags entry
Smallcap
boolean
The value of the SmallCap flag in the font descriptor’s Flags entry
Note: The characteristics shown in the table apply only to character codes con-
tained in show strings within content streams. They do not exist for alternate de-
scription text (Alt), replacement text (ActualText), or abbreviation expansion text
(E).
Note: For the standard 14 Type 1 fonts, the font descriptor may be missing; the well-
known values for those fonts are used.
Tagged PDF in PDF 1.5 defines a wider set of font characteristics, which provide
information needed when converting PDF to other files formats such as RTF,
HTML, XML, and OEB, and also improve accessibility and reflow of tables.
Table 10.19 lists these font selector attributes and shows how their values are de-
rived.
Note: If the FontFamily, FontWeight and FontStretch fields are not present in the font de-
scriptor, these values are derived from the font name in an implementation-defined
manner.
894
CHAPTER 10
Document Interchange
TABLE 10.19 Font Selector Attributes
ATTRIBUTE
DESCRIPTION
FontFamily
A string specifying the preferred font family name. Derived from the FontFamily entry
in the font descriptor (see Table 5.19 on page 456).
GenericFontFamily
A general font classification, used if FontFamily is not found. The following values are
supported; with two exceptions, they can be derived from the font descriptor’s Flags en-
try:
• Serif: Chosen if the Serif flag is set and the FixedPitch and Script flags are not set
• SansSerif: Chosen if the FixedPitch, Script and Serif flags are all not set
• Cursive: Chosen if the Script flag is set and the FixedPitch flag is not set
• Monospace: Chosen if the FixedPitch flag is set
• Decorative: Cannot be derived
• Symbol: Cannot be derived
FontSize
The size of the font: a positive fixed-point number specifying the height of the typeface
in points. It is derived from the a, b, c, and d fields of the current text matrix.
FontStretch
The stretch value of the font. It can be derived from FontStretch in the font descriptor
(see Table 5.19 on page 456).
FontStyle
The italicization value of the font. It is set to Italic if the Italic flag is set in the Flags field
of the font descriptor. Otherwise, it is set to Normal.
FontVariant
The small-caps value of the font. It is set to SmallCaps if the SmallCap flag is set in the
Flags field of the font descriptor. Otherwise, it is set to Normal.
FontWeight
The weight (thickness) value of the font. It can be derived from FontWeight in the font
descriptor (see Table 5.19 on page 456).
The ForceBold flag and the StemV field should not be used to set this attribute.
Identifying Word Breaks
A document’s text stream defines not only the characters in a page’s text but also
the words. Unlike a character, the notion of a word is not precisely defined but
depends on the purpose for which the text is being processed. A reflow tool needs
to determine where it can break the running text into lines; a text-to-speech en-
gine needs to identify the words to be vocalized; spelling checkers and other ap-
895
SECTION 10.7
Tagged PDF
plications all have their own ideas of what constitutes a word. It is not important
for a Tagged PDF document to identify the words within the text stream accord-
ing to a single, unambiguous definition that satisfies all of these clients. What is
important is that there be enough information available for each client to make
that determination for itself.
The consumer of a Tagged PDF document finds words by sequentially examining
the Unicode character stream, perhaps augmented by replacement text specified
with ActualText (see Section 10.8.3, “Replacement Text”). The consumer does not
need to guess about word breaks based on information such as glyph positioning
on the page, font changes, or glyph sizes. The main consideration is to ensure that
the spacing characters that would be present to separate words in a pure text rep-
resentation are also present in the Tagged PDF.
Note that the identification of what constitutes a word is unrelated to how the text
happens to be grouped into show strings. The division into show strings has no
semantic significance. In particular, a space or other word-breaking character is
still needed even if a word break happens to fall at the end of a show string.
Note: Some applications may identify words by simply separating them at every
space character. Others may be slightly more sophisticated and treat punctuation
marks such as hyphens or em dashes as word separators as well. Still other applica-
tions may identify possible line-break opportunities by using an algorithm similar to
the one in Unicode Standard Annex #29, Text Boundaries, available from the Uni-
code Consortium (see the Bibliography).
10.7.2
Basic Layout Model
Tagged PDF’s standard structure types and attributes are interpreted in the con-
text of a basic layout model that describes the arrangement of structure elements
on the page. This model is designed to capture the general intent of the docu-
ment’s underlying structure and does not necessarily correspond to the one actu-
ally used for page layout by the application creating the document. (The PDF
content stream specifies the exact appearance.) The goal is to provide sufficient
information for Tagged PDF consumers to make their own layout decisions while
preserving the authoring application’s intent as closely as their own layout models
allow.
Note: The Tagged PDF layout model resembles the ones used in markup languages
such as HTML, CSS, XSL, and RTF, but does not correspond exactly to any of them.
896
CHAPTER 10
Document Interchange
The model is deliberately defined loosely to allow reasonable latitude in the interpre-
tation of structure elements and attributes when converting to other document for-
mats. Some degree of variation in the resulting layout from one format to another is
to be expected.
The basic layout model begins with the notion of a reference area. This is a rect-
angular region used by the layout application as a frame or guide in which to
place the document’s content. Some of the standard structure attributes, such as
StartIndent and EndIndent (see “Layout Attributes for BLSEs” on page 922), are
measured from the boundaries of the reference area. Reference areas are not
specified explicitly but are inferred from context. Those of interest are generally
the column area or areas in a general text layout, the outer bounding box of a
table and those of its component cells, and the bounding box of an illustration or
other floating element.
The standard structure types are divided into four main categories according to
the roles they play in page layout:
• Grouping elements (see “Grouping Elements” on page 899) group other ele-
ments into sequences or hierarchies but hold no content directly and have no
direct effect on layout.
• Block-level structure elements (BLSEs) (see “Block-Level Structure Elements” on
page 901) describe the overall layout of content on the page, proceeding in the
block-progression direction.
• Inline-level structure elements (ILSEs) (see “Inline-Level Structure Elements” on
page 905) describe the layout of content within a BLSE, proceeding in the in-
line-progression direction.
• Illustration elements (see “Illustration Elements” on page 911) are compact se-
quences of content, in page content order, that are considered to be unitary ob-
jects with respect to page layout. An illustration can be treated as either a BLSE
or an ILSE.
The meaning of the terms block-progression direction and inline-progression
direction depends on the writing system in use, as specified by the standard
attribute WritingMode (see “General Layout Attributes” on page 917). In Western
writing systems, the block direction is from top to bottom and the inline direc-
tion is from left to right. Other writing systems use different directions for laying
out content.
897
SECTION 10.7
Tagged PDF
Because the progression directions can vary depending on the writing system,
edges of areas and directions on the page must be identified by terms that are
neutral with respect to the progression order rather than by familiar terms such
as up, down, left, and right. Block layout proceeds from before to after, inline
from start to end. Thus, for example, in Western writing systems, the before and
after edges of a reference area are at the top and bottom, respectively, and the
start and end edges are at the left and right. Another term, shift direction (the
direction of shift for a superscript), refers to the direction opposite that for block
progression—that is, from after to before (in Western writing systems, from bot-
tom to top).
BLSEs are stacked within a reference area in block-progression order. In general,
the first BLSE is placed against the before edge of the reference area. Subsequent
BLSEs are stacked against preceding ones, progressing toward the after edge, until
no more BLSEs fit in the reference area. If the overflowing BLSE allows itself to be
split—such as a paragraph that can be split between lines of text—a portion of it
may be included in the current reference area and the remainder carried over to a
subsequent reference area (either elsewhere on the same page or on another page
of the document). Once the amount of content that fits in a reference area is de-
termined, the placements of the individual BLSEs may be adjusted to bias the
placement toward the before edge, the middle, or the after edge of the reference
area, or the spacing within or between BLSEs may be adjusted to fill the full ex-
tent of the reference area.
Note: BLSEs may be nested, with child BLSEs stacked within a parent BLSE in the
same manner as BLSEs within a reference area. Except in a few instances noted
below (the BlockAlign and InlineAlign elements), such nesting of BLSEs does not re-
sult in the nesting of reference areas; a single reference area prevails for all levels of
nested BLSEs.
Within a BLSE, child ILSEs are packed into lines. (Direct content items—those that
are immediate children of a BLSE rather than contained within a child ILSE—are
implicitly treated as ILSEs for packing purposes.) Each line is treated as a synthe-
sized BLSE and is stacked within the parent BLSE. Lines may be intermingled
with other BLSEs within the parent area. This line-building process is analogous
to the stacking of BLSEs within a reference area, except that it proceeds in the
inline-progression rather than the block-progression direction: a line is packed
with ILSEs beginning at the start edge of the containing BLSE and continuing
until the end edge is reached and the line is full. The overflowing ILSE may allow
itself to be broken at linguistically determined or explicitly marked break points
898
CHAPTER 10
Document Interchange
(such as hyphenation points within a word), and the remaining fragment is car-
ried over to the next line.
Note: Certain values of an element’s Placement attribute remove the element from
the normal stacking or packing process and allow it instead to float to a specified
edge of the enclosing reference area or parent BLSE; see “General Layout Attributes”
on page 917 for further discussion.
Two enclosing rectangles are associated with each BLSE and ILSE (including
direct content items that are treated implicitly as ILSEs):
• The content rectangle is derived from the shape of the enclosed content and
defines the bounds used for the layout of any included child elements.
• The allocation rectangle includes any additional borders or spacing surround-
ing the element, affecting how it is positioned with respect to adjacent elements
and the enclosing content rectangle or reference area.
The definitions of these rectangles are determined by layout attributes associated
with the structure element; see “Content and Allocation Rectangles” on page 930
for further discussion.
10.7.3
Standard Structure Types
Tagged PDF’s standard structure types characterize the role of a content element
within the document and, in conjunction with the standard structure attributes
(described in Section 10.7.4, “Standard Structure Attributes”), how that content is
laid out on the page. As discussed in Section 10.6.2, “Structure Types,” the struc-
ture type of a logical structure element is specified by the S entry in its structure
element dictionary. To be considered a standard structure type, this value must be
either:
• One of the standard structure type names described below.
• An arbitrary name that is mapped to one of the standard names by the docu-
ment’s role map (see Section 10.6.2, “Structure Types”), possibly through multi-
ple levels of mapping.
Note: Beginning with PDF 1.5, an element name is always mapped to its corre-
sponding name in the role map, if there is one, even if the original name is one of the
standard types. This is done to allow the element, for example, to represent a tag
with the same name as a standard role, even though its use differs from the standard
role.
899
SECTION 10.7
Tagged PDF
Ordinarily, structure elements having standard structure types are processed the
same way whether the type is expressed directly or is determined indirectly from
the role map. However, some consumer applications may ascribe additional se-
mantics to nonstandard structure types, even though the role map associates
them with standard ones. For instance, the actual values of the S entries may be
used when exporting to a tagged representation such as XML, and the corre-
sponding role-mapped values are used when converting to presentation formats
such as HTML or RTF, or for purposes such as reflow or accessibility to users
with disabilities.
Note: Most of the standard element types are designed primarily for laying out text;
the terminology reflects this usage. However, a layout can in fact include any type of
content, such as path or image objects. The content items associated with a structure
element are laid out on the page as if they were blocks of text (for a BLSE) or charac-
ters within a line of text (for an ILSE).
Grouping Elements
Grouping elements are used solely to group other structure elements; they are not
directly associated with content items. Table 10.20 describes the standard struc-
ture types for elements in this category. Section G.7, “Structured Elements That
Describe Hierarchical Lists” provides an example of nested table of content items.
For most content extraction formats, the document must be a tree with a single
top-level element; the structure tree root (identified by the StructTreeRoot entry
in the document catalog) must have only one child in its K (kids) array. If the PDF
file contains a complete document, the structure type Document is recommended
for this top-level element in the logical structure hierarchy. If the file contains a
well-formed document fragment, one of the structure types Part, Art, Sect, or Div
may be used instead.
TABLE 10.20 Standard structure types for grouping elements
STRUCTURE TYPE DESCRIPTION
Document
(Document) A complete document. This is the root element of any structure tree containing
multiple parts or multiple articles.
Part
(Part) A large-scale division of a document. This type of element is appropriate for grouping
articles or sections.
900
CHAPTER 10
Document Interchange
STRUCTURE TYPE
DESCRIPTION
Art
(Article) A relatively self-contained body of text constituting a single narrative or exposition.
Articles should be disjoint; that is, they should not contain other articles as constituent ele-
ments.
Sect
(Section) A container for grouping related content elements. For example, a section might
contain a heading, several introductory paragraphs, and two or more other sections nested
within it as subsections.
Div
(Division) A generic block-level element or group of elements.
BlockQuote
(Block quotation) A portion of text consisting of one or more paragraphs attributed to some-
one other than the author of the surrounding text.
Caption
(Caption) A brief portion of text describing a table or figure.
TOC
(Table of contents) A list made up of table of contents item entries (structure type TOCI; see
below) and/or other nested table of contents entries (TOC).
A TOC entry that includes only TOCI entries represents a flat hierarchy. A TOC entry that in-
cludes other nested TOC entries (and possibly TOCI entries) represents a more complex hier-
archy. Ideally, the hierarchy of a top level TOC entry reflects the structure of the main body of
the document.
Note: Lists of figures and tables, as well as bibliographies, can be treated as tables of contents for
purposes of the standard structure types.
TOCI
(Table of contents item) An individual member of a table of contents. This entry’s children
can be any of the following structure types:
Lbl
A label (see “List Elements” on page 902)
Reference A reference to the title and the page number (see “Inline-Level Structure
Elements” on page 905)
NonStruct Non-structure elements for wrapping a leader artifact
(see
“Grouping
Elements” on page 899).
P
Descriptive text (see “Paragraphlike Elements” on page 902)
TOC
Table of content elements for hierarchical tables of content, as described for
the TOC entry
Index
(Index) A sequence of entries containing identifying text accompanied by reference ele-
ments (structure type Reference; see “Inline-Level Structure Elements” on page 905) that
point out occurrences of the specified text in the main body of a document.
901
SECTION 10.7
Tagged PDF
STRUCTURE TYPE DESCRIPTION
NonStruct
(Nonstructural element) A grouping element having no inherent structural significance; it
serves solely for grouping purposes. This type of element differs from a division (structure
type Div; see above) in that it is not interpreted or exported to other document formats; how-
ever, its descendants are to be processed normally.
Private
(Private element) A grouping element containing private content belonging to the applica-
tion producing it. The structural significance of this type of element is unspecified and is de-
termined entirely by the producer application. Neither the Private element nor any of its
descendants are to be interpreted or exported to other document formats.
Block-Level Structure Elements
A block-level structure element (BLSE) is any region of text or other content that is
laid out in the block-progression direction, such as a paragraph, heading, list
item, or footnote. A structure element is a BLSE if its structure type (after role
mapping, if any) is one of those listed in Table 10.21. All other standard structure
types are treated as ILSEs, with the following exceptions:
• TR (Table row), TH (Table header), TD (Table data), THead (Table head), TBody
(Table body), and TFoot (Table footer), which are used to group elements with-
in a table and are considered neither BLSEs nor ILSEs
• Elements with a Placement attribute (see “General Layout Attributes” on page
917) other than the default value of Inline
TABLE 10.21 Block-level structure elements
CATEGORY
STRUCTURE TYPES
Paragraphlike elements
P
H1
H4
H
H2
H5
H3
H6
List elements
L
Lbl
LI
LBody
Table element
Table
In many cases, a BLSE appears as one compact, contiguous piece of page content;
in other cases, it is discontiguous. Examples of the latter include a BLSE that
extends across a page boundary or is interrupted in the page content order by
another, nested BLSE or a directly included footnote. When necessary, Tagged
902
CHAPTER 10
Document Interchange
PDF consumer applications can recognize such fragmented BLSEs from the logi-
cal structure and use this information to reassemble them and properly lay them
out.
Paragraphlike Elements
Table 10.22 describes structure types for paragraphlike elements that consist of
running text and other content laid out in the form of conventional paragraphs
(as opposed to more specialized layouts such as lists and tables).
TABLE 10.22 Standard structure types for paragraphlike elements
STRUCTURE TYPE
DESCRIPTION
H
(Heading) A label for a subdivision of a document’s content. It should be the first child of
the division that it heads.
H1-H6
Headings with specific levels, for use in applications that cannot hierarchically nest their
sections and thus cannot determine the level of a heading from its level of nesting.
P
(Paragraph) A low-level division of text.
List Elements
The structure types described in Table 10.23 are used for organizing the content
of lists. Section G.7, “Structured Elements That Describe Hierarchical Lists” pro-
vides an example of nested list entries.
TABLE 10.23 Standard structure types for list elements
STRUCTURE TYPE
DESCRIPTION
L
(List) A sequence of items of like meaning and importance. Its immediate children should
be an optional caption (structure type Caption; see “Grouping Elements” on page 899) fol-
lowed by one or more list items (structure type LI; see below).
LI
(List item) An individual member of a list. Its children may be one or more labels, list bod-
ies, or both (structure types Lbl or LBody; see below).
Lbl
(Label) A name or number that distinguishes a given item from others in the same list or
other group of like items. In a dictionary list, for example, it contains the term being de-
fined; in a bulleted or numbered list, it contains the bullet character or the number of the
list item and associated punctuation.
903
SECTION 10.7
Tagged PDF
STRUCTURE TYPE
DESCRIPTION
LBody
(List body) The descriptive content of a list item. In a dictionary list, for example, it con-
tains the definition of the term. It can either contain the content directly or have other
BLSEs, perhaps including nested lists, as children.
Table Elements
The structure types described in Table 10.24 are used for organizing the content
of tables.
Note: Strictly speaking, the Table element is a BLSE; the others in this table are nei-
ther BLSEs or ILSEs.
TABLE 10.24 Standard structure types for table elements
STRUCTURE TYPE
DESCRIPTION
Table
(Table) A two-dimensional layout of rectangular data cells, possibly having a complex sub-
structure. It contains either one or more table rows (structure type TR; see below) as chil-
dren; or an optional table head (structure type THead; see below) followed by one or more
table body elements (structure type TBody; see below) and an optional table footer (struc-
ture type TFoot; see below). In addition, a table may have an optional caption (structure
type Caption; see “Grouping Elements” on page 899) as its first or last child.
TR
(Table row) A row of headings or data in a table. It may contain table header cells and table
data cells (structure types TH and TD; see below).
TH
(Table header cell) A table cell containing header text describing one or more rows or col-
umns of the table.
TD
(Table data cell) A table cell containing data that is part of the table’s content.
THead
(Table header row group; PDF 1.5) A group of rows that constitute the header of a table. If
the table is split across multiple pages, these rows may be redrawn at the top of each table
fragment (although there is only one THead element).
TBody
(Table body row group; PDF 1.5) A group of rows that constitute the main body portion of
a table. If the table is split across multiple pages, the body area may be broken apart on a
row boundary. A table may have multiple TBody elements to allow for the drawing of a
border or background for a set of rows.
Note: (Table footer row group; PDF 1.5) A group of rows that constitute the footer of a ta-
TFoot
ble. If the table is split across multiple pages, these rows may be redrawn at the bottom of
each table fragment (although there is only one TFoot element.)
904
CHAPTER 10
Document Interchange
Note: The association of headers with rows and columns of data is typically deter-
mined heuristically by applications. Such heuristics may fail for complex tables; the
standard attributes for tables shown in Table 10.36 can be used to make the associa-
tion explicit.
Usage Guidelines for Block-Level Structure
Because different consumer applications use PDF’s logical structure facilities in
different ways, Tagged PDF does not enforce any strict rules regarding the order
and nesting of elements using the standard structure types. Furthermore, each
export format has its own conventions for logical structure. However, adhering to
certain general guidelines helps to achieve the most consistent and predictable in-
terpretation among different Tagged PDF consumers.
As described under “Grouping Elements” on page 899, a Tagged PDF document
can have one or more levels of grouping elements, such as Document, Part, Art
(Article), Sect (Section), and Div (Division). The descendants of these are BLSEs,
such as H (Heading), P (Paragraph), and L (List), that hold the actual content.
Their descendants, in turn, are either content items or ILSEs that further describe
the content.
Note: As noted earlier, elements with structure types that would ordinarily be treat-
ed as ILSEs can have a Placement attribute (see “General Layout Attributes” on
page 917) that causes them to be treated as BLSEs instead. Such elements may be in-
cluded as BLSEs in the same manner as headings and paragraphs.
The block-level structure can follow one of two principal paradigms:
• Strongly structured. The grouping elements nest to as many levels as necessary
to reflect the organization of the material into articles, sections, subsections,
and so on. At each level, the children of the grouping element consist of a head-
ing (H), one or more paragraphs (P) for content at that level, and perhaps one or
more additional grouping elements for nested subsections.
• Weakly structured. The document is relatively flat, having perhaps only one or
two levels of grouping elements, with all the headings, paragraphs, and other
BLSEs as their immediate children. In this case, the organization of the material
is not reflected in the logical structure; however, it can be expressed by the use
of headings with specific levels (H1-H6).
905
SECTION 10.7
Tagged PDF
The strongly structured paradigm is used by some rich document models based
on XML. The weakly structured paradigm is typical of documents represented in
HTML.
Lists and tables should be organized using the specific structure types described
under “List Elements” on page 902 and “Table Elements” on page 903. Likewise,
tables of contents and indexes should be structured as described for the TOC and
Index structure types under “Grouping Elements” on page 899.
Inline-Level Structure Elements
An inline-level structure element (ILSE) contains a portion of text or other content
having specific styling characteristics or playing a specific role in the document.
Within a paragraph or other block defined by a containing BLSE, consecutive
ILSEs—possibly intermixed with other content items that are direct children of
the parent BLSE—are laid out consecutively in the inline-progression direction
(left to right in Western writing systems). The resulting content may be broken
into multiple lines, which in turn are stacked in the block-progression direction.
It is possible for an ILSE in turn to contain a BLSE, which is treated as a unitary
item of layout in the inline direction. Table 10.25 lists the standard structure types
for ILSEs.
TABLE 10.25 Standard structure types for inline-level structure elements
STRUCTURE TYPE
DESCRIPTION
Span
(Span) A generic inline portion of text having no particular inherent characteristics. It can
be used, for example, to delimit a range of text with a given set of styling attributes.
Note: Not all inline style changes need to be identified as a span. Text color and font changes
(including modifiers such as bold, italic, and small caps) need not be so marked, since these
can be derived from the PDF content (see “Font Characteristics” on page 892). However, it is
necessary to use a span to apply explicit layout attributes such as LineHeight, BaselineShift, or
TextDecorationType (see “Layout Attributes for ILSEs” on page 926).
Note: Marked-content sequences having the tag Span are also used to carry certain accessibil-
ity properties (Alt, ActualText, Lang, and E; see Section 10.8, “Accessibility Support”). Such se-
quences lack an MCID property and are not associated with any structure element. This use of
the Span marked-content tag is distinct from its use as a structure type.
906
CHAPTER 10
Document Interchange
STRUCTURE TYPE
DESCRIPTION
Quote
(Quotation) An inline portion of text attributed to someone other than the author of the
surrounding text.
Note: The quoted text is contained inline within a single paragraph. This differs from the
block-level element BlockQuote (see “Grouping Elements” on page 899), which consists of one
or more complete paragraphs (or other elements presented as if they were complete para-
graphs).
Note
(Note) An item of explanatory text, such as a footnote or an endnote, that is referred to
from within the body of the document. It may have a label (structure type Lbl; see “List El-
ements” on page 902) as a child. The note may be included as a child of the structure ele-
ment in the body text that refers to it, or it may be included elsewhere (such as in an
endnotes section) and accessed by means of a reference (structure type Reference; see be-
low).
Note: Tagged PDF does not prescribe the placement of footnotes in the page content order.
They can be either inline or at the end of the page, at the discretion of the producer applica-
tion.
Reference
(Reference) A citation to content elsewhere in the document.
BibEntry
(Bibliography entry) A reference identifying the external source of some cited content. It
may contain a label (structure type Lbl; see “List Elements” on page 902) as a child.
Note: Although a bibliography entry is likely to include component parts identifying the cited
content’s author, work, publisher, and so forth, no standard structure types are defined at this
level of detail at the time of publication.
Code
(Code) A fragment of computer program text.
Link
(Link) An association between a portion of the ILSE’s content and a corresponding link
annotation or annotations (see “Link Annotations” on page 622). Its children are one or
more content items or child ILSEs and one or more object references (see “PDF Objects as
Content Items” on page 868) identifying the associated link annotations. See “Link Ele-
ments,” below, for further discussion.
Annot
(Annotation; PDF 1.5) An association between a portion of the ILSE’s content and a corre-
sponding PDF annotation (see Section 8.4, “Annotations”). Annot is used for all PDF an-
notations except link annotations (see the Link element, above) and widget annotations
(see the Form element in Table 10.27 on page 912). See “Annotation Elements” on page 909
for further discussion.
907
SECTION 10.7
Tagged PDF
STRUCTURE TYPE
DESCRIPTION
Ruby
(Ruby; PDF 1.5) A side-note (annotation) written in a smaller text size and placed adjacent
to the base text to which it refers. It is used in Japanese and Chinese to describe the pro-
nunciation of unusual words or to describe such items as abbreviations and logos. A Ruby
element may also contain the RB, RT, and RP elements. See “Ruby and Warichu Elements”
on page 910 for more details.
Warichu
(Warichu; PDF 1.5) A comment or annotation in a smaller text size and formatted onto
two smaller lines within the height of the containing text line and placed following (inline)
the base text to which it refers. It is used in Japanese for descriptive comments and for ruby
annotation text that is too long to be aesthetically formatted as a ruby. A Warichu element
may also contain the WT and WP elements. See “Ruby and Warichu Elements” on page 910
for more details.
Link Elements
Link annotations (like all PDF annotations) are associated with a geometric
region of the page rather than with a particular object in its content stream. Any
connection between the link and the content is based solely on visual appearance
rather than on an explicitly specified association. For this reason, link annota-
tions alone are not useful to users with visual impairments or to applications
needing to determine which content can be activated to invoke a hypertext link.
Tagged PDF link elements (structure type Link) use PDF’s logical structure facili-
ties to establish the association between content items and link annotations, pro-
viding functionality comparable to HTML hypertext links. The following items
can be children of a link element:
• One or more content items or other ILSEs (except other links)
• Object references (see “PDF Objects as Content Items” on page 868) to one or
more link annotations associated with the content
A link element may contain several link annotations if the geometry of the
content requires it. For instance, if a span of text wraps from the end of one line to
the beginning of another, separate link annotations may be needed to cover the
two portions of text. All of the child link annotations must have the same target
and action. To maintain a geometric association between the content and the an-
notation that is consistent with the logical association, all of the link element’s
content must be covered by the union of its child link annotations.
908
CHAPTER 10
Document Interchange
As an example, consider the following fragment of HTML code, which produces
a line of text containing a hypertext link:
< html >
< body >
< p >
Here is some text < a href = http : / / www. adobe . com >with a link< /a > inside .
< /body >
< /html >
Example 10.17 shows an equivalent fragment of PDF using a link element, whose
text it displays in blue and underlined. Example 10.18 shows an excerpt from the
associated logical structure hierarchy.
Example 10.17
/P << /MCID 0 >>
% Marked-content sequence 0 (paragraph)
BDC
% Begin marked-content sequence
BT
% Begin text object
/T1_0 1 Tf
% Set text font and size
14 0 0 14 10.000 753.976 Tm
% Set text matrix
0.0
0.0
0.0 rg
% Set nonstroking color to black
( Here is some text ) Tj
% Show text preceding link
ET
% End text object
EMC
% End marked-content sequence
/Link << /MCID 1 >>
% Marked-content sequence 1 (link)
BDC
% Begin marked-content sequence
0.7 w
% Set line width
[ ]
0 d
% Solid dash pattern
111.094 751.8587 m
% Move to beginning of underline
174.486 751.8587 l
% Draw underline
0.0
0.0
1.0 RG
% Set stroking color to blue
S
% Stroke underline
BT
% Begin text object
14 0 0 14 111.094 753.976 Tm
% Set text matrix
0.0
0.0
1.0 rg
% Set nonstroking color to blue
( with a link ) Tj
% Show text of link
ET
% End text object
EMC
% End marked-content sequence
909
SECTION 10.7
Tagged PDF
/P << /MCID 2 >>
% Marked-content sequence 2 (paragraph)
BDC
% Begin marked-content sequence
BT
% Begin text object
14 0 0 14 174.486
753.976
Tm
% Set text matrix
0.0
0.0
0.0 rg
% Set nonstroking color to black
( inside . ) Tj
% Show text following link
ET
% End text object
EMC
% End marked-content sequence
Example 10.18
501 0 obj
% Structure element for paragraph
<< /Type /StructElem
/S /P
/K [
0
% Three children: marked-content sequence 0
502 0 R
% Link
2
% Marked-content sequence 2
]
>>
endobj
502 0 obj
% Structure element for link
<< /Type /StructElem
/S /Link
/K [
1
% Two children: marked-content sequence 1
503 0 R
% Object reference to link annotation
]
>>
endobj
503 0 obj
% Object reference to link annotation
<< /Type /OBJR
/Obj 600 0 R
% Link annotation (not shown)
>>
endobj
Annotation Elements
Tagged PDF annotation elements (structure type Annot; PDF 1.5) use PDF’s logi-
cal structure facilities to establish the association between content items and PDF
annotations. Annotation elements are used for all types of annotations other than
links (see “Link Elements” on page 907) and forms (see Table 10.27 on page 912).
910
CHAPTER 10
Document Interchange
The following items can be children of an annotation element:
• Object references (see “PDF Objects as Content Items” on page 868) to one or
more annotation dictionaries
• Optionally, one or more content items (such as marked-content sequences) or
other ILSEs (except other annotations) associated with the annotations
If an Annot element has no children other than object references, its rendering is
defined by the appearance of the referenced annotations, and its text content is
treated as if it were a Span element. It may have an optional BBox attribute; if sup-
plied, this attribute overrides the rectangle specified by the annotation dictio-
nary’s Rect entry.
If the Annot element has children that are content items, those children represent
the displayed form of the annotation, and the appearance of the associated anno-
tation may also be applied (for example, with a Highlight annotation).
There can be multiple children that are object references to different annotations,
subject to the constraint that the annotations must be the same except for their
Rect entry. This is much the same as is done for the Link element; it allows an an-
notation to be associated with discontiguous pieces of content, such as line-
wrapped text.
Ruby and Warichu Elements
Ruby text is a side note, written in a smaller text size and placed adjacent to the
base text to which it refers. It is used in Japanese and Chinese to describe the pro-
nunciation of unusual words or to describe such items as abbreviations and logos.
Warichu text is a comment or annotation, written in a smaller text size and for-
matted onto two smaller lines within the height of the containing text line and
placed following (inline) the base text to which it refers. It is used in Japanese for
descriptive comments and for ruby annotation text that is too long to be aestheti-
cally formatted as a ruby.
911
SECTION 10.7
Tagged PDF
TABLE 10.26 Standard structure types for Ruby and Warichu elements (PDF 1.5)
STRUCTURE TYPE
DESCRIPTION
Ruby
(Ruby) The wrapper around the entire ruby assembly. It contains one RB element followed
by either an RT element or a three-element group consisting of RP, RT, and RP. Ruby ele-
ments and their content elements may not break across multiple lines.
RB
(Ruby base text) The full-size text to which the ruby annotation is applied. RB can contain
text, other inline elements, or a mixture of both. It may have the RubyAlign attribute.
RT
(Ruby annotation text) The smaller-size text that is placed adjacent to the ruby base text. It
can contain text, other inline elements, or a mixture of both. It may have the RubyAlign
and RubyPosition attributes.
RP
(Ruby punctuation) Punctuation surrounding the ruby annotation text. It us used only
when a ruby annotation cannot be properly formatted in a ruby style and instead is for-
matted as a normal comment, or when it is formatted as a warichu. It contains text (usual-
ly a single open or close parenthesis or similar bracketing character).
Warichu
(Warichu) The wrapper around the entire warichu assembly. It may contain a three-ele-
ment group consisting of WP, WT, and WP. Warichu elements (and their content elements)
may wrap across multiple lines, according to the warichu breaking rules described in the
Japanese Industrial Standard (JIS) X 4051-1995.
WT
(Warichu text) The smaller-size text of a warichu comment that is formatted into two lines
and placed between surrounding WP elements.
WP
(Warichu punctuation) The punctuation that surrounds the WT text. It contains text (usu-
ally a single open or close parenthesis or similar bracketing character). According to JIS X
4051-1995, the parentheses surrounding a warichu may be converted to a space (nominal-
ly 1/4 EM in width) at the discretion of the formatter.
Illustration Elements
Tagged PDF defines an illustration element as any structure element whose struc-
ture type (after role mapping, if any) is one of those listed in Table 10.27. The il-
lustration’s content must consist of one or more complete graphics objects. It may
not appear between the BT and ET operators delimiting a text object (see Section
5.3, “Text Objects”). It may include clipping only in the form of a contained
marked clipping sequence, as defined in Section 10.5.2, “Marked Content and
Clipping.” In Tagged PDF, all such marked clipping sequences must carry the
marked-content tag Clip.
912
CHAPTER 10
Document Interchange
TABLE 10.27 Standard structure types for illustration elements
STRUCTURE TYPE
DESCRIPTION
Figure
(Figure) An item of graphical content. Its placement may be specified with the Placement
layout attribute (see “General Layout Attributes” on page 917).
Formula
(Formula) A mathematical formula.
Note: This structure type is useful only for identifying an entire content element as a formula.
No standard structure types are defined for identifying individual components within the for-
mula. From a formatting standpoint, the formula is treated similarly to a figure (structure
type Figure; see above).
Form
(Form) A widget annotation representing an interactive form field (see Section 8.6, “Inter-
active Forms”). If the element contains a Role attribute, it may contain content items that
represent the value of the (non-interactive) form field. If the element omits a Role attribute
(see Table 10.35 on page 934), its only child is an object reference (see “PDF Objects as
Content Items” on page 868) identifying the widget annotation. The annotations’ appear-
ance stream (see “Appearance Streams” on page 612) defines the rendering of the form ele-
ment.
An illustration may have logical substructure, including other illustrations. For
purposes of reflow, however, it is moved (and perhaps resized) as a unit, without
examining its internal contents. To be useful for reflow, it must have a BBox
attribute. It may also have Placement, Width, Height, and BaselineShift attributes
(see “Layout Attributes” on page 916).
Often an illustration is logically part of, or at least attached to, a paragraph or oth-
er element of a document. Any such containment or attachment is represented
through the use of the Figure structure type. The Figure element indicates the
point of attachment, and its Placement attribute describes the nature of the at-
tachment. An illustration element without a Placement attribute is treated as an
ILSE and laid out inline.
Note: For accessibility to users with disabilities and other text extraction purposes,
an illustration element should always have an Alt entry or an ActualText entry (or
both) in its structure element dictionary (see Sections 10.8.2, “Alternate Descrip-
tions,” and 10.8.3, “Replacement Text”). Alt is a description of the illustration,
whereas ActualText gives the exact text equivalent of a graphical illustration that
has the appearance of text.
913
SECTION 10.7
Tagged PDF
10.7.4
Standard Structure Attributes
In addition to the standard structure types, Tagged PDF defines standard layout
and styling attributes for structure elements of those types. These attributes en-
able predictable formatting to be applied during operations such as reflow and
export of PDF content to other document formats.
As discussed in Section 10.6.4, “Structure Attributes,” attributes are defined in
attribute objects, which are dictionaries or streams attached to a structure element
in either of two ways:
• The A entry in the structure element dictionary identifies an attribute object or
an array of such objects.
• The C entry in the structure element dictionary gives the name of an attribute
class or an array of such names. The class name is in turn looked up in the class
map, a dictionary identified by the ClassMap entry in the structure tree root,
yielding an attribute object or array of objects corresponding to the class.
In addition to the standard structure attributes described below, there are several
other optional entries—Lang, Alt, ActualText, and E—that are described in Sec-
tion 10.8, “Accessibility Support,” but are useful to other PDF consumers as well.
They appear in the following places in a PDF file (rather than in attribute dictio-
naries):
• As entries in the structure element dictionary (see Table 10.10 on page 858)
• As entries in property lists attached to marked-content sequences with a Span
tag (see Section 10.5, “Marked Content”)
Example 10.15 illustrates the use of standard structure attributes.
Standard Attribute Owners
Each attribute object has an owner, specified by the object’s O entry, which deter-
mines the interpretation of the attributes defined in the object’s dictionary. Multi-
ple owners may define like-named attributes with different value types or
interpretations. Tagged PDF defines a set of standard attribute owners, shown in
Table 10.28.
914
CHAPTER 10
Document Interchange
TABLE 10.28 Standard attribute owners
OWNER
DESCRIPTION
Layout
Attributes governing the layout of content
List
Attributes governing the numbering of lists
PrintField
(PDF 1.7) Attributes governing Form structure elements for non-
interactive form fields
Table
Attributes governing the organization of cells in tables
XML-1.00
Additional attributes governing translation to XML, version 1.00
HTML-3.20
Additional attributes governing translation to HTML, version 3.20
HTML-4.01
Additional attributes governing translation to HTML, version 4.01
OEB-1.00
Additional attributes governing translation to OEB, version 1.0
RTF-1.05
Additional attributes governing translation to Microsoft Rich Text
Format, version 1.05
CSS-1.00
Additional attributes governing translation to a format using CSS,
version 1.00
CSS-2.00
Additional attributes governing translation to a format using CSS,
version 2.00
An attribute object owned by a specific export format, such as XML-1.00, is
applied only when exporting PDF content to that format. Such format-specific at-
tributes override any corresponding attributes owned by Layout, List, PrintField,
or Table. There may also be additional format-specific attributes; the set of possi-
ble attributes is open-ended and is not explicitly specified or limited by Tagged
PDF.
Attribute Values and Inheritance
Some attributes are defined as inheritable. Inheritable attributes propagate down
the structure tree; that is, an attribute that is specified for an element applies to all
the descendants of the element in the structure tree unless a descendent element
specifies an explicit value for the attribute.
915
SECTION 10.7
Tagged PDF
Note: The description of each of the standard attributes in this section specifies
whether their values are inheritable.
It is permissible to specify an inheritable attribute on an element for the purpose
of propagating its value to child elements, even if the attribute is not meaningful
for the parent element. Non-inheritable attributes may be specified only for ele-
ments on which they would be meaningful.
The following list shows the priority for setting attribute values. A processing ap-
plication sets an attribute’s value to the first item in the list that applies:
1. The value of the attribute specified in the element’s A entry, owned by one of
the export formats (such as XML, HTML-3.20, HTML-4.01, OEB-1.0, CSS-1.00,
CSS-2.0, and RTF), if present, and if outputting to that format
2. The value of the attribute specified in the element’s A entry, owned by Layout,
PrintField, Table or List, if present
3. The value of the attribute specified in a class map associated with the element’s
C entry, if there is one
4. The resolved value of the parent structure element, if the attribute is inherita-
ble
5. The default value for the attribute, if there is one
Note: The attributes Lang, Alt, ActualText, and E do not appear in attribute dictio-
naries. The rules governing their application are discussed in Section 10.8, “Accessi-
bility Support.”
There is no semantic distinction between attributes that are specified explicitly
and ones that are inherited. Logically, the structure tree has attributes fully bound
to each element, even though some may be inherited from an ancestor element.
This is consistent with the behavior of properties (such as font characteristics)
that are not specified by structure attributes but are derived from the content.
916
CHAPTER 10
Document Interchange
Layout Attributes
Layout attributes specify parameters of the layout process used to produce the
appearance described by a document’s PDF content. Attributes in this category
are defined in attribute objects whose O (owner) entry has the value Layout (or is
one of the format-specific owner names listed in Table 10.28 on page 914). The
intent is that these parameters can be used to reflow the content or export it to
some other document format with at least basic styling preserved.
Table 10.32 summarizes the standard layout attributes and the structure elements
to which they apply. The following sections describe the meaning and usage of
these attributes.
Note: An asterisk (*) after the attribute name indicates that the attribute is inherit-
able. As described in “Attribute Values and Inheritance” on page 914, an inheritable
attribute may be specified for any element to propagate it to descendants, regardless
of whether it is meaningful for that element.
TABLE 10.29 Standard layout attributes
STRUCTURE ELEMENTS
ATTRIBUTES
Any structure element
Placement
WritingMode*
BackgroundColor
BorderColor*
BorderStyle
BorderThickness*
Color*
Padding
Any BLSE
SpaceBefore
ILSEs with Placement other than
SpaceAfter
StartIndent*
Inline
EndIndent*
BLSEs containing text
TextIndent*
TextAlign*
Illustration elements (Figure,
BBox
Formula, Form)
Width
Height
Table
917
SECTION 10.7
Tagged PDF
STRUCTURE ELEMENTS
ATTRIBUTES
TH (Table header)
Width
TD (Table data)
Height
BlockAlign*
InlineAlign*
TBorderStyle*
TPadding*
Any ILSE
LineHeight*
BLSEs containing ILSEs or
BaselineShift
TextDecorationType
containing direct or nested content
TextDecorationColor*
items
TextDecorationThickness*
Grouping elements Art, Sect, and
ColumnCount
Div
ColumnWidths
ColumnGap
Vertical text
GlyphOrientationVertical*
Ruby text
RubyAlign*
RubyPosition*
General Layout Attributes
The layout attributes described in Table 10.30 can apply to structure elements of
any of the standard types at the block level (BLSEs) or the inline level (ILSEs).
TABLE 10.30 Standard layout attributes common to all standard structure types
KEY
TYPE
VALUE
Placement
name
(Optional; not inheritable) The positioning of the element with respect to the
enclosing reference area and other content:
Block
Stacked in the block-progression direction within an
enclosing reference area or parent BLSE.
Inline
Packed in the inline-progression direction within an
enclosing BLSE.
918
CHAPTER 10
Document Interchange
KEY
TYPE
VALUE
Before
Placed so that the before edge of the element’s allocation
rectangle (see “Content and Allocation Rectangles” on page
930) coincides with that of the nearest enclosing reference
area. The element may float, if necessary, to achieve the
specified placement (see note below). The element is treated
as a block occupying the full extent of the enclosing reference
area in the inline direction. Other content is stacked so as to
begin at the after edge of the element’s allocation rectangle.
Start
Placed so that the start edge of the element’s allocation
rectangle (see “Content and Allocation Rectangles” on page
930) coincides with that of the nearest enclosing reference
area. The element may float, if necessary, to achieve the
specified placement (see note below). Other content that
would intrude into the element’s allocation rectangle is laid
out as a runaround.
End
Placed so that the end edge of the element’s allocation
rectangle (see “Content and Allocation Rectangles” on page
930) coincides with that of the nearest enclosing reference
area. The element may float, if necessary, to achieve the
specified placement (see note below). Other content that
would intrude into the element’s allocation rectangle is laid
out as a runaround.
When applied to an ILSE, any value except Inline causes the element to be
treated as a BLSE instead. Default value: Inline.
Note: Elements with Placement values of Before, Start, or End are removed from
the normal stacking or packing process and allowed to float to the specified edge
of the enclosing reference area or parent BLSE. Multiple such floating elements
may be positioned adjacent to one another against the specified edge of the ref-
erence area or placed serially against the edge, in the order encountered. Com-
plex cases such as floating elements that interfere with each other or do not fit
on the same page may be handled differently by different layout applications.
Tagged PDF merely identifies the elements as floating and indicates their de-
sired placement.
919
SECTION 10.7
Tagged PDF
KEY
TYPE
VALUE
WritingMode
name
(Optional; inheritable) The directions of layout progression for packing of
ILSEs (inline progression) and stacking of BLSEs (block progression):
LrTb
Inline progression from left to right; block progression from
top to bottom. This is the typical writing mode for Western
writing systems.
RlTb
Inline progression from right to left; block progression from
top to bottom. This is the typical writing mode for Arabic
and Hebrew writing systems.
TbRl
Inline progression from top to bottom; block progression
from right to left. This is the typical writing mode for
Chinese and Japanese writing systems.
The specified layout directions apply to the given structure element and all of
its descendants to any level of nesting. Default value: LrTb.
For elements that produce multiple columns, the writing mode defines the
direction of column progression within the reference area: the inline direc-
tion determines the stacking direction for columns and the default flow order
of text from column to column. For tables, the writing mode controls the lay-
out of rows and columns: table rows (structure type TR) are stacked in the
block direction, cells within a row (structure type TD) in the inline direction.
Note: The inline-progression direction specified by the writing mode is subject
to local override within the text being laid out, as described in Unicode Stan-
dard Annex #9, The Bidirectional Algorithm, available from the Unicode Con-
sortium (see the Bibliography).
BackgroundColor
array
(Optional; not inheritable; PDF 1.5) The color to be used to fill the back-
ground of a table cell or any element’s content rectangle (possibly adjusted by
the Padding attribute). The value is an array of three numbers in the range
0.0 to 1.0, representing the red, green, and blue values, respectively, of an
RGB color space. If this attribute is not specified, the element is treated as if it
were transparent.
920
CHAPTER 10
Document Interchange
KEY
TYPE
VALUE
BorderColor
array
(Optional; inheritable; PDF 1.5) The color of the border drawn on the edges
of a table cell or any element’s content rectangle (possibly adjusted by the
Padding attribute). The value of each edge is an array of three numbers in the
range 0.0 to 1.0, representing the red, green, and blue values, respectively, of
an RGB color space. There are two forms:
• A single array of three numbers representing the RGB values to apply to all
four edges.
• An array of four arrays, each specifying the RGB values for one edge of the
border, in the order of the before, after, start, and end edges. A value of null
for any of the edges means that it is not to be drawn.
If this attribute is not specified, the border color for this element is the cur-
rent text fill color in effect at the start of its associated content.
BorderStyle
array or
(Optional; not inheritable; PDF 1.5) The style of an element’s border. Specifies
name
the stroke pattern of each edge of a table cell or any element’s content rectan-
gle (possibly adjusted by the Padding attribute). There are two forms:
• A name from the list below representing the border style to apply to all
four edges.
• An array of four entries, each entry specifying the style for one edge of the
border in the order of the before, after, start, and end edges. A value of null
for any of the edges means that it is not to be drawn.
None
No border. Forces the computed value of BorderThickness to
be 0.
Hidden
Same as None, except in terms of border conflict resolution
for table elements.
Dotted
The border is a series of dots.
Dashed
The border is a series of short line segments.
Solid
The border is a single line segment.
Double
The border is two solid lines. The sum of the two lines and
the space between them equals the value of BorderThickness.
Groove
The border looks as though it were carved into the canvas.
Ridge
The border looks as though it were coming out of the canvas
(the opposite of Groove).
921
SECTION 10.7
Tagged PDF
KEY
TYPE
VALUE
Inset
The border makes the entire box look as though it were
embedded in the canvas.
Outset
The border makes the entire box look as though it were
coming out of the canvas (the opposite of Inset).
Default value: None
Note: All borders are drawn on top of the box’s background. The color of bor-
ders drawn for values of Groove, Ridge, Inset, and Outset depends on the struc-
ture element’s BorderColor attribute and the color of the background over which
the border is being drawn.
Note: Conforming HTML applications may interpret Dotted, Dashed, Double,
Groove, Ridge, Inset, and Outset to be Solid.
BorderThickness
number or
(Optional; inheritable; PDF 1.5) The thickness of the border drawn on the
array
edges of a table cell or any element’s content rectangle (possibly adjusted by
the Padding attribute). The value of each edge is a positive number in default
user space units representing the border’s thickness (a value of 0 indicates
that the border is not drawn). There are two forms:
• A number representing the border thickness for all four edges.
• An array of four entries, each entry specifying the thickness for one edge of
the border, in the order of the before, after, start, and end edges. A value of
null for any of the edges means that it is not to be drawn.
Padding
number or
(Optional; not inheritable; PDF 1.5) Specifies an offset to account for the sep-
array
aration between the element’s content rectangle and the surrounding border
(see “Content and Allocation Rectangles” on page 930). A positive value en-
larges the background area; a negative value trims it, possibly allowing the
border to overlap the element’s text or graphic.
The value is either a single number representing the width of the padding, in
default user space units, that applies to all four sides or a 4-entry array repre-
senting the padding width for the before, after, start, and end edge, respec-
tively, of the content rectangle. Default value: 0.
Color
array
(Optional; inheritable; PDF 1.5) The color to be used for drawing text and the
default value for the color of table borders and text decorations. The value is
an array of three numbers in the range 0.0 to 1.0, representing the red, green,
and blue values, respectively, of an RGB color space. If this attribute is not
specified, the border color for this element is the current text fill color in ef-
fect at the start of its associated content.
922
CHAPTER 10
Document Interchange
Layout Attributes for BLSEs
Table 10.31 describes layout attributes that apply only to block-level structure ele-
ments (BLSEs).
Note: Inline-level structure elements (ILSEs) with a Placement attribute other than
the default value of Inline are treated as BLSEs and hence are also subject to the
attributes described here.
TABLE 10.31 Additional standard layout attributes specific to block-level structure
elements
KEY
TYPE
VALUE
SpaceBefore
number
(Optional; not inheritable) The amount of extra space preceding the before
edge of the BLSE, measured in default user space units in the block-progres-
sion direction. This value is added to any adjustments induced by the
LineHeight attributes of ILSEs within the first line of the BLSE (see “Layout
Attributes for ILSEs” on page 926). If the preceding BLSE has a SpaceAfter at-
tribute, the greater of the two attribute values is used. Default value: 0.
Note: This attribute is disregarded for the first BLSE placed in a given reference
area.
SpaceAfter
number
(Optional; not inheritable) The amount of extra space following the after edge
of the BLSE, measured in default user space units in the block-progression
direction. This value is added to any adjustments induced by the LineHeight
attributes of ILSEs within the last line of the BLSE (see “Layout Attributes for
ILSEs” on page 926). If the following BLSE has a SpaceBefore attribute, the
greater of the two attribute values is used. Default value: 0.
Note: This attribute is disregarded for the last BLSE placed in a given reference
area.
Большое спасибо!
Ваше мнение очень важно для нас.
Нет комментариевНе стесняйтесь поделиться с нами вашим ценным мнением.
Текст