PDF Export

OpenOffice.org 2.0

Document - ID	Specification Owner	Last Change	Status
	Philipp Lohmann	10/11/05	final
Conforms to	
Applies to	all modules that can print
Task ID(s)	i20327 : ThirdPartyIntegration-MMP-01 PDF Export i15455 – hyperlinks in Writer i19669 – hyperlinks in Impress i12836 – hyperlinks; reset visited color i17336 – tagged PDF 109656 – WriterWeb to PDF using page breaks 108245 – extra page for extra large tables in Writer – addressed in this spec 108878 – blank pages in Calc 112547 – print range in Calc i10388 – image quality i13154 – display of PDF Options i17387 – standard printing Options needed for Impress i12626 – security settings
Category	Feature

Abstract

This document is about enhancements to OOo1.1's PDF export feature. For Ooo2.0 the features most requested by our users should be implemented; namely: improved graphics output, links, document outline, document notes, tagged PDF, presentation transition effects, form controls and document encryption.

i-Team Members

	Name	E-mail Address
Specification Owner	Philipp Lohmann	Philipp.Lohmann@sun.com
User Experience	Matthias Müller-Prove /MMP	mprove@sun.com
Development	Oliver Specht Kai Ahrens Philipp Lohmann Sven Jacobi Niklas Nebel Daniel Vogelheim	Oliver.Specht@sun.com Kai.Ahrens@sun.com Philipp.Lohmann@sun.com Sven.Jacobi@sun.com Niklas.Nebel@sun.com Daniel.Vogelheim@sun.com
Quality Assurance	Hasan Ilter Oliver Craemer Wolfram Garten	Hasan.Ilter@sun.com Oliver.Craemer@sun.com Wolfram.Garten@sun.com
Documentation		

Approved for Implementation

	Approved by	Date
User Experience	MMP	01.06.04
Development	OS, KA, PL, SJ, NN, DVO	01.06.04
Quality Assurance	HI	01.06.04
Documentation		
String Review	Elizabeth Matthis	14.06.04

Document Change History

Rev. Level	Change	Initials	Date
0,1		PL	08.04.04
0,2	Update due to development and user experience feedback	PL	21.04.04
1,0	Finalized	PL	04.08.04
1.1	clarification about how to create push buttons which are to be exported as PDF submit buttons	FS	21.09.04
	German sting change: ~Tagged PDF (capital T) New PDF Optiond dialog mockup (figure 6.1)	MMP	10/15/04
	New Future Issue: Notes view in Impress	MMP	10/11/05

Contents

Glossary	1

1	Motivation	1

2	User Scenarios	1

3	Goals	1

4	Requirements and Dependencies	2

4.1	Requirements	2

4.2	Technical Dependencies	2

5	Competitive Analyses	2

6	Detailed Specification	2

6.1	Export range selection	2

6.2	Improved Graphics output	3

6.3	Hyperlinks	3

6.4	Document outline	3

6.5	Writer and Calc notes	3

6.6	Presentation notes	3

6.7	Transition effects	3

6.8	Tagged PDF	4

6.9	PDF controls	8

6.10	UI for PDF export	9

6.11	Error Conditions	11

7	Future Tasks	11

8	Notes	11

9	References	11

Glossary

Term	Description
DCT	Discrete Cosine Transformation – a lossy image compression algorithm used by e.g. JPEG images
PDF	Portable Document Format, a widely used system independent document format

Motivation

PDF export in OpenOffice.org 1.1 was a much acclaimed feature, however a bunch of issues and requests for enhancement came from our user base. Since good PDF export is undoubtedly a great value-add for OpenOffice.org we should improve this feature for OOo 2.0.

User Scenarios

The user creates a document and exports it to PDF. The absolute minimum is an adequate page per page display of the document (as is the case in OOo 1.1). The ultimate target must be an export that saves as many features of the originating document as possible.

Goals

The goals to achieve in order of priority are:

Improved graphics output

Many users complained about blurry images in PDF files created with OOo 1.1. The reason for this is that images are DCT compressed, which yields bad results for images with sharp borders (e.g. Drawings, logos). We need to give the user the ability to use either lossless compression for images or set the quality level for exported images. This will increase file size of the created PDF which is an accepted fact.

Hyperlinks

One of the most useful features beyond pure content viewing of PDF are hyperlinks. Documents can contain references to other parts of the document, e.g. a table of contents linking to the respective parts of the document. Since this is a feature that OOo's own document formats already possess, we simply need to export the links, too.

