Repository navigation
PDF Spec 14 Structure
Part of: PDF-Spec-14-Document-Interchange
Navigation: PDF-Spec-14-Page-Piece | PDF-Spec-Index | PDF-Spec-14-Accessibility
Tagged PDF enables character codes to be unambiguously converted to Unicode values representing the information content of the text. There are several methods for doing this; a Tagged PDF document shall conform to at least one of them (see 'Unicode Mapping in Tagged PDF' in 14.8.2.4, 'Extraction of Character Properties'). In addition, Tagged PDF enables some characteristics of the associated fonts to be deduced (see 'Font Characteristics' in 14.8.2.4, 'Extraction of Character Properties').
- NOTE These Unicode 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.
Tagged PDF requires that every character code in a document can be mapped to a corresponding Unicode value.
- NOTE 1 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 Bibliography).
The methods for mapping a character code to a Unicode value are described in 9.10.2, 'Mapping Character Codes to Unicode Values.' A conforming writer shall ensure that the PDF file contains enough information to map all character codes to Unicode by one of the methods described there.
- NOTE 2 An Alt , ActualText , or E entry specified in a structure element dictionary or a marked-content property list (see 14.9.3, 'Alternate Descriptions,' 14.9.4, 'Replacement Text,' and 14.9.5, 'Expansion of Abbreviations and Acronyms') may affect the character stream that some conforming readers actually use. For example, some conforming readers may choose to use the Alt or ActualText value and ignore all text and other content associated with the structure element and its descendants.
- NOTE 3 Some uses of Tagged PDF require characters that may not be available in all fonts, such as the soft hyphen (see 14.8.2.2.3, 'Incidental Artifacts'). Such characters may 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 characters.
In addition to a Unicode value, each character code in a content stream has an associated set of font characteristics. These characteristics are not specified explicitly in the PDF file. Instead, the conforming reader derives the characteristics from the font descriptor for the font that is set in the text state at the time the character is shown.
- NOTE These characteristics are useful when exporting text to another application or file format that has a limited repertoire of available fonts.
Table 331 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 shall be derived from information available in the font descriptor's Flags entry (see 9.8.2, 'Font Descriptor Flags').
Table 331 - 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 |
The characteristics shown in the table apply only to character codes contained in show strings within content streams. They do not exist for alternate description text ( Alt ), replacement text ( ActualText ), or abbreviation expansion text ( E ).
For the standard 14 Type 1 fonts, the font descriptor may be missing; the well-known values for those fonts shall be 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 332 lists these font selector attributes and shows how their values shall be derived.
If the FontFamily , FontWeight and FontStretch fields are not present in the font descriptor, these values shall be derived from the font name in a manner of the conforming reader's choosing.
Table 332 - 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 122). |
| GenericFontFamily | A general font classification, used if FontFamily is not found. Derived from the font descriptor's Flags entry as follows: 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 NOTE The values Decorative and Symbol cannot be derived |
| FontSize | The size of the font: a positive number specifying the height of the typeface in points. Derived from the a, b, c, and d fields of the current text matrix. |
| FontStretch | The stretch value of the font. Derived from FontStretch in the font descriptor (see Table 122). |
| FontStyle | The italicization value of the font. It shall be Italic if the Italic flag is set in the Flags field of the font descriptor; otherwise, it shall be Normal. |
| FontVariant | The small-caps value of the font. It shall be SmallCaps if the SmallCap flag is set in the Flags field of the font descriptor; otherwise, it shall be Normal. |
| FontWeight | The weight (thickness) value of the font. Derived from FontWeight in the font descriptor (see Table 122). The ForceBold flag and the StemV field should not be used to set this attribute. |
- NOTE 1 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 engine needs to identify the words to be vocalized; spelling checkers and other applications 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 according 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.
A conforming reader of a Tagged PDF document may find words by sequentially examining the Unicode character stream, perhaps augmented by replacement text specified with ActualText (see 14.9.4, 'Replacement Text'). For this purpose the spacing characters that would be present to separate words in a pure text representation shall be present in the Tagged PDF representation of the text.
- NOTE 2 The conforming reader does not need to guess about word breaks based on information such as glyph positioning on the page, font changes, or glyph sizes.
- NOTE 3 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 (U+0020) or other word-breaking character is still needed even if a word break happens to fall at the end of a show string.
- NOTE 4 Some conforming readers 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 others may identify possible line-break opportunities by using an algorithm similar to the one in Unicode Standard Annex #29, Text Boundaries, available from the Unicode Consortium (see the Bibliography).
The basic layout model begins with the notion of a reference area . This is a rectangular region used 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 14.8.5.4.3, 'Layout Attributes for BLSEs'), shall be 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.
- NOTE 1 Tagged PDF's standard structure types and attributes shall be interpreted in the context 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 document's underlying structure and does not necessarily correspond to the one actually 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 conforming readers to make their own layout decisions while preserving the authoring application's intent as closely as their own layout models allow.
- NOTE 2 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. The model is deliberately defined loosely to allow reasonable latitude in the interpretation of structure elements and attributes when converting to other document formats. Some degree of variation in the resulting layout from one format to another is to be expected.
The standard structure types are divided into four main categories according to the roles they play in page layout:
-
Grouping elements (see 14.8.4.2, 'Grouping Elements') group other elements into sequences or hierarchies but hold no content directly and have no direct effect on layout.
-
Block-level structure elements ( BLSE s) (see 14.8.4.3, 'Block-Level Structure Elements') describe the overall layout of content on the page, proceeding in the block-progression direction .
-
Inline-level structure elements ( ILSE s) (see 14.8.4.4, 'Inline-Level Structure Elements') describe the layout of content within a BLSE, proceeding in the inline-progression direction .
-
Illustration elements (see 14.8.4.5, 'Illustration Elements') are compact sequences of content, in page content order, that are considered to be unitary objects 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 14.8.5.4.2, 'General Layout Attributes'). In Western writing systems, the block direction is from top to bottom and the inline direction is from left to right. Other writing systems use different directions for laying out content.
Because the progression directions can vary depending on the writing system, edges of areas and directions on the page are 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 bottom to top).
BLSEs shall be stacked within a reference area in block-progression order. In general, the first BLSE shall be placed against the before edge of the reference area. Subsequent BLSEs shall be 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 determined, 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 extent of the reference area.
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 (the BlockAlign and InlineAlign elements), such nesting of BLSEs does not result in the nesting of reference areas; a single reference area prevails for all levels of nested BLSEs.
Within a BLSE, child ILSEs shall be packed into lines . Direct content items -those that are immediate children of a BLSE rather than contained within a child ILSE-shall be implicitly treated as ILSEs for packing purposes. Each line shall be treated as a synthesized BLSE and shall be 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 blockprogression direction: a line shall be packed with ILSEs beginning at the start edge of the containing BLSE and continuing until the end edge shall be reached and the line is full. The overflowing ILSE may allow itself to be broken at linguistically determined or explicitly marked break points (such as hyphenation points within a word), and the remaining fragment shall be carried over to the next line.
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' in 14.8.5.4, 'Layout Attributes,' for further discussion.
Two enclosing rectangles shall be associated with each BLSE and ILSE (including direct content items that are treated implicitly as ILSEs):
- The content rectangle shall be 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 surrounding the element, affecting how it shall be positioned with respect to adjacent elements and the enclosing content rectangle or reference area.
The definitions of these rectangles shall be determined by layout attributes associated with the structure element; see 14.8.5.4.5, 'Content and Allocation Rectangles' for further discussion.
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 14.8.5, 'Standard Structure Attributes'), how that content is laid out on the page. As discussed in 14.7.3, 'Structure Types,' the structure type of a logical structure element shall be specified by the S entry in its structure element dictionary. To be considered a standard structure type, this value shall be either:
- One of the standard structure type names described in 14.8.4.2, 'Grouping Elements.'
- An arbitrary name that shall be mapped to one of the standard names by the document's role map (see 14.7.3, 'Structure Types'), possibly through multiple levels of mapping.
- NOTE 1 Beginning with PDF 1.5, an element name is always mapped to its corresponding 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.
Ordinarily, structure elements having standard structure types shall be processed the same way whether the type is expressed directly or is determined indirectly from the role map. However, some conforming readers may ascribe additional semantics to nonstandard structure types, even though the role map associates them with standard ones.
- NOTE 2 For instance, the actual values of the S entries may be used when exporting to a tagged representation such as XML, and the corresponding role-mapped values shall be used when converting to presentation formats such as HTML or RTF, or for purposes such as reflow or accessibility to users with disabilities.
- NOTE 3 Most of the standard element types are designed primarily for laying out text; the terminology reflects this usage. However, a layout may in fact include any type of content, such as path or image objects.
The content items associated with a structure element shall be laid out on the page as if they were blocks of text (for a BLSE) or characters within a line of text (for an ILSE).
Grouping elements shall be used solely to group other structure elements; they are not directly associated with content items. Table 333 describes the standard structure types for elements in this category. H.8, 'Structured Elements That Describe Hierarchical Lists' provides an example of nested table of content items.
In a tagged PDF document, the structure tree shall contain a single top-level element; that is, the structure tree root (identified by the StructTreeRoot entry in the document catalogue) shall have only one child in its K (kids) array. If the PDF file contains a complete document, the structure type Document should be used for this toplevel 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 333 - 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. |
| 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 elements. |
Table 333 - Standard structure types for grouping elements (continued)
| Structure type | Description |
|---|---|
| Sect | (Section) A container for grouping related content elements. NOTE 1 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 someone 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) 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 includes other nested TOC entries (and possibly TOCI entries) represents a more complex hierarchy. Ideally, the hierarchy of a top level TOC entry reflects the structure of the main body of the document. NOTE 2 Lists of figures and tables, as well as bibliographies, can be treated as |
| TOCI | (Table of contents item) An individual member of a table of contents. This entry's children may be any of the following structure types: Lbl A label (see 'List Elements' in 14.8.4.3, 'Block-Level Structure Elements') Reference A reference to the title and the page number (see 'Inline-Level Structure Elements' in 14.8.4.4, 'Inline-Level Structure Elements') NonStruct Non-structure elements for wrapping a leader artifact (see 'Grouping Elements' in 14.8.4.2, 'Grouping Elements'). P Descriptive text (see 'Paragraphlike Elements' 14.8.4.3, 'Block-Level Structure Elements') 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 elements (structure type Reference; see 14.8.4.4, 'Inline-Level Structure Elements') that point out occurrences of the specified text in the main body of a document. |
| 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) in that it shall not be interpreted or exported to other document formats; however, its descendants shall be processed normally. |
| Private | (Private element) A grouping element containing private content belonging to the application producing it. The structural significance of this type of element is unspecified and shall be determined entirely by the conforming writer. Neither the Private element nor any of its descendants shall be interpreted or exported to other document formats. |
A block-level structure element (BLSE) is any region of text or other content that is laid out in the blockprogression 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 334. All other standard structure types shall be 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 shall be used to group elements within a table and shall be considered neither BLSEs nor ILSEs
- Elements with a Placement attribute (see 'General Layout Attributes' in 14.8.5.4, 'Layout Attributes') other than the default value of Inline
Table 334 - Block-level structure elements
| Category | Structure types | Structure types |
|---|---|---|
| Paragraphlike elements | P H | H1 H2 H3 |
| List elements | L LI | Lbl LBody |
| Table element | Table |
In many cases, a BLSE may appear as one compact, contiguous piece of page content; in other cases, it may be discontiguous.
NOTE 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 conforming readers can recognize such fragmented BLSEs from the logical structure and use this information to reassemble them and properly lay them out.
Table 335 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 335 - 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 conforming writers 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. |
Table 336 describes structure types for organizing the content of lists. H.8, 'Structured Elements That Describe Hierarchical Lists' provides an example of nested list entries.
Table 336 - 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 14.8.4.2, 'Grouping Elements') followed by one or more list items (structure type LI). |
| LI | (List item) An individual member of a list. Its children may be one or more labels, list bodies, or both (structure types Lbl or LBody). |
Table 336 - Standard structure types for list elements (continued)
| Structure Type | Description |
|---|---|
| Lbl | (Label) A name or number that distinguishes a given item from others in the same list or other group of like items. NOTE In a dictionary list, for example, it contains the term being defined; in a bulleted or numbered list, it contains the bullet character or the |
| LBody | (List body) The descriptive content of a list item. In a dictionary list, for example, it contains the definition of the term. It may either contain the content directly or have other BLSEs, perhaps including nested lists, as children. |
The structure types described in Table 337 shall be used for organizing the content of tables.
NOTE 1 Strictly speaking, the Table element is a BLSE; the others in this table are neither BLSEs or ILSEs.
Table 337 - Standard structure types for table elements
| Structure Type | Description |
|---|---|
| Table | (Table) A two-dimensional layout of rectangular data cells, possibly having a complex substructure. It contains either one or more table rows (structure type TR) as children; or an optional table head (structure type THead) followed by one or more table body elements (structure type TBody) and an optional table footer (structure type TFoot). In addition, a table may have a caption (structure type Caption; see 14.8.4.2, 'Grouping Elements') 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). |
| TH | (Table header cell) A table cell containing header text describing one or more rows or columns 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. |
| TFoot | (Table footer row group; PDF 1.5 ) A group of rows that constitute the footer of a table. 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.) |
NOTE 2 The association of headers with rows and columns of data is typically determined heuristically by applications. Such heuristics may fail for complex tables; the standard attributes for tables shown in Table 348 can be used to make the association explicit.
Because different conforming readers 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 interpretation among different Tagged PDF consumers.
As described under 14.8.4.2, 'Grouping Elements,' a Tagged PDF document may have one or more levels of grouping elements, such as Document, Part, Art (Article), Sect (Section), and Div (Division). The descendants of these should be BLSEs, such as H (Heading), P (Paragraph), and L (List), that hold the actual content. Their descendants, in turn, should be either content items or ILSEs that further describe the content.
- NOTE 1 As noted earlier, elements with structure types that would ordinarily be treated as ILSEs may have a Placement attribute (see 'General Layout Attributes' in 14.8.5.4, 'Layout Attributes') that causes them to be treated as BLSEs instead. Such elements may be included as BLSEs in the same manner as headings and paragraphs.
The block-level structure may 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 should consist of a heading (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 may be expressed by the use of headings with specific levels (H1-H6).
- NOTE 2 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' in 14.8.4.3, 'Block-Level Structure Elements,' and 'Table Elements' in 14.8.4.3, 'Block-Level Structure Elements'. Likewise, tables of contents and indexes should be structured as described for the TOC and Index structure types under 'Grouping Elements' in 14.8.4.2, 'Grouping 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 shall be stacked in the blockprogression direction. An ILSE may in turn contain a BLSE, which shall be treated as a unitary item of layout in the inline direction. Table 338 lists the standard structure types for ILSEs.
Table 338 - 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 1 Not all inline style changes need to be identified as a span. Text colour 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' in 14.8.2.4, 'Extraction of Character Properties'). However, it is necessary to use a span to apply explicit layout attributes such as LineHeight , BaselineShift , or TextDecorationType (see 'Layout Attributes for ILSEs' in 14.8.5.4, 'Layout Attributes'). NOTE 2 Marked-content sequences having the tag Span are also used to carry certain accessibility properties ( Alt , ActualText , Lang , and E ; see 14.9, 'Accessibility Support'). Such sequences 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. |
| Quote | (Quotation) An inline portion of text attributed to someone other than the author of the surrounding text. The quoted text should be contained inline within a single paragraph. This differs from the block-level element BlockQuote (see 14.8.4.2, 'Grouping Elements'), which consists of one or more complete paragraphs (or other elements presented as if they were complete paragraphs). |
| 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 Elements' in 14.8.4.3, 'Block-Level Structure Elements') as a child. The note may be included as a child of the structure element 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). Tagged PDF does not prescribe the placement of footnotes in the page content order. They may be either inline or at the end of the page, at the discretion of the conforming writer. |
| 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' in 14.8.4.3, 'Block-Level Structure Elements') as a child. 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. |
| 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 12.5.6.5, 'Link Annotations'). Its children should be one or more content items or child ILSEs and one or more object references (see 14.7.4.3, 'PDF Objects as Content Items') identifying the associated link annotations. See 'Link Elements' in 14.8.4.3, 'Block-Level Structure Elements,' for further discussion. |
| Annot | (Annotation; PDF 1.5) An association between a portion of the ILSE's content and a corresponding PDF annotation (see 12.5, 'Annotations'). Annot shall be used for all PDF annotations except link annotations (see the Link element) and widget annotations (see the Form element in Table 340). See 'Annotation Elements' 14.8.4.4, 'Inline-Level Structure Elements,' for further discussion. |
Table 338 - Standard structure types for inline-level structure elements (continued)
| 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. A Ruby element may also contain the RB, RT, and RP elements. See 'Ruby and Warichu Elements' in14.8.4.4, 'Inline- Level Structure Elements,' 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. A Warichu element may also contain the WT and WP elements. See 'Ruby and Warichu Elements' in14.8.4.4, 'Inline-Level Structure Elements,' for more details. |
NOTE 1 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 annotations 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 facilities to establish the association between content items and link annotations, providing functionality comparable to HTML hypertext links. The following items may be children of a link element:
- One or more content items or other ILSEs (except other links)
- Object references (see 14.7.4.3, 'PDF Objects as Content Items') to one or more link annotations associated with the content
When a Link structure element describes a span of text to be associated with a link annotation and that span wraps from the end of one line to the beginning of another, the Link structure element shall include a single object reference that associates the span with the associated link annotation. Further, the link annotation shall use the QuadPoint entry to denote the active areas on the page.
entry that boxes the entry contains 16 numbers: the first 8 numbers describe
EXAMPLE 1 The Link structure element references a link annotation that includes a QuadPoint strings 'with a' and 'link'. That is, the QuadPoint a quadrilateral for 'with a', and the next 8 describe a quadrilateral for 'link.'
Here is some text with a link inside.
NOTE 2 Beginning with PDF 1.7, use of the Link structure element to enclose multiple link annotations is deprecated.
EXAMPLE 2 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 >
This code sample shows an equivalent fragment of PDF using a link element, whose text it displays in blue and underlined.
/P << /MCID 0 >> % Marked-content sequence 0 (paragraph) BDC % Begin marked-content sequence
501 0 obj endobj 502 0 obj endobj 503 0 obj endobj
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 colour 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 colour 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 colour to blue ( with a link ) Tj % Show text of link ET % End text object EMC % End marked-content sequence /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 colour to black ( inside . ) Tj % Show text following link ET % End text object EMC % End marked-content sequence % 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 ] >> % Structure element for link << /Type /StructElem /S /Link . . . /K [ 1 % Two children: marked-content sequence 1 503 0 R % Object reference to link annotation ] >> % Object reference to link annotation << /Type /OBJR /Obj 600 0 R % Link annotation (not shown) >>
Tagged PDF annotation elements (structure type Annot; PDF 1.5 ) use PDF's logical structure facilities to establish the association between content items and PDF annotations. Annotation elements shall be used for all types of annotations other than links (see 'Link Elements' in 14.8.4.3, 'Block-Level Structure Elements') and forms (see Table 340).
The following items may be children of an annotation element:
- Object references (see 14.7.4.3, 'PDF Objects as Content Items') 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 shall be defined by the appearance of the referenced annotations, and its text content shall be treated as if it were a Span element. It may have an optional BBox attribute; if supplied, this attribute overrides the rectangle specified by the annotation dictionary'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 annotation may also be applied (for example, with a Highlight annotation).
There may be multiple children that are object references to different annotations, subject to the constraint that the annotations shall be the same except for their Rect entry. This is much the same as is done for the Link element; it allows an annotation to be associated with discontiguous pieces of content, such as line-wrapped text.
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 pronunciation 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 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.
Table 339 - Standard structure types for Ruby and Warichu elements ( PDF 1.5 )
| Structure Type | Description |
|---|---|
| Ruby | (Ruby) The wrapper around the entire ruby assembly. It shall contain one RB element followed by either an RT element or a three-element group consisting of RP, RT, and RP. Ruby elements and their content elements shall not break across multiple lines. |
| RB | (Ruby base text) The full-size text to which the ruby annotation is applied. RB may 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 shall be placed adjacent to the ruby base text. It may contain text, other inline elements, or a mixture of both. It may have the RubyAlign and RubyPosition attributes. |
Table 339 - Standard structure types for Ruby and Warichu elements ( PDF 1.5 ) (continued)
| Structure Type | Description |
|---|---|
| RP | (Ruby punctuation) Punctuation surrounding the ruby annotation text. It is used only when a ruby annotation cannot be properly formatted in a ruby style and instead is formatted as a normal comment, or when it is formatted as a warichu. It contains text (usually a single LEFT or RIGHT PARENTHESIS or similar bracketing character). |
| Warichu | (Warichu) The wrapper around the entire warichu assembly. It may contain a three- element 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 (usually a single LEFT or RIGHT PARENTHESIS or similar bracketing character). According to JIS X 4051-1995, the parentheses surrounding a warichu may be converted to a SPACE (nominally 1/4 EM in width) at the discretion of the formatter. |
Tagged PDF defines an illustration element as any structure element whose structure type (after role mapping, if any) is one of those listed in Table 340. The illustration's content shall consist of one or more complete graphics objects. It shall not appear between the BT and ET operators delimiting a text object (see 9.4, 'Text Objects'). It may include clipping only in the form of a contained marked clipping sequence, as defined in 14.6.3, 'Marked Content and Clipping.' In Tagged PDF, all such marked clipping sequences shall carry the marked-content tag Clip.
Table 340 - 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' in 14.8.5.4, 'Layout Attributes'). |
| Formula | (Formula) A mathematical formula. 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 formula. From a formatting standpoint, the formula shall be treated similarly to a figure (structure type Figure). |
| Form | (Form) A widget annotation representing an interactive form field (see 12.7, 'Interactive 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 348), it shall have only one child: an object reference (see 14.7.4.3, 'PDF Objects as Content Items') identifying the widget annotation. The annotations' appearance stream (see 12.5.5, 'Appearance Streams') shall describe the appearance of the form element. |
An illustration may have logical substructure, including other illustrations. For purposes of reflow, however, it shall be moved (and perhaps resized) as a unit, without examining its internal contents. To be useful for reflow, it shall have a BBox attribute. It may also have Placement , Width , Height , and BaselineShift attributes (see 14.8.5.4, 'Layout Attributes').
Often an illustration is logically part of, or at least attached to, a paragraph or other element of a document. Any such containment or attachment shall be 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 attachment. An illustration element without a Placement attribute shall be treated as an ILSE and laid out inline.
For accessibility to users with disabilities and other text extraction purposes, an illustration element should have an Alt entry or an ActualText entry (or both) in its structure element dictionary (see 14.9.3, 'Alternate Descriptions,' and 14.9.4, '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.
In addition to the standard structure types, Tagged PDF defines standard layout and styling attributes for structure elements of those types. These attributes enable predictable formatting to be applied during operations such as reflow and export of PDF content to other document formats.
As discussed in 14.7.5, 'Structure Attributes,' attributes shall be 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 in 14.8.5.2, 'Standard Attribute Owners,' there are several other optional entriesLang , Alt , ActualText , and E -that are described in 14.9, '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 dictionaries):
- As entries in the structure element dictionary (see Table 323)
- As entries in property lists attached to marked-content sequences with a Span tag (see 14.6, 'Marked Content')
The Example in 14.7.6, 'Example of Logical Structure,' illustrates the use of standard structure attributes.
Each attribute object has an owner , specified by the object's O entry, which determines the interpretation of the attributes defined in the object's dictionary. Multiple owners may define like-named attributes with different value types or interpretations. Tagged PDF defines a set of standard attribute owners, shown in Table 341.
Table 341 - 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 |
Table 341 - Standard attribute owners (continued)
| Owner | Description |
|---|---|
| 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 , shall be applied only when exporting PDF content to that format. Such format-specific attributes shall override any corresponding attributes owned by Layout , List , PrintField , or Table . There may also be additional format-specific attributes; the set of possible attributes is open-ended and is not explicitly specified or limited by Tagged PDF.
Navigation: PDF-Spec-14-Page-Piece | PDF-Spec-Index | PDF-Spec-14-Accessibility