Page tree
Skip to end of metadata
Go to start of metadata

Introduction

Jaws is only concerned with rendering page descriptions and annotations from PDF files. The operators Jaws uses for this are described in Chapter 4, “Jaws specific features”.

Jaws does not examine any information in a PDF file which is not directly con- nected to rendering either page descriptions or annotations. Jaws provides default (but OEM over ridable) processing for marked content operators used for PDF 1.5 optional content. Other uses of marked content

operators can be handled by device class code. Jaws can render any valid PDF 1.7 page description.

If a PDF file contains multiple alternate images, Jaws will use the DefaultForPrinting image.

If a PDF file contains an OPI form, Jaws will ignore the external file names (even if they refer to external files embedded in the PDF file) and render the contents of the form stream.

If a PDF file uses ICCBased color spaces, Jaws will always render using the alternate color space provided. The Jaws kernel does not perform color correction. The ICC profile embedded in the original ICCBased color space is, however, available to any OEM code device classes that wish to perform color correction. The example color correction code included in the SDK is an example of this.

Jaws will open any encrypted PDF file if encryption support has been added by the OEM.

Any file which contains an Encrypt entry in the trailer dictionary, for which Acrobat Reader reports any security method other than “none”, is encrypted. Note that this can include files which can be viewed and printed by Acrobat Reader without requiring a password from the user and which therefore appear at first sight not to be encrypted. The “security info” dialog box is the correct way to determine whether a PDF file is encrypted or not.

PDF includes the notion of a “font descriptor”, and Adobe Acrobat products incorporate “faux font” technology to make use of this. A font descriptor is embedded in a PDF file for every font used in the document, regardless of whether the font itself is embedded in the file or not. If the font is embedded, Acrobat will use the font when it displays the document. If the font is not embedded, and a font of the same name cannot be found on the computer being used to view and/or print the document, then the font descriptor, along with two resident multiple master fonts, is used to synthesize a faux font to enable the document to be viewed. The faux font matches the original fonts metrics quite closely, but makes little attempt to match its outlines. Faux fonts are restricted to text fonts; symbol fonts must be embedded in the PDF file if they are to be reproduced reliably when the document is viewed or printed.

It is possible to synthesize fonts to match missing fonts in PostScript language files, but this requires a database of font descriptions.

For more information see Faux (synthetic) fonts section of the HTML documentation supplied with the Jaws SDK.

All of the above comments about PostScript language graphics compatibility apply equally to PDF files.

PDF transparency and Jaws

Jaws supports PDF transparency, as introduced in PDF 1.4. This is implemented as a series of device classes which are pushed into place by the kernel when it encounters a PDF 1.4 file.

The user parameter /Transparency controls transparency. The default value is true, which enables rendering of transparent objects; setting it to false will cause the file to be rendered as if all objects were opaque.

Files which use non-white-preserving blend modes may be sensitive to the blend space of the page group. If a file contains an explicit page group, Jaws will use the color space specified; otherwise if a /DefaultCMYK space is specified in the file, Jaws will use that.

The PDF specification requires that any color correction which is performed must be performed after transparency calculations. This means that if you are using transparency with a banding device, you must perform color correction or color conversion (for example, into CMYK + Light Cyan and Light Magenta) after the display list (as has been recommended for some time) and not before, as the transparency device class is installed immediately behind the display list device class. The example color correction code included in the SDK is an example of this. If you are using a frame device, the transparency device class will install itself ahead of any OEM device classes.



  • No labels