Document outline

PDF documents support an outline which e.g. in acrobat reader is visible on the left sidebar. The outline allows for easy document navigation. Since OOo's own documents have an outline, too, we should export it to PDF.

Document notes: Writer/Calc

PDF allows for notes to be added to the actual content. These notes are not normally visible but can be activated like Writer's and Calc's notes

Tagged PDF

Tagged PDF enables other applications to extract the text and document structure of a PDF file. The most requests for tagged PDF came from users of Adobe's Acrobat Reader for PalmOS; this application takes tagged PDF and changes it into a format suitable for displaying on the handheld device.

note: tagged PDF will not be created by Calc in the 2.0 timeframe due to time constraints

PDF controls

PDF supports controls that can be used inside the viewer application. E.g. edit fields can be filled in in a form which can then be send back to the originator.

Transition effects for PDF presentations

PDF allows for transition effects between pages. These should be used by impress as it is a subset of features that are available in OOo's presentations.

PDF encryption and modification rights

note: will not probably not be done in 2.0 timeframe due to time constraints

PDF can be encrypted so that its contents are only accessible using the correct password. In this case also bits can be set that make various operations permissible (like modifying, printing).

Presentation notes

note: will not probably not be done in 2.0 timeframe due to time constraints

It must be possible for a user to add the notes for a presentation to a PDF file. These notes should be appended to the pages of the actual presentation as the presentation should not play with interspersed notes pages.

Requirements and Dependencies

Requirements

<State the requirement(s) of this feature here.>

Technical Dependencies

The actual PDF output has to happen in vcl as currently only vcl has the graphical details necessary to create an actual PDF document (like font files, bitmap code, etc.). The vcl PDF layer gets called by the actual PDF filter which gets fed a metafile by the applications. The metafile is produced by the application code that is also used for printing.

Competitive Analyses

A good analogue for OOo's situation is Adobe's FrameMaker software which creates PDF on the fly out of its own document format.

Detailed Specification

Export range selection

The export range selection remains unchanged from Ooo1.1: options exist to export all pages, a range of pages or only the current selection.

Improved Graphics output

The Ooo1.1 state is that all Graphics with more than 8 bit depth and greater than 31x31 pixel are DCT compressed. The compression quality level depended on the output quality selected by the user and was 30%, 60% or 80% for screen, print and press quality respectively. This compression is way too aggressive for many images, especially those that contain steep changes in contrast like drawings or logos.

For OOo2.0 this needs to be changed: the user should be able to choose between lossless (LZW) image compression and DCT compression. If he chooses DCT compression, then he must be able to enter the quality level. The default selection should be JPEG compression with a quality level of 90 percent. See the according UI elements in .

The PDF size of PDF files created with Ooo2.0 default settings will be larger than with OOo1.1. This is accepted.

Optimization: if the original input for an image was a JPEG file and the images contents was not changed, then the original file should copied into the PDF, regardless what the user entered for image compression; quality cannot get any better than the original file. Exception: if the original file was a JPEG but compressed with much more quality (20% higher) than the user defined, then the JPEG should be compressed anew with the user's chosen quality level.

Additionally the user should have the option to sample down high resolution images as to produce a smaller PDF document. E.g. a typical scanned image has a resolution of 2400 dpi, that is 2400x2400 pixel for one square inch. Unless printed to a high resolution printer this is far more than anyone could need, so the user would probably want to reduce this great amount of data by resampling the image to 300dpi, thereby compressing the image to a 64th of its original size.

Hyperlinks

There are two kinds of hyperlinks available in PDF: links pointing to the document itself and links pointing to an URL (in the latter case on clicking the link a browser gets started with the URL). Both kinds should be supported; no new UI is necessary since links are part of OOo's document types. If a document contains a table of contents and this table contains links to the respective places inside the document, then in the exported PDF the table entries there also must be links to the according document elements.

Document outline

Any document having an outline must export the outline to the PDF document. The PDF outline is simple; it just contains named nodes where each node points to a part of the document. Each node may have subnodes. There is no UI necessary for the document outline.

Writer and Calc notes

Writer's/Calc's notes must be exported as PDF text notes unless the user opts not to export them. PDF notes have the same semantics as Writer's notes: a small icon in the document can be pressed in which case a popup window comes up containing the note content.

Presentation notes

