This page describes a proposal for FOP-specific extensions to XSL-FO to activate PDF-specific features.

Requirements

Today

  • Requested by Jiri Tyr: Initial Page View (-> PDF Document Catalog, /PageMode)

Future

  • Document Catalog's /PageLayout, /OpenAction
  • ViewerPreferences dict: all values
  • other types of possible future extensions include PDF Action dictionaries (with embedded Javascript) to add interactivity

Namespace URI

xmlns:pdf="http://xmlgraphics.apache.org/fop/extensions/pdf"

pdf:document-settings

Andreas proposed fox:pdf-catalog, but since this is highly PDF-specific I'd follow the pattern we used for formats like PCL and PostScript.

Parent: fo:declarations

Format (minimal):

<pdf:document-settings
    page-mode="use-none|use-outlines|use-thumbs|full-screen"/>

Format (future):

<pdf:document-settings
  page-mode="use-none|use-outlines|use-thumbs|full-screen"
  page-layout="single-page|one-column|two-column-left|two-column-right"
  starting-position="someidref"
  initial-zoom="auto|fit|fit-width|fit-height"
  hide-toolbar="true|false"
  hide-menubar="true|false"
  etc. etc.
/>

pdf:dictionary / pdf:entry

Taking into account the suggestion made by Paul Womack, how about something slightly more generic, and more closely resembling PDF, like:

<pdf:dictionary type="catalog" xmlns:pdf="http://xmlgraphics.apache/org/fop/extensions/pdf">
  <pdf:entry key="PageMode" type="name">FullScreen</pdf:entry>
  <pdf:entry key="PageLayout" type="name">SinglePage</pdf:entry>
  <pdf:dictionary type="normal" key="ViewerPreferences">
    <pdf:entry key="HideToolbar" type="boolean">true</pdf:entry>
    <pdf:entry key="HideWindowUI" type="boolean">true</pdf:entry>
    <pdf:entry key="NonFullScreenPageMode" type="name">UseThumbs</pdf:entry>
  </pdf:dictionary>
</pdf:dictionary>

The type attribute is the hint to make sure the catalog dictionary is treated special, and its entries are added to the PDF Document Catalog. The same extension can easily be used for other dictionaries, like ViewerPreferences. Using the same terminology as in the PDF Reference seems to make sense, as it's a PDF extension. Using the exact same possible values could lead to an easier translation to PDF.

Thinking about it some more, and starting to prototype this idea, the entry object seems to be the key, as it is conceivable to also insert a dictionary by specifying it entirely as a PDF expression. Makes me wonder to what extent we should validate the contents... Ultimate flexibility vs. the risk of producing corrupt PDF in case of the slightest glitch/typo (question)

For a prototype implementation, check out http://issues.apache.org/bugzilla/show_bug.cgi?id=45390

Maybe the abstract pdf:entry object would better be replaced by strictly typed objects, to make the representation a bit more compact...?

<pdf:dictionary type="catalog" xmlns:pdf="http://xmlgraphics.apache/org/fop/extensions/pdf">
  <pdf:name key="PageMode">FullScreen</pdf:name>
  <pdf:name key="PageLayout">SinglePage</pdf:name>
  <pdf:dictionary type="normal" key="ViewerPreferences">
    <pdf:boolean key="HideToolbar">true</pdf:boolean>
    <pdf:boolean key="HideWindowUI">true</pdf:boolean>
    <pdf:name key="NonFullScreenPageMode">UseThumbs</pdf:name>
  </pdf:dictionary>
</pdf:dictionary>
  • No labels