PDF Reference sixth edition, Adobe Portable Document Format Version 1.7 (book 2) — page 10

    963
    SECTION 10.10
    Prepress Support
    include areas close to the edges of the medium that cannot be marked because
    of physical limitations of the output device. Content falling outside this bound-
    ary can safely be discarded without affecting the meaning of the PDF file.
    • The crop box defines the region to which the contents of the page are to be
    clipped (cropped) when displayed or printed. Unlike the other boxes, the crop
    box has no defined meaning in terms of physical page geometry or intended
    use; it merely imposes clipping on the page contents. However, in the absence
    of additional information (such as imposition instructions specified in a JDF or
    PJTF job ticket), the crop box determines how the page’s contents are to be po-
    sitioned on the output medium. The default value is the page’s media box.
    • The bleed box (PDF 1.3) defines the region to which the contents of the page
    should be clipped when output in a production environment. This may include
    any extra bleed area needed to accommodate the physical limitations of cut-
    ting, folding, and trimming equipment. The actual printed page may include
    printing marks that fall outside the bleed box. The default value is the page’s
    crop box.
    • The trim box (PDF 1.3) defines the intended dimensions of the finished page
    after trimming. It may be smaller than the media box to allow for production-
    related content, such as printing instructions, cut marks, or color bars. The
    default value is the page’s crop box.
    • The art box (PDF 1.3) defines the extent of the page’s meaningful content
    (including potential white space) as intended by the page’s creator. The default
    value is the page’s crop box.
    These boundaries are specified by the MediaBox, CropBox, BleedBox, TrimBox,
    and ArtBox entries, respectively, in the page object dictionary (see Table 3.27 on
    page 145). All of them are rectangles expressed in default user space units. The
    crop, bleed, trim, and art boxes should not ordinarily extend beyond the boun-
    daries of the media box. If they do, they are effectively reduced to their intersec-
    tion with the media box. Figure 10.3 illustrates the relationships among these
    boundaries. (The crop box is not shown in the figure because it has no defined re-
    lationship with any of the other boundaries.)
    964
    CHAPTER 10
    Document Interchange
    Headline
    Art box
    Trim box
    Tis might be a caption
    Bleed: 10.75x8.25
    Trim: 10.5x8
    Printer’s marks
    Bleed box
    Media box
    FIGURE 10.3 Page boundaries
    How the various boundaries are used depends on the purpose to which the page
    is being put. The following are typical purposes:
    • Placing the content of a page in another application. The art box determines the
    boundary of the content that is to be placed in the application. Depending on
    965
    SECTION 10.10
    Prepress Support
    the applicable usage conventions, the placed content may be clipped to either
    the art box or the bleed box. (For example, a quarter-page advertisement to be
    placed on a magazine page might be clipped to the art box on the two sides of
    the ad that face into the middle of the page and to the bleed box on the two
    sides that bleed over the edge of the page.) The media box and trim box are
    ignored.
    • Printing a finished page. This case is typical of desktop or shared page printers,
    in which the page content is positioned directly on the final output medium.
    The art box and bleed box are ignored. The media box may be used as advice
    for selecting media of the appropriate size. The crop box and trim box, if
    present, should be the same as the media box. (See implementation note 167 in
    Appendix H.)
    • Printing an intermediate page for use in a prepress process. The art box is
    ignored. The bleed box defines the boundary of the content to be imaged. The
    trim box specifies the positioning of the content on the medium; it may also be
    used to generate cut or fold marks outside the bleed box. Content falling within
    the media box but outside the bleed box may or may not be imaged, depending
    on the specific production process being used.
    • Building an imposition of multiple pages on a press sheet. The art box is ignored.
    The bleed box defines the clipping boundary of the content to be imaged; con-
    tent outside the bleed box is ignored. The trim box specifies the positioning of
    the page’s content within the imposition. Cut and fold marks are typically gen-
    erated for the imposition as a whole.
    In the scenarios above, an application that interprets the bleed, trim, and art
    boxes for some purpose typically alters the crop box so as to impose the clipping
    that those boxes prescribe.
    Display of Page Boundaries
    For the user’s convenience, viewer applications may offer the ability to display
    guidelines on the screen for the various page boundaries. The optional BoxCol-
    orInfo entry in a page object (see “Page Objects” on page 144) holds a box color
    information dictionary (PDF 1.4) specifying the colors and other visual character-
    istics to be used for such display. Viewer applications typically provide a user in-
    terface to allow the user to set these characteristics interactively. Note that this
    information is page-specific and can vary from one page to another.
    966
    CHAPTER 10
    Document Interchange
    As shown in Table 10.46, the box color information dictionary contains an op-
    tional entry for each of the possible page boundaries other than the media box.
    The value of each entry is a box style dictionary, whose contents are shown in
    Table 10.47. If a given entry is absent, the viewer application should use its own
    current default settings instead.
    10.10.2
    Printer’s Marks
    Printer’s marks are graphic symbols or text added to a page to assist production
    personnel in identifying components of a multiple-plate job and maintaining
    consistent output during production. Examples commonly used in the printing
    industry include these:
    • Registration targets for aligning plates
    • Gray ramps and color bars for measuring colors and ink densities
    • Cut marks showing where the output medium is to be trimmed
    Although PDF producer applications traditionally include such marks in the con-
    tent stream of a document, they are logically separate from the content of the page
    itself and typically appear outside the boundaries (the crop box, trim box, and art
    box) defining the extent of that content (see Section 10.10.1, “Page Boundaries”).
    Printer’s mark annotations (PDF 1.4) provide a mechanism for incorporating
    printer’s marks into the PDF representation of a page, while keeping them sepa-
    rate from the actual page content. Each page in a PDF document may contain any
    number of such annotations, each of which represents a single printer’s mark.
    Note: Because printer’s marks typically fall outside the page’s content boundaries,
    each mark must be represented as a separate annotation. Otherwise—if, for exam-
    ple, the cut marks at the four corners of the page were defined in a single annota-
    tion—the annotation rectangle would encompass the entire contents of the page and
    could interfere with the user’s ability to select content or interact with other annota-
    tions on the page. Defining printer’s marks in separate annotations also facilitates
    the implementation of a drag-and-drop user interface for specifying them.
    967
    SECTION 10.10
    Prepress Support
    TABLE 10.46 Entries in a box color information dictionary
    KEY
    TYPE
    VALUE
    CropBox dictionary
    (Optional) A box style dictionary (see Table 10.47) specifying the visual characteris-
    tics for displaying guidelines for the page’s crop box. This entry is ignored if no crop
    box is defined in the page object.
    BleedBox dictionary
    (Optional) A box style dictionary (see Table 10.47) specifying the visual characteris-
    tics for displaying guidelines for the page’s bleed box. This entry is ignored if no
    bleed box is defined in the page object.
    TrimBox
    dictionary
    (Optional) A box style dictionary (see Table 10.47) specifying the visual characteris-
    tics for displaying guidelines for the page’s trim box. This entry is ignored if no trim
    box is defined in the page object.
    ArtBox
    dictionary
    (Optional) A box style dictionary (see Table 10.47) specifying the visual characteris-
    tics for displaying guidelines for the page’s art box. This entry is ignored if no art
    box is defined in the page object.
    TABLE 10.47 Entries in a box style dictionary
    KEY
    TYPE
    VALUE
    C
    array
    (Optional) An array of three numbers in the range 0.0 to 1.0, representing the com-
    ponents in the DeviceRGB color space of the color to be used for displaying the
    guidelines. Default value: [ 0.0 0.0 0.0 ].
    W
    number
    (Optional) The guideline width in default user space units. Default value: 1.
    S
    name
    (Optional) The guideline style:
    S
    (Solid) A solid rectangle.
    D
    (Dashed) A dashed rectangle. The dash pattern is specified by the D entry
    (see below).
    Other guideline styles may be defined in the future. Default value: S.
    D
    array
    (Optional) A dash array defining a pattern of dashes and gaps to be used in drawing
    dashed guidelines (guideline style D above). The dash array is specified in default
    user space units, in the same format as in the line dash pattern parameter of the
    graphics state (see “Line Dash Pattern” on page 217). The dash phase is not speci-
    fied and is assumed to be 0. For example, a D entry of [ 3 2 ] specifies guidelines
    drawn with 3-point dashes alternating with 2-point gaps. Default value: [ 3 ].
    968
    CHAPTER 10
    Document Interchange
    The visual presentation of a printer’s mark is defined by a form XObject specified
    as an appearance stream in the N (normal) entry of the printer’s mark annota-
    tion’s appearance dictionary (see Section 8.4.4, “Appearance Streams”). More
    than one appearance may be defined for the same printer’s mark to meet the
    requirements of different regions or production facilities. In this case, the
    appearance dictionary’s N entry holds a subdictionary containing the alternate
    appearances, each identified by an arbitrary key. The AS (appearance state) entry
    in the annotation dictionary designates one of them to be displayed or printed.
    Note: The printer’s mark annotation’s appearance dictionary may include R (roll-
    over) or D (down) entries, but appearances defined in either of these entries are
    never displayed or printed.
    Like all annotations, a printer’s mark annotation is defined by an annotation dic-
    tionary (see Section 8.4.1, “Annotation Dictionaries”); its annotation type is
    PrinterMark. The AP (appearances) and F (flags) entries (which ordinarily are
    optional) must be present, as must the AS (appearance state) entry if the appear-
    ance dictionary AP contains more than one appearance stream. The Print and
    ReadOnly flags in the F entry must be set and all others clear (see Section 8.4.2,
    “Annotation Flags”). Table 10.48 shows an additional annotation dictionary entry
    specific to this type of annotation.
    TABLE 10.48 Additional entries specific to a printer’s mark annotation
    KEY
    TYPE
    VALUE
    Subtype
    name
    (Required) The type of annotation that this dictionary describes;
    must
    be
    PrinterMark for a printer’s mark annotation.
    MN
    name
    (Optional) An arbitrary name identifying the type of printer’s mark, such as
    ColorBar or RegistrationTarget.
    The form dictionary defining a printer’s mark can contain the optional entries
    shown in Table 10.49 in addition to the standard ones common to all form dictio-
    naries (see Section 4.9.1, “Form Dictionaries”).
    TABLE 10.49 Additional entries specific to a printer’s mark form dictionary
    KEY
    TYPE
    VALUE
    MarkStyle
    text string
    (Optional; PDF 1.4) A text string representing the printer’s mark in human-
    readable form and suitable for presentation to the user on the screen.
    969
    SECTION 10.10
    Prepress Support
    KEY
    TYPE
    VALUE
    Colorants
    dictionary
    (Optional; PDF 1.4) A dictionary identifying the individual colorants
    associated with a printer’s mark, such as a color bar. For each entry in this
    dictionary, the key is a colorant name and the value is an array defining a
    Separation color space for that colorant (see “Separation Color Spaces” on
    page 264). The key must match the colorant name given in that color space.
    10.10.3
    Separation Dictionaries
    In high-end printing workflows, pages are ultimately produced as sets of separa-
    tions, one per colorant (see “Separation Color Spaces” on page 264). Ordinarily,
    each page in a PDF file is treated as a composite page that paints graphics objects
    using all the process colorants and perhaps some spot colorants as well. In other
    words, all separations for a page are generated from a single PDF description of
    that page.
    In some workflows, however, pages are preseparated before generating the PDF
    file. In a preseparated PDF file, the separations for a page are described as sepa-
    rate page objects, each painting only a single colorant (usually specified in the
    DeviceGray color space). When this is done, additional information is needed to
    identify the actual colorant associated with each separation and to group together
    the page objects representing all the separations for a given page. This informa-
    tion is contained in a separation dictionary (PDF 1.3) in the SeparationInfo entry
    of each page object (see “Page Objects” on page 144). Table 10.50 shows the con-
    tents of this type of dictionary.
    TABLE 10.50 Entries in a separation dictionary
    KEY
    TYPE
    VALUE
    Pages
    array
    (Required) An array of indirect references to page objects representing separa-
    tions of the same document page. One of the page objects in the array must be
    the one with which this separation dictionary is associated, and all of them must
    have separation dictionaries (SeparationInfo entries) containing Pages arrays
    identical to this one.
    DeviceColorant name or
    (Required) The name of the device colorant to be used in rendering this separa-
    string
    tion, such as Cyan or PANTONE 35 CV.
    970
    CHAPTER 10
    Document Interchange
    KEY
    TYPE
    VALUE
    ColorSpace
    array
    (Optional) An array defining a Separation or DeviceN color space (see “Separa-
    tion Color Spaces” on page 264 and “DeviceN Color Spaces” on page 268). It
    provides additional information about the color specified by DeviceColorant—in
    particular, the alternate color space and tint transformation function that would
    be used to represent the colorant as a process color. This information enables a
    viewer application to preview the separation in a color that approximates the de-
    vice colorant.
    The value of DeviceColorant must match the space’s colorant name (if it is a
    Separation space) or be one of the space’s colorant names (if it is a DeviceN
    space).
    10.10.4
    Output Intents
    Output intents (PDF 1.4) provide a means for matching the color characteristics
    of a PDF document with those of a target output device or production environ-
    ment in which the document will be printed. The optional OutputIntents entry in
    the document catalog (see Section 3.6.1, “Document Catalog”) holds an array of
    output intent dictionaries, each describing the color reproduction characteristics
    of a possible output device or production condition. The contents of these dictio-
    naries can vary for different devices and conditions. The dictionary’s S entry
    specifies an output intent subtype that determines the format and meaning of the
    remaining entries.
    This use of multiple output intents allows the production process to be custom-
    ized to the expected workflow and the specific tools available. For example, one
    production facility might process files conforming to a recognized format stan-
    dard such as PDF/X-1, while another uses custom Acrobat plug-in extensions to
    produce RGB output for document distribution on the Web. Each of these work-
    flows would require different sets of output intent information. Multiple output
    intents also allow the same PDF file to be distributed unmodified to multiple pro-
    duction facilities. The choice of which output intent to use in a given production
    environment is a matter for agreement between the purchaser and provider of
    production services. PDF intentionally does not include a selector for choosing a
    particular output intent from within the PDF file.
    At the time of publication, only one output intent subtype, GTS_PDFX, has been
    defined, corresponding to the PDF/X format standard specified in ISO 15930-
    1:2001 (see the Bibliography). Table 10.51 shows the contents of this type of output
    971
    SECTION 10.10
    Prepress Support
    intent dictionary. Other subtypes may be added in the future; the names of any
    such additional subtypes must conform to the naming guidelines described in
    Appendix E.
    TABLE 10.51 Entries in a PDF/X output intent dictionary
    KEY
    TYPE
    VALUE
    Type
    name
    (Optional) The type of PDF object that this dictionary describes;
    if present, must be OutputIntent for an output intent dictionary.
    S
    name
    (Required) The output intent subtype; must be GTS_PDFX for a
    PDF/X output intent.
    OutputCondition
    ASCII string
    (Optional) An ASCII string concisely identifying the intended
    output device or production condition in human-readable form.
    This is the preferred method of defining such a string for pre-
    sentation to the user.
    OutputConditionIdentifier
    ASCII string
    (Required) An ASCII string identifying the intended output de-
    vice or production condition in human- or machine-readable
    form. If human-readable, this string may be used in lieu of an
    OutputCondition string for presentation to the user.
    A typical value for this entry would be the name of a production
    condition maintained in an industry-standard registry such as
    the ICC Characterization Data Registry (see the Bibliography). If
    the designated condition matches that in effect at production
    time, the production software is responsible for providing the
    corresponding ICC profile as defined in the registry.
    If the intended production condition is not a recognized
    standard, the value of this entry may be Custom or an applica-
    tion-specific, machine-readable name. The DestOutputProfile
    entry defines the ICC profile, and the Info entry is used for fur-
    ther human-readable identification.
    RegistryName
    ASCII string
    (Optional) An ASCII string (conventionally a uniform resource
    identifier, or URI) identifying the registry in which the condi-
    tion designated by OutputConditionIdentifier is defined.
    Info
    text string
    (Required if OutputConditionIdentifier does not specify a standard
    production condition; optional otherwise) A human-readable text
    string containing additional information or comments about the
    intended target device or production condition.
    972
    CHAPTER 10
    Document Interchange
    KEY
    TYPE
    VALUE
    DestOutputProfile
    stream
    (Required if OutputConditionIdentifier does not specify a standard
    production condition; optional otherwise) An ICC profile stream
    defining the transformation from the PDF document’s source
    colors to output device colorants.
    The format of the profile stream is the same as that used in spec-
    ifying an ICCBased color space (see “ICCBased Color Spaces” on
    page 252). The output transformation uses the profile’s “from
    CIE” information (BToA in ICC terminology); the “to CIE”
    (AToB) information can optionally be used to remap source
    color values to some other destination color space, such as for
    screen preview or hardcopy proofing. (See implementation note
    168 in Appendix H.)
    Note: PDF/X is actually a family of standards representing varying levels of con-
    formance. The standard for a given conformance level may prescribe further restric-
    tions on the usage and meaning of entries in the output intent dictionary. Any such
    restrictions take precedence over the descriptions given in Table 10.51.
    The ICC profile information in an output intent dictionary supplements rather
    than replaces that in an ICCBased or default color space (see “ICCBased Color
    Spaces” on page 252 and “Default Color Spaces” on page 257). Those mechanisms
    are specifically intended for describing the characteristics of source color compo-
    nent values. An output intent can be used in conjunction with them to convert
    source colors to those required for a specific production condition or to enable
    the display or proofing of the intended output.
    The data in an output intent dictionary is provided for informational purposes
    only, and PDF consumer applications are free to disregard it. In particular, there
    is no expectation that PDF production tools will automatically convert colors
    expressed in the same source color space to the specified target space before gen-
    erating output. (In some workflows, such conversion may, in fact, be undesirable.
    For example, when working with CMYK source colors tagged with a source ICC
    profile solely for purposes of characterization, converting such colors from four
    components to three and back is unnecessary and will result in a loss of fidelity in
    the values of the black component; see “Implicit Conversion of CIE-Based Color
    Spaces” on page 259 for further discussion.) On the other hand, when source
    colors are expressed in different base color spaces—for example, when combining
    separately generated images on the same PDF page—it is possible (though not re-
    quired) to use the destination profile specified in the output intent dictionary to
    973
    SECTION 10.10
    Prepress Support
    convert source colors to the same target color space. (See implementation note
    169 in Appendix H.)
    Example 10.26 shows a PDF/X output intent dictionary based on an industry-
    standard production condition (CGATS TR 001) from the ICC Characterization
    Data Registry. Example 10.27 shows one for a custom production condition.
    Example 10.26
    <<
    /Type /OutputIntent
    % Output intent dictionary
    /S
    /GTS_PDFX
    /OutputCondition ( CGATS TR 001 ( SWOP ) )
    /OutputConditionIdentifier ( CGATS TR 001 )
    /RegistryName ( http : / / www . color. org )
    /DestOutputProfile 100 0 R
    >>
    100 0 obj
    % ICC profile stream
    << /N 4
    /Length 1605
    /Filter
    /ASCIIHexDecode
    >>
    stream
    00 00 02 0C 61 70 … >
    endstream
    endobj
    Example 10.27
    <<
    /Type /OutputIntent
    % Output intent dictionary
    /S
    /GTS_PDFX
    /OutputCondition ( Coated )
    /OutputConditionIdentifier ( Custom )
    /Info
    ( Coated 150lpi )
    /DestOutputProfile 100 0 R
    >>
    100 0 obj
    % ICC profile stream
    << /N 4
    /Length 1605
    /Filter
    /ASCIIHexDecode
    >>
    stream
    00 00 02 0C 61 70 … >
    endstream
    endobj
    974
    CHAPTER 10
    Document Interchange
    10.10.5
    Trapping Support
    On devices such as offset printing presses, which mark multiple colorants on a
    single sheet of physical medium, mechanical limitations of the device can cause
    imprecise alignment, or misregistration, between colorants. This can produce
    unwanted visual artifacts such as brightly colored gaps or bands around the edges
    of printed objects. In high-quality reproduction of color documents, such arti-
    facts are commonly avoided by creating an overlap, called a trap, between areas of
    adjacent color.
    Figure 10.4 shows an example of trapping. The light and medium grays represent
    two different colorants, which are used to paint the background and the glyph de-
    noting the letter A. The first figure shows the intended result, with the two colo-
    rants properly registered. The second figure shows what happens when the
    colorants are misregistered. In the third figure, traps have been overprinted along
    the boundaries, obscuring the artifacts caused by the misregistration. (For em-
    phasis, the traps are shown here in dark gray; in actual practice, their color would
    be similar to one of the adjoining colors.)
    Intended result
    Misregistration
    Misregistration
    with no trap
    with trap
    FIGURE 10.4 Trapping example
    Trapping can be implemented by the application generating a PDF file, by some
    intermediate application that adds traps to a PDF document, or by the raster
    image processor (RIP) that produces final output. In the last two cases, the trap-
    ping process is controlled by a set of trapping instructions, which define two kinds
    of information:
    • Trapping zones within which traps should be created
    • Trapping parameters specifying the nature of the traps within each zone
    975
    SECTION 10.10
    Prepress Support
    Trapping zones and trapping parameters are discussed fully in Sections 6.3.2 and
    6.3.3, respectively, of the PostScript Language Reference, Third Edition. Trapping
    instructions are not directly specified in a PDF file (as they are in a PostScript
    file). Instead, they are specified in a job ticket that accompanies the PDF file or
    can be embedded within it. Various standards exist for the format of job tickets;
    two of them, JDF (Job Definition Format) and PJTF (Portable Job Ticket For-
    mat), are described in the CIP4 document JDF Specification and in Adobe Tech-
    nical Note #5620, Portable Job Ticket Format (see the Bibliography).
    When trapping is performed before the production of final output, the resulting
    traps are placed in the PDF file for subsequent use. The traps themselves are
    described as a content stream in a trap network annotation (see below). The
    stream dictionary can include additional entries describing the method that was
    used to produce the traps and other information about their appearance.
    Trap Network Annotations
    A complete set of traps generated for a given page under a specified set of trap-
    ping instructions is called a trap network (PDF 1.3). It is a form XObject contain-
    ing graphics objects for painting the required traps on the page. A page may have
    more than one trap network based on different trapping instructions, presumably
    intended for different output devices. All of the trap networks for a given page are
    contained in a single trap network annotation (see Section 8.4, “Annotations”).
    There can be at most one trap network annotation per page, which must be the
    last element in the page’s Annots array (see “Page Objects” on page 144). This en-
    sures that the trap network is printed after all of the page’s other contents. (See
    implementation note 170 in Appendix H.)
    The form XObject defining a trap network is specified as an appearance stream in
    the N (normal) entry of the trap network annotation’s appearance dictionary (see
    Section 8.4.4, “Appearance Streams”). If more than one trap network is defined
    for the same page, the N entry holds a subdictionary containing the alternate trap
    networks, each identified by an arbitrary key. The AS (appearance state) entry in
    the annotation dictionary designates one of them as the current trap network to
    be displayed or printed.
    Note: The trap network annotation’s appearance dictionary may include R (rollover)
    or D (down) entries, but appearances defined in either of these entries are never
    printed.
    976
    CHAPTER 10
    Document Interchange
    Like all annotations, a trap network annotation is defined by an annotation dic-
    tionary (see Section 8.4.1, “Annotation Dictionaries”); its annotation type is
    TrapNet. The AP (appearances), AS (appearance state), and F (flags) entries
    (which ordinarily are optional) must be present, with the Print and ReadOnly
    flags set and all others clear (see Section 8.4.2, “Annotation Flags”). Table 10.52
    shows the additional annotation dictionary entries specific to this type of anno-
    tation.
    The Version and AnnotStates entries, if present, are used to detect changes in the
    content of a page that might require regenerating its trap networks. The Version
    array identifies elements of the page’s content that might be changed by an editing
    application and thus invalidate its trap networks. Because there is at most one
    Version array per trap network annotation (and thus per page), any application
    generating a new trap network must also verify the validity of existing trap net-
    works by enumerating the objects identified in the array and verifying that the
    results exactly match the array’s current contents. Any trap networks found to be
    invalid must be regenerated. (See implementation notes 171 and 172 in Appendix
    H.)
    Beginning with PDF 1.4, the LastModified entry can be used in place of the
    Version array to track changes to a page’s trap network. (The trap network anno-
    tation must include either a LastModified entry or the combination of Version
    and AnnotStates, but not all three.) If the modification date in the LastModified
    entry of the page object (see “Page Objects” on page 144) is more recent than the
    one in the trap network annotation dictionary, the page’s trap networks are in-
    valid and must be regenerated. Note, however, that not all editing applications
    and plug-in extensions correctly maintain these modification dates. This method
    of tracking trap network modifications can be used reliably only in a controlled
    workflow environment where the integrity of the modification dates is assured.
    TABLE 10.52 Additional entries specific to a trap network annotation
    KEY
    TYPE
    VALUE
    Subtype
    name
    (Required) The type of annotation that this dictionary describes; must be
    TrapNet for a trap network annotation.
    LastModified
    date
    (Required if Version and AnnotStates are absent; must be absent if Version and
    AnnotStates are present; PDF 1.4) The date and time (see Section 3.8.3,
    “Dates”) when the trap network was most recently modified.
    977
    SECTION 10.10
    Prepress Support
    KEY
    TYPE
    VALUE
    Version
    array
    (Required if AnnotStates is present; must be absent if LastModified is present)
    An unordered array of all objects present in the page description at the time
    the trap networks were generated and that, if changed, could affect the
    appearance of the page. If present, the array must include the following
    objects:
    • All content streams identified in the page object’s Contents entry (see
    “Page Objects” on page 144)
    • All resource objects (other than procedure sets) in the page’s resource dic-
    tionary (see Section 3.7.2, “Resource Dictionaries”)
    • All resource objects (other than procedure sets) in the resource dictionar-
    ies of any form XObjects on the page (see Section 4.9, “Form XObjects”)
    • All OPI dictionaries associated with XObjects on the page (see Section
    10.10.6, “Open Prepress Interface (OPI)”)
    AnnotStates
    array
    (Required if Version is present; must be absent if LastModified is present) An
    array of name objects representing the appearance states (value of the AS
    entry) for annotations associated with the page. The appearance states must
    be listed in the same order as the annotations in the page’s Annots array (see
    “Page Objects” on page 144). For an annotation with no AS entry, the corre-
    sponding array element should be null. No appearance state should be
    included for the trap network annotation itself.
    FontFauxing
    array
    (Optional) An array of font dictionaries representing fonts that were fauxed
    (replaced by substitute fonts) during the generation of trap networks for the
    page.
    Trap Network Appearances
    Each entry in the N (normal) subdictionary of a trap network annotation’s
    appearance dictionary holds an appearance stream defining a trap network asso-
    ciated with the given page. Like all appearances, a trap network is a stream object
    defining a form XObject (see Section 4.9, “Form XObjects”). The body of the
    stream contains the graphics objects needed to paint the traps making up the trap
    network. Its dictionary entries include, besides the standard entries for a form
    dictionary, the additional entries shown in Table 10.53.
    978
    CHAPTER 10
    Document Interchange
    TABLE 10.53 Additional entries specific to a trap network appearance stream
    KEY
    TYPE
    VALUE
    PCM
    name
    (Required) The name of the process color model that was assumed when
    this trap network was created; equivalent to the PostScript page device
    parameter ProcessColorModel (see Section 6.2.5 of the PostScript Lan-
    guage Reference, Third Edition). Valid values are DeviceGray, DeviceRGB,
    DeviceCMYK, DeviceCMY, DeviceRGBK, and DeviceN.
    SeparationColorNames
    array
    (Optional) An array of names identifying the colorants that were assumed
    when this network was created; equivalent to the PostScript page device
    parameter of the same name (see Section 6.2.5 of the PostScript Language
    Reference, Third Edition). Colorants implied by the process color model
    PCM are available automatically and need not be explicitly declared. If this
    entry is absent, the colorants implied by PCM are assumed.
    TrapRegions
    array
    (Optional) An array of indirect references to TrapRegion objects defining
    the page’s trapping zones and the associated trapping parameters, as de-
    scribed in Adobe Technical Note #5620, Portable Job Ticket Format.
    These references are to objects comprising portions of a PJTF job ticket
    that is embedded in the PDF file. When the trapping zones and parame-
    ters are defined by an external job ticket (or by some other means, such
    as with JDF), this entry is absent.
    TrapStyles
    text string
    (Optional) A human-readable text string that applications can use to de-
    scribe this trap network to the user (for example, to allow switching be-
    tween trap networks).
    Note: Preseparated PDF files (see Section 10.10.3, “Separation Dictionaries”) can-
    not be trapped because traps are defined along the borders between different colors
    and a preseparated file uses only one color. Preseparation must therefore occur after
    trapping, not before. An application preseparating a trapped PDF file is responsible
    for calculating new Version arrays for the separated trap networks.
    10.10.6
    Open Prepress Interface (OPI)
    The workflow in a prepress environment often involves multiple applications in
    areas such as graphic design, page layout, word processing, photo manipulation,
    and document construction. As pieces of the final document are moved from one
    application to another, it is useful to separate the data of high-resolution images,
    which can be quite large—in some cases, many times the size of the rest of the
    document combined—from that of the document itself. The Open Prepress Inter-
    face (OPI) is a mechanism, originally developed by Aldus Corporation, for cre-
    979
    SECTION 10.10
    Prepress Support
    ating low-resolution placeholders, or proxies, for such high-resolution images.
    The proxy typically consists of a downsampled version of the full-resolution
    image, to be used for screen display and proofing. Before the document is print-
    ed, it passes through a filter known as an OPI server, which replaces the proxies
    with the original full-resolution images.
    In PostScript programs, OPI proxies are defined by PostScript code surrounded
    by special OPI comments, which specify such information as the placement and
    cropping of the image and adjustments to its size, rotation, color, and other
    attributes. In PDF, proxies are embedded in a document as image or form
    XObjects with an associated OPI dictionary (PDF 1.2) containing the same infor-
    mation conveyed in PostScript by the OPI comments. Two versions of OPI are
    supported, versions 1.3 and 2.0. In OPI 1.3, a proxy consisting of a single image,
    with no changes in the graphics state, may be represented as an image XObject;
    otherwise it must be a form XObject. In OPI 2.0, the proxy always entails changes
    in the graphics state and hence must be represented as a form XObject. (See
    implementation notes 173 and 174 in Appendix H.)
    An XObject representing an OPI proxy must contain an OPI entry in its image or
    form dictionary (see Table 4.39 on page 340 and Table 4.45 on page 358). The val-
    ue of this entry is an OPI version dictionary (Table 10.54) identifying the version
    of OPI to which the proxy corresponds. This dictionary consists of a single entry,
    whose key is the name 1.3 or 2.0 and whose value is the OPI dictionary defining
    the proxy’s OPI attributes.
    TABLE 10.54 Entry in an OPI version dictionary
    KEY
    TYPE
    VALUE
    version number
    dictionary
    (Required; PDF 1.2) An OPI dictionary specifying the attributes of this proxy
    (see Tables 10.55 and 10.56). The key for this entry must be the name 1.3 or
    2.0, identifying the version of OPI to which the proxy corresponds.
    Note: As in any other PDF dictionary, the key in an OPI version dictionary must be
    a name object. The OPI version dictionary would thus be written in the PDF file in
    either the form
    << /1 . 3 d 0 R >>
    % OPI 1 . 3 dictionary
    or
    << /2 . 0 d 0 R >>
    % OPI 2 . 0 dictionary
    where d is the object number of the corresponding OPI dictionary.
    980
    CHAPTER 10
    Document Interchange
    Tables 10.55 and 10.56 describe the contents of the OPI dictionaries for OPI 1.3
    and OPI 2.0, respectively, along with the corresponding PostScript OPI com-
    ments. The dictionary entries are listed in the order in which the corresponding
    OPI comments should appear in a PostScript program. Complete details on the
    meanings of these entries and their effects on OPI servers can be found in OPI:
    Open Prepress Interface Specification 1.3 (available from Adobe) and Adobe Tech-
    nical Note #5660, Open Prepress Interface (OPI) Specification, Version 2.0.
    TABLE 10.55 Entries in a version 1.3 OPI dictionary
    KEY
    TYPE
    OPI COMMENT
    VALUE
    Type
    name
    (Optional) The type of PDF object that this dic-
    tionary describes; if present, must be OPI for an
    OPI dictionary.
    Version
    number
    (Required) The version of OPI to which this dic-
    tionary refers; must be the number 1.3 (not the
    name 1.3, as in an OPI version dictionary).
    F
    file speci-
    %ALDImageFilename
    (Required) The external file containing the im-
    fication
    age corresponding to this proxy. (See implemen-
    tation note 175 in Appendix H.)
    ID
    byte string
    %ALDImageID
    (Optional) An identifying string denoting the
    image.
    Comments
    text string
    %ALDObjectComments
    (Optional) A human-readable comment, typical-
    ly containing instructions or suggestions to the
    operator of the OPI server on how to handle the
    image.
    Size
    array
    %ALDImageDimensions
    (Required) An array of two integers of the form
    [ pixelsWide pixelsHigh ]
    specifying the dimensions of the image in pixels.
    CropRect
    rectangle
    %ALDImageCropRect
    (Required) An array of four integers of the form
    [ left top right bottom ]
    specifying the portion of the image to be used.
    981
    SECTION 10.10
    Prepress Support
    KEY
    TYPE
    OPI COMMENT
    VALUE
    CropFixed
    array
    %ALDImageCropFixed
    (Optional) An array with the same form and
    meaning as CropRect, but expressed in real
    numbers instead of integers. Default value: the
    value of CropRect.
    Position
    array
    %ALDImagePosition
    (Required) An array of eight numbers of the
    form
    [ llx lly ulx uly urx ury lrx lry ]
    specifying the location on the page of the
    cropped image, where (llx , lly ) are the user space
    coordinates of the lower-left corner, (ulx , uly ) are
    those of the upper-left corner,
    (urx , ury ) are
    those of the upper-right corner, and (lrx , lry ) are
    those of the lower-right corner. The specified
    coordinates must define a parallelogram; that is,
    they must satisfy the conditions
    ulx − llx = urx − lrx
    and
    uly − lly = ury − lry
    The combination of Position and CropRect de-
    termines the image’s scaling, rotation, reflection,
    and skew.
    Resolution
    array
    %ALDImageResolution
    (Optional) An array of two numbers of the form
    [ horizRes vertRes ]
    specifying the resolution of the image in samples
    per inch.
    ColorType
    name
    %ALDImageColorType
    (Optional) The type of color specified by the
    Color entry. Valid values are Process, Spot, and
    Separation. Default value: Spot.
    982
    CHAPTER 10
    Document Interchange
    KEY
    TYPE
    OPI COMMENT
    VALUE
    Color
    array
    %ALDImageColor
    (Optional) An array of four numbers and a byte
    string of the form
    [ C M Y K colorName ]
    specifying the value and name of the color in
    which the image is to be rendered. The values of
    C, M, Y, and K must all be in the range 0.0 to 1.0.
    Default value: [ 0.0 0.0 0.0 1.0 ( Black )].
    Tint
    number
    %ALDImageTint
    (Optional) A number in the range 0.0 to 1.0
    specifying the concentration of the color speci-
    fied by Color in which the image is to be ren-
    dered. Default value: 1.0.
    Overprint
    boolean
    %ALDImageOverprint
    (Optional) A flag specifying whether the image
    is to overprint (true) or knock out (false) under-
    lying marks on other separations. Default value:
    false.
    ImageType
    array
    %ALDImageType
    (Optional) An array of two integers of the form
    [ samples bits ]
    specifying the number of samples per pixel and
    bits per sample in the image.
    GrayMap
    array
    %ALDImageGrayMap
    (Optional) An array of 2n integers in the range 0
    to 65,535 (where n is the number of bits per
    sample) recording changes made to the bright-
    ness or contrast of the image.
    Transparency
    boolean
    %ALDImageTransparency
    (Optional) A flag specifying whether white pix-
    els in the image are to be treated as transparent.
    Default value: true.
    Tags
    array
    %ALDImageAsciiTag< NNN >
    (Optional) An array of pairs of the form
    [ tagNum1 tagText1 … tagNumn tagTextn ]
    where each tagNum is an integer representing a
    TIFF tag number and each tagText is an ASCII
    string representing the corresponding ASCII tag
    value.
    983
    SECTION 10.10
    Prepress Support
    TABLE 10.56 Entries in a version 2.0 OPI dictionary
    KEY
    TYPE
    OPI COMMENT
    VALUE
    Type
    name
    (Optional) The type of PDF object that this dic-
    tionary describes; if present, must be OPI for an
    OPI dictionary.
    Version
    number
    (Required) The version of OPI to which this dic-
    tionary refers; must be the number 2 or 2.0 (not
    the name 2.0, as in an OPI version dictionary).
    F
    file speci-
    %%ImageFilename
    (Required) The external file containing the low-
    fication
    resolution proxy image.
    (See implementation
    note 175 in Appendix H.)
    MainImage
    byte string
    %%MainImage
    (Optional) The pathname of the file containing
    the full-resolution image corresponding to this
    proxy, or any other identifying string that
    uniquely identifies the full-resolution image.
    Tags
    array
    %%TIFFASCIITag
    (Optional) An array of pairs of the form
    [ tagNum1 tagText1 … tagNumn tagTextn ]
    where each tagNum is an integer representing a
    TIFF tag number and each tagText is an ASCII
    string or an array of ASCII strings representing
    the corresponding ASCII tag value.
    Size
    array
    %%ImageDimensions
    (Optional; see note below) An array of two num-
    bers of the form
    [ width height ]
    specifying the dimensions of the image in pixels.
    984
    CHAPTER 10
    Document Interchange
    KEY
    TYPE
    OPI COMMENT
    VALUE
    CropRect
    rectangle
    %%ImageCropRect
    (Optional; see note below) An array of four num-
    bers of the form
    [ left top right bottom ]
    specifying the portion of the image to be used.
    Note: The Size and CropRect entries should either
    both be present or both be absent. If present, they
    must satisfy the conditions
    0 ≤ left < right ≤ width
    and
    0 ≤ top < bottom ≤ height
    Note that in this coordinate space, the positive y
    axis extends vertically downward; hence, the
    requirement that top < bottom.
    Overprint
    boolean
    %%ImageOverprint
    (Optional) A flag specifying whether the image
    is to overprint (true) or knock out (false) under-
    lying marks on other separations. Default value:
    false.
    Inks
    name or
    %%ImageInks
    (Optional) A name object or array specifying the
    array
    colorants to be applied to the image. The value
    may be the name full_color or registration or an
    array of the form
    [ /monochrome name1 tint1 … namen tintn ]
    where each name is a string representing the
    name of a colorant and each tint is a real number
    in the range 0.0 to 1.0 specifying the concentra-
    tion of that colorant to be applied.
    IncludedImageDimensions
    array
    %%IncludedImageDimensions
    (Optional) An array of two integers of the form
    [ pixelsWide pixelsHigh ]
    specifying the dimensions of the included image
    in pixels.
    IncludedImageQuality
    number
    %%IncludedImageQuality
    (Optional) A number indicating the quality of
    the included image. Valid values are 1, 2, and 3.
    APPENDIX A
    Operator Summary
    A
    This appendix lists, in alphabetical order, all the operators used in PDF content
    streams. Table A.1 lists each operator, its corresponding PostScript language op-
    erators (when it is an exact or near-exact equivalent of the PDF operator), a de-
    scription of the operator, and references to the table and page where each
    operator is introduced.
    TABLE A.1 PDF content stream operators
    POSTSCRIPT
    OPERATOR
    EQUIVALENT
    DESCRIPTION
    TABLE
    PAGE
    b
    closepath, fill,
    Close, fill, and stroke path using nonzero winding number
    4.10
    230
    stroke
    rule
    B
    fill, stroke
    Fill and stroke path using nonzero winding number rule
    4.10
    230
    b*
    closepath, eofill,
    Close, fill, and stroke path using even-odd rule
    4.10
    230
    stroke
    B*
    eofill, stroke
    Fill and stroke path using even-odd rule
    4.10
    230
    BDC
    (PDF 1.2) Begin marked-content sequence with property list
    10.7
    851
    BI
    Begin inline image object
    4.42
    352
    BMC
    (PDF 1.2) Begin marked-content sequence
    10.7
    851
    BT
    Begin text object
    5.4
    405
    BX
    (PDF 1.1) Begin compatibility section
    3.29
    152
    c
    curveto
    Append curved segment to path (three control points)
    4.9
    226
    cm
    concat
    Concatenate matrix to current transformation matrix
    4.7
    219
    985
    986
    APPENDIX A
    Operator Summary
    POSTSCRIPT
    OPERATOR
    EQUIVALENT
    DESCRIPTION
    TABLE
    PAGE
    CS
    setcolorspace
    (PDF 1.1) Set color space for stroking operations
    4.24
    287
    cs
    setcolorspace
    (PDF 1.1) Set color space for nonstroking operations
    4.24
    287
    d
    setdash
    Set line dash pattern
    4.7
    219
    d0
    setcharwidth
    Set glyph width in Type 3 font
    5.10
    423
    d1
    setcachedevice
    Set glyph width and bounding box in Type 3 font
    5.10
    423
    Do
    Invoke named XObject
    4.37
    332
    DP
    (PDF 1.2) Define marked-content point with property list
    10.7
    851
    EI
    End inline image object
    4.42
    352
    EMC
    (PDF 1.2) End marked-content sequence
    10.7
    851
    ET
    End text object
    5.4
    405
    EX
    (PDF 1.1) End compatibility section
    3.29
    152
    f
    fill
    Fill path using nonzero winding number rule
    4.10
    230
    F
    fill
    Fill path using nonzero winding number rule (obsolete)
    4.10
    230
    f*
    eofill
    Fill path using even-odd rule
    4.10
    230
    G
    setgray
    Set gray level for stroking operations
    4.24
    288
    g
    setgray
    Set gray level for nonstroking operations
    4.24
    288
    gs
    (PDF 1.2) Set parameters from graphics state parameter
    4.7
    219
    dictionary
    h
    closepath
    Close subpath
    4.9
    227
    i
    setflat
    Set flatness tolerance
    4.7
    219
    ID
    Begin inline image data
    4.42
    352
    j
    setlinejoin
    Set line join style
    4.7
    219
    J
    setlinecap
    Set line cap style
    4.7
    219
    K
    setcmykcolor
    Set CMYK color for stroking operations
    4.24
    288
    987
    APPENDIX A
    Operator Summary
    POSTSCRIPT
    OPERATOR
    EQUIVALENT
    DESCRIPTION
    TABLE
    PAGE
    k
    setcmykcolor
    Set CMYK color for nonstroking operations
    4.24
    288
    l
    lineto
    Append straight line segment to path
    4.9
    226
    m
    moveto
    Begin new subpath
    4.9
    226
    M
    setmiterlimit
    Set miter limit
    4.7
    219
    MP
    (PDF 1.2) Define marked-content point
    10.7
    851
    n
    End path without filling or stroking
    4.10
    230
    q
    gsave
    Save graphics state
    4.7
    219
    Q
    grestore
    Restore graphics state
    4.7
    219
    re
    Append rectangle to path
    4.9
    227
    RG
    setrgbcolor
    Set RGB color for stroking operations
    4.24
    288
    rg
    setrgbcolor
    Set RGB color for nonstroking operations
    4.24
    288
    ri
    Set color rendering intent
    4.7
    219
    s
    closepath,
    Close and stroke path
    4.10
    230
    stroke
    S
    stroke
    Stroke path
    4.10
    230
    SC
    setcolor
    (PDF 1.1) Set color for stroking operations
    4.24
    287
    sc
    setcolor
    (PDF 1.1) Set color for nonstroking operations
    4.24
    288
    SCN
    setcolor
    (PDF 1.2) Set color for stroking operations (ICCBased and
    4.24
    288
    special color spaces)
    scn
    setcolor
    (PDF 1.2) Set color for nonstroking operations (ICCBased
    4.24
    288
    and special color spaces)
    sh
    shfill
    (PDF 1.3) Paint area defined by shading pattern
    4.27
    303
    T*
    Move to start of next text line
    5.5
    406
    Tc
    Set character spacing
    5.2
    398
    Td
    Move text position
    5.5
    406
    988
    APPENDIX A
    Operator Summary
    POSTSCRIPT
    OPERATOR
    EQUIVALENT
    DESCRIPTION
    TABLE
    PAGE
    TD
    Move text position and set leading
    5.5
    406
    Tf
    selectfont
    Set text font and size
    5.2
    398
    Tj
    show
    Show text
    5.6
    407
    TJ
    Show text, allowing individual glyph positioning
    5.6
    408
    TL
    Set text leading
    5.2
    398
    Tm
    Set text matrix and text line matrix
    5.5
    406
    Tr
    Set text rendering mode
    5.2
    398
    Ts
    Set text rise
    5.2
    398
    Tw
    Set word spacing
    5.2
    398
    Tz
    Set horizontal text scaling
    5.2
    398
    v
    curveto
    Append curved segment to path (initial point replicated)
    4.9
    226
    w
    setlinewidth
    Set line width
    4.7
    219
    W
    clip
    Set clipping path using nonzero winding number rule
    4.11
    235
    W*
    eoclip
    Set clipping path using even-odd rule
    4.11
    235
    y
    curveto
    Append curved segment to path (final point replicated)
    4.9
    226
    '
    Move to next line and show text
    5.6
    407
    "
    Set word and character spacing, move to next line, and
    5.6
    407
    show text
    APPENDIX B
    B
    Operators in Type 4
    Functions
    This appendix summarizes the PostScript operators that can appear in a type 4
    function, as discussed in Section 3.9.4, “Type 4 (PostScript Calculator) Func-
    tions.” For details on these operators, see the PostScript Language Reference, Third
    Edition.
    B.1
    Arithmetic Operators
    num1 num2
    add sum
    Return num1 plus num2
    num1 num2
    sub difference
    Return num1 minus num2
    num1 num2
    mul product
    Return num1 times num2
    num1 num2
    div quotient
    Return num1 divided by num2
    int1 int2
    idiv quotient
    Return int1 divided by int2 as an integer
    int1 int2
    mod remainder
    Return remainder after dividing int1 by int2
    num1
    neg num2
    Return negative of num1
    num1
    abs num2
    Return absolute value of num1
    num1
    ceiling num2
    Return ceiling of num1
    num1
    floor num2
    Return floor of num1
    num1
    round num2
    Round num1 to nearest integer
    num1
    truncate num2
    Remove fractional part of num1
    num
    sqrt real
    Return square root of num
    angle
    sin real
    Return sine of angle degrees
    angle
    cos real
    Return cosine of angle degrees
    num den
    atan angle
    Return arc tangent of num/den in degrees
    base exponent
    exp real
    Raise base to exponent power
    num
    ln real
    Return natural logarithm (base e)
    num
    log real
    Return common logarithm (base 10)
    num
    cvi int
    Convert to integer
    num
    cvr real
    Convert to real
    989
    990
    APPENDIX B
    Operators in Type 4 Functions
    B.2
    Relational, Boolean, and Bitwise Operators
    any1 any2
    eq bool
    Test equal
    any1 any2
    ne bool
    Test not equal
    num1 num2
    gt bool
    Test greater than
    num1 num2
    ge bool
    Test greater than or equal
    num1 num2
    lt bool
    Test less than
    num1 num2
    le bool
    Test less than or equal
    bool1 | int1 bool2 | int2
    and bool3 | int3
    Perform logical | bitwise and
    bool1 | int1 bool2 | int2
    or bool3 | int3
    Perform logical | bitwise inclusive or
    bool1 | int1 bool2 | int2
    xor bool3 | int3
    Perform logical | bitwise exclusive or
    bool1 | int1
    not bool2 | int2
    Perform logical | bitwise not
    int1 shift bitshift int2
    Perform bitwise shift of int1 (positive is left)
    - true true
    Return boolean value true
    – false false
    Return boolean value false
    B.3
    Conditional Operators
    bool
    { expr } if
    -
    Execute expr if bool is true
    bool
    { expr1 }
    { expr2 } ifelse
    -
    Execute expr1 if bool is true, expr2 if false
    B.4
    Stack Operators
    any pop
    -
    Discard top element
    any1 any2
    exch any2 any1
    Exchange top two elements
    any dup any any
    Duplicate top element
    any1 … anyn n copy any1 … anyn any1 … anyn
    Duplicate top n elements
    anyn … any0 n index anyn … any0 anyn
    Duplicate arbitrary element
    anyn
    −1 … any0 n jroll any(j−1) mod n … any0 anyn−1 … anyj mod n
    Roll n elements up j times
    APPENDIX C
    Implementation Limits
    C
    In general, PDF does not restrict the size or quantity of things described in the
    file format, such as numbers, arrays, images, and so on. However, a PDF consum-
    er application running on a particular processor and in a particular operating en-
    vironment does have such limits. If an application attempts to perform an action
    that exceeds one of the limits, it displays an error.
    PostScript interpreters also have implementation limits, listed in Appendix B of
    the PostScript Language Reference, Third Edition. It is possible to construct a PDF
    file that does not violate application limits but does not print on a PostScript
    printer. Keep in mind that these limits vary according to the PostScript Lan-
    guageLevel, interpreter version, and the amount of memory available to the inter-
    preter.
    This appendix describes typical limits for Acrobat. These limits fall into two main
    classes:
    • Architectural limits. The hardware on which a viewer application executes im-
    poses certain constraints. For example, an integer is usually represented in 32
    bits, limiting the range of allowed integers. In addition, the design of the soft-
    ware imposes other constraints, such as a limit to the number of elements in an
    array or string.
    • Memory limits. The amount of memory available to a viewer application limits
    the number of memory-consuming objects that can be held simultaneously.
    PDF itself has one architectural limit: Because ten digits are allocated to byte off-
    sets, the size of a file is limited to 1010 bytes (approximately 10 gigabytes).
    Table C.1 describes the architectural limits for Acrobat viewer applications run-
    ning on 32-bit machines. Because Acrobat implementations are subject to these
    991
    992
    APPENDIX C
    Implementation Limits
    limits, applications producing PDF files are strongly advised to remain within
    them. Note, however, that memory limits are often exceeded before architectural
    limits (such as the limit on the number of indirect objects) are reached.
    TABLE C.1 Architectural limits
    QUANTITY
    LIMIT
    DESCRIPTION
    integer
    2,147,483,647
    Largest integer value; equal to 231 − 1.
    -2,147,483,648
    Smallest integer value; equal to −231.
    real
    ± 3.403 × 1038
    Largest and smallest real values (approximate).
    ± 1.175 × 1038
    Nonzero real values closest to 0 (approximate). Values closer
    than these are automatically converted to 0.
    5
    Number of significant decimal digits of precision in fractional
    part (approximate).
    Note: To represent real numbers, Acrobat 6 uses IEEE single-precision floating-point
    numbers, as described in the IEEE Standard for Binary Floating-Point Arithmetic (see
    the Bibliography). Previous versions used 32-bit fixed-point numbers (16 bits on either
    side of the radix point), which have greater precision but a much smaller range than
    IEEE floating-point numbers. (Acrobat 6 still converts floating-point numbers to fixed
    point for some components, such as screen display and fonts.)
    string (in content
    32,767
    Maximum length of a string, in bytes.
    stream)
    Note: This restriction applies only to strings in content streams.
    There is no effective restriction on other strings in PDF files.
    name
    127
    Maximum length of a name, in bytes.
    indirect object
    8,388,607
    Maximum number of indirect objects in a PDF file.
    q/Q nesting
    28
    Maximum depth of graphics state nesting by q and Q operators.
    (This is not a limit of Acrobat as such, but arises from the fact
    that q and Q are implemented by the PostScript gsave and gre-
    store operators when generating PostScript output; see imple-
    mentation note 176 in Appendix H.)
    DeviceN components
    32
    Maximum number of colorants or tint components in a DeviceN
    color space.
    CID
    65,535
    Maximum value of a CID (character identifier).
    993
    APPENDIX C
    Implementation Limits
    Acrobat has some additional architectural limits:
    • Thumbnail images may be no larger than 106 by 106 samples, and should be
    created at one-eighth scale for 8.5-by-11-inch and A4-size pages.
    • The minimum allowed page size is 3 by 3 units in default user space; the maxi-
    mum is 14,400 by 14,400 units. In versions of PDF earlier than 1.6 (Acrobat
    7.0), the size of the default user space unit was fixed at 1⁄ 72 inch, yielding a
    minimum of approximately 0.04 by 0.04 inch and a maximum of 200 by 200
    inches. Beginning with PDF 1.6, the size of the unit may be set on a page-by-
    page basis; the default remains at 1/72 inch. (See implementation note 177 in
    Appendix H.)
    • The magnification factor of a view is constrained to be between approximately
    8 percent and 6400 percent. These limits are not fixed; they vary with the size of
    the page being displayed, as well as with the size of the pages previously viewed
    within the file.
    • When Acrobat reads a PDF file with a damaged or missing cross-reference
    table, it attempts to rebuild the table by scanning all the objects in the file.
    However, the generation numbers of deleted entries are lost if the cross-
    reference table is missing or severely damaged. Reconstruction fails if any ob-
    ject identifiers do not appear at the start of a line or if the endobj keyword does
    not appear at the start of a line. Also, reconstruction fails if a stream contains a
    line beginning with the word endstream, aside from the required endstream
    that delimits the end of the stream.
    Memory limits cannot be characterized as precisely as architectural limits because
    the amount of available memory and the ways in which it is allocated vary from
    one product to another. Memory is automatically reallocated from one use to an-
    other when necessary: when more memory is needed for a particular purpose, it
    can be taken from memory allocated to another purpose if that memory is cur-
    rently unused or its use is nonessential (a cache, for example). Also, data is often
    saved to a temporary file when memory is limited. Because of this behavior, it is
    not possible to state limits for such items as the number of pages in a document,
    number of text annotations or hypertext links on a page, number of graphics ob-
    jects on a page, or number of fonts on a page or in a document.
    994
    APPENDIX C
    Implementation Limits
    APPENDIX D
    Character Sets and
    D
    Encodings
    This appendix lists the character sets and encodings that are assumed to be pre-
    defined in any PDF consumer application. Only simple fonts, encompassing
    Latin text and some symbols, are described here. See “Predefined CMaps” on
    page 442 for a list of predefined CMaps for CID-keyed fonts.
    Section D.1, “Latin Character Set and Encodings,” describes the entire character
    set for the Adobe standard Latin-text fonts. This character set is supported by the
    Times, Helvetica, and Courier font families, which are among the standard 14
    predefined fonts (see “Standard Type 1 Fonts (Standard 14 Fonts)” on page 416).
    For each named character, an octal character code is given in four different en-
    codings: StandardEncoding, MacRomanEncoding, WinAnsiEncoding, and PDF-
    DocEncoding (see Table D.1). Unencoded characters are indicated by a dash (—).
    Section D.2, “PDFDocEncoding Character Set,” describes the entire set of charac-
    ters that can be represented using PDFDocEncoding. It presents these characters
    in numerical order and it describes the Unicode representation of each character.
    This table overlaps the information presented in Section D.1, “Latin Character
    Set and Encodings,” in terms of its presentation of presenting octal character
    codes.
    Section D.3,
    “Expert Set and MacExpertEncoding,” describes the so-called
    “expert” character set, which contains additional characters useful for sophisti-
    cated typography, such as small capitals, ligatures, and fractions. For each named
    character, an octal character code is given in MacExpertEncoding. Note that the
    built-in encoding in an expert font program is usually different from MacEx-
    pertEncoding.
    Sections D.4, “Symbol Set and Encoding,” and D.5, “ZapfDingbats Set and Encod-
    ing,” describe the character sets and built-in encodings for the Symbol and
    995
    996
    APPENDIX D
    Character Sets and Encodings
    ZapfDingbats (ITC Zapf Dingbats) font programs, which are among the standard
    14 predefined fonts. These fonts have built-in encodings that are unique to each
    font. (The characters for ZapfDingbats are ordered by code instead of by name,
    since the names in that font are meaningless.)
    TABLE D.1 Latin-text encodings
    ENCODING
    DESCRIPTION
    StandardEncoding
    Adobe standard Latin-text encoding. This is the built-in encoding
    defined in Type 1 Latin-text font programs (but generally not in
    TrueType font programs). PDF does not have a predefined encod-
    ing named StandardEncoding. However, it is useful to describe
    this encoding, since a font’s built-in encoding can be used as the
    base encoding from which differences are specified in an encod-
    ing dictionary.
    MacRomanEncoding
    Mac OS standard encoding for Latin text in Western writing sys-
    tems. PDF has a predefined encoding named MacRomanEncoding
    that can be used with both Type 1 and TrueType fonts.
    WinAnsiEncoding
    Windows Code Page 1252, often called the “Windows ANSI”
    encoding. This is the standard Windows encoding for Latin text
    in Western writing systems. PDF has a predefined encoding
    named WinAnsiEncoding that can be used with both Type 1 and
    TrueType fonts.
    PDFDocEncoding
    Encoding for text strings in a PDF document outside the docu-
    ment’s content streams. This is one of two encodings (the other
    being Unicode) that can be used to represent text strings; see Sec-
    tion , “Text String Type.” PDF does not have a predefined encod-
    ing named PDFDocEncoding; it is not customary to use this
    encoding to show text from fonts.
    MacExpertEncoding
    An encoding for use with expert fonts—ones containing the
    expert character set. PDF has a predefined encoding named
    MacExpertEncoding. Despite its name, it is not a platform-specific
    encoding; however, only certain fonts have the appropriate char-
    acter set for use with this encoding. No such fonts are among the
    standard 14 predefined fonts.
    997
    SECTION D.1
    Latin Character Set and Encodings
    D.1
    Latin Character Set and Encodings
    CHAR CODE (OCTAL)
    CHAR CODE (OCTAL)
    CHAR
    NAME
    STD
    MAC WIN
    PDF
    CHAR
    NAME
    STD
    MAC WIN
    PDF
    A
    A
    101
    101
    101
    101
    Œ
    OE
    352
    316
    214
    226
    Æ
    AE
    341
    256
    306
    306
    Ó
    Oacute
    —
    356
    323
    323
    Á
    Aacute
    —
    347
    301
    301
    Ô
    Ocircumflex
    —
    357
    324
    324
    Â
    Acircumflex
    —
    345
    302
    302
    Ö
    Odieresis
    —
    205
    326
    326
    Ä
    Adieresis
    —
    200
    304
    304
    Ò
    Ograve
    —
    361
    322
    322
    À
    Agrave
    —
    313
    300
    300
    Ø
    Oslash
    351
    257
    330
    330
    Å
    Aring
    —
    201
    305
    305
    Õ
    Otilde
    —
    315
    325
    325
    Ã
    Atilde
    —
    314
    303
    303
    P
    P
    120
    120
    120
    120
    B
    B
    102
    102
    102
    102
    Q
    Q
    121
    121
    121
    121
    C
    C
    103
    103
    103
    103
    R
    R
    122
    122
    122
    122
    Ç
    Ccedilla
    —
    202
    307
    307
    S
    S
    123
    123
    123
    123
    D
    D
    104
    104
    104
    104
    Š
    Scaron
    —
    —
    212
    227
    E
    E
    105
    105
    105
    105
    T
    T
    124
    124
    124
    124
    É
    Eacute
    —
    203
    311
    311
    Þ
    Thorn
    —
    —
    336
    336
    Ê
    Ecircumflex
    —
    346
    312
    312
    U
    U
    125
    125
    125
    125
    Ë
    Edieresis
    —
    350
    313
    313
    Ú
    Uacute
    —
    362
    332
    332
    È
    Egrave
    —
    351
    310
    310
    Û
    Ucircumflex
    —
    363
    333
    333
    Ð
    Eth
    —
    —
    320
    320
    Ü
    Udieresis
    —
    206
    334
    334
    €
    Euro1
    —
    —
    200
    240
    Ù
    Ugrave
    —
    364
    331
    331
    F
    F
    106
    106
    106
    106
    V
    V
    126
    126
    126
    126
    G
    G
    107
    107
    107
    107
    W
    W
    127
    127
    127
    127
    H
    H
    110
    110
    110
    110
    X
    X
    130
    130
    130
    130
    I
    I
    111
    111
    111
    111
    Y
    Y
    131
    131
    131
    131
    Í
    Iacute
    —
    352
    315
    315
    Ý
    Yacute
    —
    —
    335
    335
    Î
    Icircumflex
    —
    353
    316
    316
    Ÿ
    Ydieresis
    —
    331
    237
    230
    Ï
    Idieresis
    —
    354
    317
    317
    Z
    Z
    132
    132
    132
    132
    Ì
    Igrave
    —
    355
    314
    314
    Ž
    Zcaron2
    —
    —
    216
    231
    J
    J
    112
    112
    112
    112
    a
    a
    141
    141
    141
    141
    K
    K
    113
    113
    113
    113
    á
    aacute
    —
    207
    341
    341
    L
    L
    114
    114
    114
    114
    â
    acircumflex
    —
    211
    342
    342
    Ł
    Lslash
    350
    —
    —
    225
    ´
    acute
    302
    253
    264
    264
    M
    M
    115
    115
    115
    115
    ä
    adieresis
    —
    212
    344
    344
    N
    N
    116
    116
    116
    116
    æ
    ae
    361
    276
    346
    346
    Ñ
    Ntilde
    —
    204
    321
    321
    à
    agrave
    —
    210
    340
    340
    O
    O
    117
    117
    117
    117
    &
    ampersand
    046
    046
    046
    046
    998
    APPENDIX D
    Character Sets and Encodings
    CHAR CODE (OCTAL)
    CHAR CODE (OCTAL)
    CHAR
    NAME
    STD
    MAC WIN
    PDF
    CHAR
    NAME
    STD
    MAC WIN
    PDF
    å
    aring
    —
    214
    345
    345
    ê
    ecircumflex
    —
    220
    352
    352
    ^
    asciicircum
    136
    136
    136
    136
    ë
    edieresis
    —
    221
    353
    353
    ~
    asciitilde
    176
    176
    176
    176
    è
    egrave
    —
    217
    350
    350
    asterisk
    052
    052
    052
    052
    8
    eight
    070
    070
    070
    070
    @
    at
    100
    100
    100
    100
    …
    ellipsis
    274
    311
    205
    203
    ã
    atilde
    —
    213
    343
    343
    —
    emdash
    320
    321
    227
    204
    b
    b
    142
    142
    142
    142
    –
    endash
    261
    320
    226
    205
    \
    backslash
    134
    134
    134
    134
    =
    equal
    075
    075
    075
    075
    |
    bar
    174
    174
    174
    174
    ð
    eth
    —
    —
    360
    360
    {
    braceleft
    173
    173
    173
    173
    !
    exclam
    041
    041
    041
    041
    }
    braceright
    175
    175
    175
    175
    ¡
    exclamdown
    241
    301
    241
    241
    [
    bracketleft
    133
    133
    133
    133
    f
    f
    146
    146
    146
    146
    ]
    bracketright
    135
    135
    135
    135
    fi
    fi
    256
    336
    —
    223
    ˘
    breve
    306
    371
    —
    030
    5
    five
    065
    065
    065
    065
    ¦
    brokenbar
    —
    —
    246
    246
    fl
    fl
    257
    337
    —
    224
    •
    bullet3
    267
    245
    225
    200
    ƒ
    florin
    246
    304
    203
    206
    c
    c
    143
    143
    143
    143
    4
    four
    064
    064
    064
    064
    ˇ
    caron
    317
    377
    —
    031
    ⁄
    fraction
    244
    332
    —
    207
    ç
    ccedilla
    —
    215
    347
    347
    g
    g
    147
    147
    147
    147
    ¸
    cedilla
    313
    374
    270
    270
    ß
    germandbls
    373
    247
    337
    337
    ¢
    cent
    242
    242
    242
    242
    `
    grave
    301
    140
    140
    140
    ˆ
    circumflex
    303
    366
    210
    032
    >
    greater
    076
    076
    076
    076
    :
    colon
    072
    072
    072
    072
    «
    guillemotleft4
    253
    307
    253
    253
    4
    ,
    comma
    054
    054
    054
    054
    »
    guillemotright
    273
    310
    273
    273
    copyright
    —
    251
    251
    251
    ‹
    guilsinglleft
    254
    334
    213
    210
    ¤
    currency1
    250
    333
    244
    244
    ›
    guilsinglright
    255
    335
    233
    211
    d
    d
    144
    144
    144
    144
    h
    h
    150
    150
    150
    150
    †
    dagger
    262
    240
    206
    201
    ˝
    hungarumlaut
    315
    375
    —
    034
    ‡
    daggerdbl
    263
    340
    207
    202
    -
    hyphen5
    055
    055
    055
    055
    °
    degree
    —
    241
    260
    260
    i
    i
    151
    151
    151
    151
    ¨
    dieresis
    310
    254
    250
    250
    í
    iacute
    —
    222
    355
    355
    ÷
    divide
    —
    326
    367
    367
    î
    icircumflex
    —
    224
    356
    356
    $
    dollar
    044
    044
    044
    044
    ï
    idieresis
    —
    225
    357
    357
    ˙
    dotaccent
    307
    372
    —
    033
    ì
    igrave
    —
    223
    354
    354
    ı
    dotlessi
    365
    365
    —
    232
    j
    j
    152
    152
    152
    152
    e
    e
    145
    145
    145
    145
    k
    k
    153
    153
    153
    153
    é
    eacute
    —
    216
    351
    351
    l
    l
    154
    154
    154
    154
    999
    SECTION D.1
    Latin Character Set and Encodings
    CHAR CODE (OCTAL)
    CHAR CODE (OCTAL)
    CHAR
    NAME
    STD
    MAC WIN
    PDF
    CHAR
    NAME
    STD
    MAC WIN
    PDF
    <
    less
    074
    074
    074
    074
    q
    q
    161
    161
    161
    161
    ¬
    logicalnot
    —
    302
    254
    254
    ?
    question
    077
    077
    077
    077
    ł
    lslash
    370
    —
    —
    233
    ¿
    questiondown
    277
    300
    277
    277
    m
    m
    155
    155
    155
    155
    "
    quotedbl
    042
    042
    042
    042
    ¯
    macron
    305
    370
    257
    257
    „
    quotedblbase
    271
    343
    204
    214
    −
    minus
    —
    —
    —
    212
    “
    quotedblleft
    252
    322
    223
    215
    μ
    mu
    —
    265
    265
    265
    ”
    quotedblright
    272
    323
    224
    216
    ×
    multiply
    —
    —
    327
    327
    ‘
    quoteleft
    140
    324
    221
    217
    n
    n
    156
    156
    156
    156
    ’
    quoteright
    047
    325
    222
    220
    9
    nine
    071
    071
    071
    071
    ‚
    quotesinglbase
    270
    342
    202
    221
    ñ
    ntilde
    —
    226
    361
    361
    '
    quotesingle
    251
    047
    047
    047
    #
    numbersign
    043
    043
    043
    043
    r
    r
    162
    162
    162
    162
    o
    o
    157
    157
    157
    157
    ®
    registered
    —
    250
    256
    256
    ó
    oacute
    —
    227
    363
    363
    ˚
    ring
    312
    373
    —
    036
    ô
    ocircumflex
    —
    231
    364
    364
    s
    s
    163
    163
    163
    163
    ö
    odieresis
    —
    232
    366
    366
    š
    scaron
    —
    —
    232
    235
    œ
    oe
    372
    317
    234
    234
    §
    section
    247
    244
    247
    247
    ˛
    ogonek
    316
    376
    —
    035
    ;
    semicolon
    073
    073
    073
    073
    ò
    ograve
    —
    230
    362
    362
    7
    seven
    067
    067
    067
    067
    1
    one
    061
    061
    061
    061
    6
    six
    066
    066
    066
    066
    ½
    onehalf
    —
    —
    275
    275
    /
    slash
    057
    057
    057
    057
    ¼
    onequarter
    —
    —
    274
    274
    space6
    040
    040
    040
    040
    ¹
    onesuperior
    —
    —
    271
    271
    £
    sterling
    243
    243
    243
    243
    ª
    ordfeminine
    343
    273
    252
    252
    t
    t
    164
    164
    164
    164
    º
    ordmasculine
    353
    274
    272
    272
    þ
    thorn
    —
    —
    376
    376
    ø
    oslash
    371
    277
    370
    370
    3
    three
    063
    063
    063
    063
    õ
    otilde
    —
    233
    365
    365
    ¾
    threequarters
    —
    —
    276
    276
    p
    p
    160
    160
    160
    160
    ³
    threesuperior
    —
    —
    263
    263
    paragraph
    266
    246
    266
    266
    ˜
    tilde
    304
    367
    230
    037
    (
    parenleft
    050
    050
    050
    050
    ™
    trademark
    —
    252
    231
    222
    )
    parenright
    051
    051
    051
    051
    2
    two
    062
    062
    062
    062
    %
    percent
    045
    045
    045
    045
    ²
    twosuperior
    —
    —
    262
    262
    period
    056
    056
    056
    056
    u
    u
    165
    165
    165
    165
    ·
    periodcentered
    264
    341
    267
    267
    ú
    uacute
    —
    234
    372
    372
    ‰ perthousand
    275
    344
    211
    213
    û
    ucircumflex
    —
    236
    373
    373
    +
    plus
    053
    053
    053
    053
    ü
    udieresis
    —
    237
    374
    374
    ±
    plusminus
    —
    261
    261
    261
    ù
    ugrave
    —
    235
    371
    371
    1000
    APPENDIX D
    Character Sets and Encodings
    CHAR CODE (OCTAL)
    CHAR CODE (OCTAL)
    CHAR NAME
    STD MAC WIN PDF
    CHAR NAME
    STD MAC WIN PDF
    _
    underscore
    137
    137
    137
    137
    ÿ
    ydieresis
    — 330 377
    377
    v
    v
    166
    166
    166
    166
    ¥
    yen
    245
    264
    245
    245
    w
    w
    167
    167
    167
    167
    z
    z
    172
    172
    172
    172
    x
    x
    170
    170
    170
    170
    ž
    zcaron2
    —
    — 236 236
    y
    y
    171
    171
    171
    171
    0
    zero
    060
    060
    060
    060
    ý
    yacute
    —
    — 375 375
    1. In PDF 1.3, the euro character was added to the Adobe standard Latin character set. It
    is encoded as 200 in WinAnsiEncoding and 240 in PDFDocEncoding, assigning codes
    that were previously unused. Apple changed the Mac OS Latin-text encoding for code
    333 from the currency character to the euro character. However, this incompatible
    change has not been reflected in PDF’s MacRomanEncoding, which continues to map
    code 333 to currency. If the euro character is desired, an encoding dictionary can be
    used to specify this single difference from MacRomanEncoding.
    2. In PDF 1.3, the existing Zcaron and zcaron characters were added to WinAnsiEncoding
    as the previously unused codes 216 and 236.
    3. In WinAnsiEncoding, all unused codes greater than 40 map to the bullet character.
    However, only code 225 is specifically assigned to the bullet character; other codes are
    subject to future reassignment.
    4. The character names guillemotleft and guillemotright are misspelled. The correct spell-
    ing for this punctuation character is guillemet. However, the misspelled names are the
    ones actually used in the fonts and encodings containing these characters.
    5. The hyphen character is also encoded as 255 in WinAnsiEncoding. The meaning of this
    duplicate code is “soft hyphen,” but it is typographically the same as hyphen.
    6. The space character is also encoded as 312 in MacRomanEncoding and as 240 in
    WinAnsiEncoding. This duplicate code signifies a nonbreaking space; it is typographi-
    cally the same as space.
    1001
    SECTION D.2
    PDFDocEncoding Character Set
    D.2
    PDFDocEncoding Character Set
    The column titled NOTES uses the following abbreviations:
    U
    Undefined code point in PDFDocEncoding
    SR
    Unicode codepoint that may require special representation in XML in
    some contexts.
    CHAR-
    DEC
    HEX
    OCTAL
    UNICODE
    UNICODE CHARACTER NAME OR (ALTERNATIVE
    NOTES
    ACTER
    ALIAS)
    ^@
    0
    0x00
    0000
    U+0000
    (NULL)
    U
    ^A
    1
    0x01
    0001
    U+0001
    (START OF HEADING)
    U
    ^B
    2
    0x02
    0002
    U+0002
    (START OF TEXT)
    U
    ^C
    3
    0x03
    0003
    U+0003
    (END OF TEXT)
    U
    ^D
    4
    0x04
    0004
    U+0004
    (END OF TEXT)
    U
    ^E
    5
    0x05
    0005
    U+0005
    (END OF TRANSMISSION)
    U
    ^F
    6
    0x06
    0006
    U+0006
    (ACKNOWLEDGE)
    U
    ^G
    7
    0x07
    0007
    U+0007
    (BELL)
    U
    ^H
    8
    0x08
    0010
    U+0008
    (BACKSPACE)
    U
    ^I
    9
    0x09
    0011
    U+0009
    (CHARACTER TABULATION)
    SR
    ^J
    10
    0x0a
    0012
    U+000A
    (LINE FEED)
    SR
    ^K
    11
    0x0b
    0013
    U+000B
    (LINE TABULATION)
    U
    ^L
    12
    0x0c
    0014
    U+000C
    (FORM FEED)
    U
    ^M
    13
    0x0d
    0015
    U+000D
    (CARRIAGE RETURN)
    SR
    ^N
    14
    0x0e
    0016
    U+000E
    (SHIFT OUT)
    U
    ^O
    15
    0x0f
    0017
    U+000F
    (SHIFT IN)
    U
    ^P
    16
    0x10
    0020
    U+0010
    (DATA LINK ESCAPE)
    U
    ^Q
    17
    0x11
    0021
    U+0011
    (DEVICE CONTROL ONE)
    U
    ^R
    18
    0x12
    0022
    U+0012
    (DEVICE CONTROL TWO)
    U
    ^S
    19
    0x13
    0023
    U+0013
    (DEVICE CONTROL THREE)
    U
    ^T
    20
    0x14
    0024
    U+0014
    (DEVICE CONTROL FOUR)
    U
    ^U
    21
    0x15
    0025
    U+0015
    (NEGATIVE ACKNOWLEDGE)
    U
    ^V
    22
    0x16
    0026
    U+0017
    (SYNCRONOUS IDLE)
    U
    ^W
    23
    0x17
    0027
    U+0017
    (END OF TRANSMISSION BLOCK)
    U
    u
    24
    0x18
    0030
    U+02D8
    BREVE
    v
    25
    0x19
    0031
    U+02C7
    CARON
    1002
    APPENDIX D
    Character Sets and Encodings
    CHAR-
    DEC
    HEX
    OCTAL
    UNICODE
    UNICODE CHARACTER NAME OR (ALTERNATIVE
    NOTES
    ACTER
    ALIAS)
    ^
    26
    0x1a
    0032
    U+02C6
    MODIFIER LETTER CIRCUMFLEX ACCENT
    ·
    27
    0x1b
    0033
    U+02D9
    DOT ABOVE
    ”
    28
    0x1c
    0034
    U+02DD
    DOUBLE ACUTE ACCENT
    ,
    29
    0x1d
    0035
    U+02DB
    OGONEK
    °
    30
    0x1e
    0036
    U+02DA
    RING ABOVE
    ~
    31
    0x1f
    0037
    U+02DC
    SMALL TILDE
    32
    0x20
    0040
    U+0020
    SPACE ( )
    !
    33
    0x21
    0041
    U+0021
    EXCLAMATION MARK
    SR
    "
    34
    0x22
    0042
    U+0022
    QUOTATION MARK (")
    SR
    #
    35
    0x23
    0043
    U+0023
    NUMBER SIGN
    $
    36
    0x24
    0044
    U+0024
    DOLLAR SIGN
    %
    37
    0x25
    0045
    U+0025
    PERCENT SIGN
    &
    38
    0x26
    0046
    U+0026
    AMPERSAND (&)
    '
    39
    0x27
    0047
    U+0027
    APOSTROPHE (')
    (
    40
    0x28
    0050
    U+0028
    LEFT PARENTHESIS
    )
    41
    0x29
    0051
    U+0029
    RIGHT PARENTHESIS
    42
    0x2a
    0052
    U+002A
    ASTERISK
    +
    43
    0x2b
    0053
    U+002B
    PLUS SIGN
    ,
    44
    0x2c
    0054
    U+002C
    COMMA
    -
    45
    0x2d
    0055
    U+002D
    HYPHEN-MINUS
    46
    0x2e
    0056
    U+002E
    FULL STOP (period)
    /
    47
    0x2f
    0057
    U+002F
    SOLIDUS (slash)
    0
    48
    0x30
    0060
    U+0030
    DIGIT ZERO
    1
    49
    0x31
    0061
    U+0031
    DIGIT ONE
    2
    50
    0x32
    0062
    U+0032
    DIGIT TWO
    3
    51
    0x33
    0063
    U+0033
    DIGIT THREE
    4
    52
    0x34
    0064
    U+0034
    DIGIT FOUR
    5
    53
    0x35
    0065
    U+0035
    DIGIT FIVE
    6
    54
    0x36
    0066
    U+0036
    DIGIT SIX
    7
    55
    0x37
    0067
    U+0037
    DIGIT SEVEN
    8
    56
    0x38
    0070
    U+0038
    DIGIT EIGJT
    9
    57
    0x39
    0071
    U+0039
    DIGIT NINE

    Была ли эта страница вам полезна?
    Да!Нет
    4 посетителя считают эту страницу полезной.
    Большое спасибо!
    Ваше мнение очень важно для нас.

    Нет комментариевНе стесняйтесь поделиться с нами вашим ценным мнением.

    Текст

    Матвей Александрович08.09.2026 16:04
    Политика конфиденциальности