There is no equivalent for presentation notes in PDF. Therefore presentation notes must be appended to the presentation itself; the notes should be handled the same way as when printed with the additional requirement that they must be after the presentation slides themselves. If this were not the case the presentation would include the notes when played which is not desirable.

Transition effects

Page transition effects must be mapped to the transitions possible in PDF. These are

Split horizontal, inward: two lines sweep across the screen horizontally from the edges of the page to its center revealing the new page

Split vertical, inward: like Split horizontal, inward but the lines sweep vertically across the screen

Split horizontal, outward: like Split horizontal inward, but the lines sweep from the center to the edges of the page.

Split vertical, outward: like Split vertical, inward, but the lines sweep from the center to the edges of the page.

Blinds horizontal: multiple horizontal lines move from top to bottom across the screen revealing the new page.

Blinds vertical: multiple vertical lines move from left to right across the the screen revealing the new page.

Box inward: a rectangular box sweeps from the edges of the screen to its center revealing the new page.

Box outward: a rectangular box sweeps from the center to the edges of the screen revealing the new page.

Dissolve: The old page dissolves in a random pattern to reveal the new one

Glitter: The old page dissolves along a moving line to reveal the new one; the direction of the line can be left to right, top to bottom or top-left to bottom-right.

Wipe: a single line moves across the screen revealing the new page; the direction of the line can be left to right, bottom to top, right to left or top to bottom.

Replace: the new page replaces the old page with no effect at all.

The duration for transition effects is per default 1 second (except Replace), this can be changed to an arbitrary number of seconds.

It is also possible to specify the duration in seconds a page will be displayed before the next presentation automatically forwards to the next page.

Tagged PDF

Note: since tagged PDF can significantly enlarge the PDF file produced it must be optional. The default for producing tagged PDF should be “off”.

Note: the next sections describe which PDF tags could be supported; those that actually will be supported can be found in table 1.

Tagged PDF builds on PDF's logical structure facilities. Similar to XML the logical structure the structure of PDF contains the following standard element types:

Grouping elements

Document: the root of the logical structure tree

Part: A large scale division of the document; similar to grouping multiple documents into a “Global document”

Art: Article; a self contained body of text; e.g. a chapter including multiple sections.

Sect: Section; e.g. a heading and multiple paragraphs

Div: Division; a generic block-level element or group of elements

BlockQuote: A portion of text attributed to someone other than the author of the surrounding text

Caption: a brief portion of text describing a table or figure

TOC: Table of contents, contains one or more TOCI elements

TOCI: a TOC item

Index: an index containing references into the document itself

NonStruct: a nondescript grouping element, will not be interpreted by other applications

Block-Level structure elements

paragraph like elements: paragraph (P); Heading(H, H1-H6)

list elements: List (L); list item (LI) a label and the list item body; Label (Lbl) e.g. the number in a numbered list or a bullet; list body (LBody) the descriptive content of a list item

table elements: Table, Table header (TH): label for a column or row, Table row (TR), Table data (TD) a single table cell

Inline-Level structure elements

Span: an inline portion of text; e.g. changes of layout attributes like line height can be marked with a span

Quote: an inline quotation (like BlockQuote, but not in an own paragraph)

Note: an explanatory item like a footnote

Reference: a citation which refers to content elsewhere in the document

BibEntry: (Bibliography entry) a special reference identifying an extern content source

Code: a fragment of program text

Link: marks the content of a hyperlink

Illustration elements

OOo element	Tagged PDF element
Document	Document
Section	Section
Heading1-5	H1-5
Heading6-10	H6
Paragraph	P
TOC	TOC
TOC item	TOCI
Index	Index
Footnote	Note
Bibliography	BibEntry
Hyperlink	Link
Internal link	Link
Figure	Figure
Formula	Formula
Control	Form
List	L, LI
Enumeration	L, LI
Table	Table, TH, TR, TD
Hyphenations, changes of character attributes	Span
Table 1: mapping from OOo elements to tagged PDF elements Figure: a graphical element

Formula: a mathematical formula

Form: a widget element; one form structure element can only point to one widget, so each widget needs its own form element

To establish the logical structure of a document it is necessary that during rendering the PDF writer facility in VCL is called with begin/end calls detailing what kind of structure element begins or ends. Structure elements may be nested (of course), but may never be overlapping; that is a valid sequence would be

begin( article )

begin( section )

begin( heading )

draw some text

end( heading )

begin( paragraph )

draw much text, and perhaps some nice images

end( paragraph )

end( section )

end( article )

but this would be invalid: effects

begin( heading )

begin( paragraph )

draw some text

end( heading ) // error, heading and paragraph overlap

Not only would the latter lead to a syntactical error in PDF but it would also be a logical error in the structure; the same text should be either part of the heading or part of the paragraph, not both.

For an exact mapping of OOo elements to tagged PDF layout elements please refer to Table 1.

Structure attributes

Tagged PDF also defines a standard set of structure attributes which can be used by reflow applications. If possible these attributes should be given also in our PDF export. Structure attributes are always bound to a structural element “owning” them. Most interesting for us are attributes of the Layout, List and Table classes, though there are classes of attributes governing the conversion to other content types (e.g. for HTML or XML).

Note: as with the tags themselves OOo 2.0 will not support all structure attributes. Please find all supported asstributes in table 2.

Some nomenclature: since layout very much depends on the general writing direction, directions need to be neutrally defined. Therefore these terms shall be used:

“block progression” is the direction blocks (e.g. paragraphs) flow to, e.g. this would be top-down for western languages and left-right in vertical Asian languages.

Placement: Inline, Block Writing Mode: LrTb, RlTb, TbRl SpaceBefore, SpaceAfter StartIndent, EndIndent TextAlign: Justify, Center Alternate text Width, Height, Bbox TextDecorationType: Underline BaselineShift Table 2: PDF structure attributes supported by OOo “inline progression” is the direction text flows (e.g. left-right in western languages, right-left in some eastern languages or top-down in vertical Asian languages).

“before edge” is the edge of an element that is adjacent to the previous block level, so is the edge opposite from its center in block progression (e.g. top in western languages).

“after edge” similarly is the opposite edge of “before” (e.g. down in western languages).

“start edge” is the edge of an element that is adjacent to the previous inline level element, so is the edge opposite its center in inline progression (e.g. left in western languages).

“end edge” - you would have guessed it – is the opposite edge of start (e.g. right in western languages).

Standard layout attributes applying to all structural elements

Placement: similar to OOo's anchoring of elements, possible values are Block, Inline, Before, Start, End with the default being “Inline”. An example would be “End” for a right aligned figure.

Block: element is stacked with its sibling elements in block progression direction within its parent.

Inline: element is packed in line with its siblings; this is the default.

Before: element is “before”-aligned. The element is considered as a block occupying the full extent of its parent element in inline direction.

Start: element is “start”-aligned. Other content occupying the same space should run around the element.

End: like Start but for end-alignment.

WritingMode: the general text direction

LrTb: Left-Right-Top-Bottom: the mode for e.g. western languages

RlTb: Right-Left-Top-Bottom: the mode for e.g. hebrew or arabic

TbRl: Top-Bottom-Right-Left: the mode for vertical writing

Standard layout attributes for block level structures:

SpaceBefore: Indentation in “before” direction (e.g. extra line height); has a numerical value.

SpaceAfter: Indentation in “after” direction, has a numerical value.

StartIndent: Indentation in “start” direction, applies only to block level elements with a Placement of “Block” or “Start”; has a numerical value.

EndIndent: Indentation in “end” direction, applies only to block level elements with a Placement of “Block” or “End”; has a numerical value.

TextIndent: Additional indentation for text in start direction that is added to the “StartIndent” above. This only applies to paragraph like block level elements that have content other than block level sub elements (example: a paragraph has an image at the beginning and text after it; this could be expressed as a block level element “Paragraph” with an additional TextIndent).

TextAlign: text alignment, values can be Start (default), Center, End, Justified.

BBox: applies only to “Figure”, “Formula”, “Form” and “Table” elements, describes a bounding box for the structural element. This attribute is normally not necessary to specify as each element is considered to be bounded by the extents of its content. Only if a different bounding box is desired for layout this attribute should be filled.

Width, Heigth: applies for “Figure”, “Formula”, “Form”, “Table”, “TH” and “TD” elements. Adobe strongly recommends to set these attributes for table cells.

BlockAlign: applies for table cells (“TH”, “TD”) only: describes the alignment of a table cell's content; possible values are “Before”, “Middle”, “After”, “Justify”

InlineAlign: applies for table cells (“TH”, “TD”) only: describes the alignment of a table cell's content; possible values are “Start”, “Center”, “End”

Standard layout attributes for inline structure elements

LineHeight: pretty self-descriptive, has a numerical value or the special values “Normal” (line height depends on BaseLineShift) and “Auto” (line height does not depend on BaseLineShift).

BaselineShift: distance by which the baseline is shifted relative from the parent element; examples: subscript, superscript; numerical value: distance in block progression.

TextDecorationType: values are self descriptive; possible values: None, Underline, Overline, LineThrough.

Standard List attributes

There is currently only one list attribute applying to “L” (List) elements only: ListNumbering. It determines what kind of list or enumeration is desired. Possible values are

None

Disc (solid circular bullets are used)

Circle (hollow circular bullet)

Square (solid square bullet)

Decimal (arabic numerals 1-9,10-99,...)

UpperRoman (uppercase roman numerals I, II, III,...)

LowerRoman (lowercase roman numerals i, ii, iii, ...)

UpperAlpha (uppercase roman letters A, B, C, ...)

LowerAlpha (lowercase roman letters a, b, c, ...)

Table attributes

It is possible to tell how many rows and/or columns a single cell spans inside its table:

RowSpan: tells the number of rows a cell occupies

ColSpan: tells the number of columns a cell occupies

Tagged PDF and page content

Tagged PDF has abilities for

distinguishing layout artifacts and original content

specifying a content order to give reflow hints if the PDF gets layout anew

representing the text in a Unicode form as unformatted text

representing word breaks unambiguously

marking text to make it more accessible to visually impaired users

Of these points OOo 2.0 must support the Unicode text representation as this is what is used by converters for PDF that create PDF for handheld devices as well as screen readers. The Unicode text representation is very much like an export to unformatted text; especially it has to contain spaces, no word breaks, etc. . Although this information is in principle already available inside the PDF produced in OOo1.1, the form is not easy to read, especially it is hard to recognize what characters a word comprises. More to the point some existing applications fail to interpret the PDF correctly which hinders our PDF from being converted to some handheld devices. Therefore we need to support the ActualText feature of tagged PDF. ActualText is an entry in a structure element's dictionary. Therefore when ending a structure element the text rendered inside the element must be passed. All text should only be passed once, e.g. a the Unicode stream representing a heading should only be passed to the corresponding heading structural element but not also to the surrounding section structure.

PDF controls

PDF forms support the following controls:

Pushbuttons

Checkboxes

Radiobuttons

Text fields (= Editfields), single-line multi-line

Listboxes

Comboboxes, dropdown, either with text field (akin to our own dropdown combobox) or without text field (akin to our dropdown listbox).

Signature fields; can only be supported with authentication plugins – not our scope for OOo 2.0

Since OOo supports a wider set of controls, controls have to be mapped to this reduced set:

numeric fields, formatted fields, date fields and currency fields must be represented as text fields

all fixed entries must simply be painted (fixed lines, group boxes, fixed texts)

PDF forms support four special action types (aside from usual actions like GoTo or URL which handle document internal and external links): Submit-form, Reset-form, Import-data, JavaScript. Of these we need to support:

Submit-form: sends the document field data to a specified URL; this will be connected to a PushButton. The data is send by the reader application and can be submitted in four formats: PDF (sends the whole document), FDF (sends the control content), HTML and XML.
For creating a push button which is exported to PDF as submit button, the user has to do the following:

Set the "Action" property of the button to "Submit form"

Set the "URL" property of the logical form which the button belongs to the submission URL

One might be tempted to use the button's "URL" property for this. However, this URL cannot be modified in the property browser as long as the "Action" is set to "Submit form". The reason is that OpenOffice.org Writer is not primarily a PDF editor. Thus, the semantics of "Submit form" on a button is already defined for other purposes, and there it means: submit the form which the button belongs to, to the URL which is specified at exactly this form.

Using the button's URL as PDF submission URL would contradict this existing semantics, which is not possible, since for a given document, it is unknown whether the user plans to export it to PDF later on.

Reset-form: resets the document's fields to their initial state; most likely connected to a PushButton

It is necessary for the user to be able to decide in which format a PDF reader application shall send the form data to the server when executing a submit action. It would be possible in principle to define multiple submit actions with different formats within the same document; however this would need UI within the control property editor. This would be disadvantageous from a UI design standpoint since this would imply setting PDF options a general document. Also this would mean this property would have to be made available via OpenOffice.org API. This is not our plan for OpenOffice.org 2.0; instead the PDF export dialog will contain a method to set the export format for all submit actions. Likely this will be good enough for most use cases.

UI for PDF export

Illustration 6.1 PDF Export Dialog

The PDF Options dialog has the same size as the EPS Export Options dialog – (on Windows:444 * 325 pixels). The controls range textfield, quality spin box and resolution combo box have the same size. Right border of all 4 text controls is end of separator lines minus 14 pixels (on Windows). All 4 text controls are vertically aligned with the base line of the labels, i.e. the base line of the labels to the left is the same as the base line of the text of the controls.

The PDF export needs UI for entering the file name to export to and UI to choose options concerning the PDF creation. The distinction between file UI and option UI is for historical and technical reasons – it is not really desirable for the user to have two dialogs pop up when exporting a file. But since all other export filters work similarly this should not be changed for the time being.

As per #i13154# the sequence of file dialog and PDF options dialog should be: options first, file second.

The PDF options UI can be seen in . If encryption were to be implemented for 2.0, the “General” group of fields would have to get specific UI for encryption; the details for encryption would have to reside in another dialog that could be activated from “PDF options”.

UI constraints

The “Quality” metric field must be disabled unless the “JPEG compression” radio button is selected.

The “Pages” text field must be disabled unless the “Pages” radio button is selected.

The default for the “Range” radio button group is “All”.

The default for the “Images” radio button group is “JPEG compression”.

The default value for the “Quality” metric field is 90%.

The default value for “Reduce image resolution” is unchecked.

The “Reduce image resolution” numeric field must be inactive unless the “Reduce image resolution” checkbox is checked.

The default for the “Tagged PDF” check box is unchecked.

The “format” listbox contains the values “FDF”, ”PDF”, “HTML”, “XML” in that order.

The default value for the “format” listbox is “FDF”.

The default value for the “Export notes” check box is checked.

The default value for “Use transition effects” is checked.

“Use transition effects” must be inactive unless a presentation is being exported.

String list

Item	English	German	Comments
Dialog title	PDF Options	PDF Optionen	
Fixedline	Range	Bereich	
Radiobutton	~All	~Alles	
Radiobutton	~Pages	~Seiten	
Radiobutton	~Selection	~Auswahl	
Fixedline	Images	Grafiken	
Radiobutton	~Lossless compression	~Verlustfreie Komprimierung	
Radiobutton	~JPEG compression	~JPEG Komprimierung	
Textfield	~Quality	~Qualität	
Checkbox	~Reduce image resolution	~Grafikauflösung verringern	
Fixedline	General	Allgemein	
Checkbox	~Tagged PDF	~Tagged PDF	
Checkbox	Export ~notes	~Notizen exportieren	
Checkbox	~Use transition effects	~Übergangseffekte benutzen	
ListBox	Submit forms in ~format:	~Format für Formularübermittlung:	

Tab Order

Initial focus should be on the “JPEG Compression” radio button as arguably the most user changing anything at all would change the compression to lossless. Tab order should then be: “JPEG Compression”, “Quality”, “Reduce image resolution” checkbox, “Reduce image resolution” numeric field, “Tagged PDF”, “Export notes”, “Use transition effects”, “Submit forms in format”, “OK”, “Cancel”, “Lossless Compression”, “JPEG Compression”.

Key Board Shortcuts

Alt-a: should activate the “All” radio button

Alt-r: should activate the “Range” radio button

Alt-s: should activate the “Selection” radio button

Alt-l: should activate the “Lossless compression” radio button

Alt-j: should activate the “JPEG compression” radio button

Alt-q: should activate the “Quality” metric field

Alt-r: should activate the “Reduce image resolution” checkbox

Alt-t: should activate the “Tagged PDF” checkbox

Alt-n: should activate the “Export notes” checkbox

Alt-u: should activate the “Use transition effects” checkbox

Alt-f: should activate the “Submit forms in format:” listbox

Error Conditions

Future Tasks

PDF encryption, Impress notes, tagged PDF for Calc: time constraints

Links within the document should be tagged as “Reference” instead of “Link”; currently internal and external links are indistinguishable by the tagging code.

MMP 10/11/05: Offer the option to create a PDF of just the notes view in Impress.

Notes

Goals 8 and 9 (encryption/PDF control bits, presentation notes) will probably not be implemented for 2.0 but for the next version depending on time constraints on development/translation. This specification will be updated accordingly if that changes.

References

PDF Reference: http://partners.adobe.com/asn/tech/pdf/specifications.jsp

PDF Export for OpenOffice.org 2.0

11

http://specs.openoffice.org/appwide/pdf_export/PDFExport.sxw

Philipp Lohmann

2004-04-07T11:32:16

Matthias Müller-Prove