Profile of ODF + PDF

[robert_weir@us.ibm.com]

Alexander Wright <alexander@silverfish-design.co.uk>
wrote on 06/30/2008 04:44:59 PM:

> On Monday 30 June 2008 17:07:57 Sam Johnston wrote:
> > Currently if you need high fidelity (eg a brochure) you will
most likely
> > manually maintain a PDF alongside the source document (eg DOC).
Embedding
> > PDF in ODF (or vice versa) to give 'pixel perfect + source' sounds
sensible
> > to me, and the quality of the 'rendering' will depend on the
application
> > used to create this compound doc (eg Google Docs vs PageMaker).
> 
> I thought about this too.
> 
> While it has benefits: 
>    Pixel perfect, 
>    Display on devices that can render PDF but can't manage
a 'full' 
> ODF document
> 
> Would it not unnecessarily bulk out documents? 
> Does an editor that can edit the ODF but not create the PDF delete
the PDF 
> chunk?
> 

I did a quick test of a 106 page DOC file to look
at the sizes:

Original DOC file = 1,549 KB
Converted to ODF format = 277 KB
Export PDF version = 757 KB
ODF + PDF in Package = 901 KB

So, even adding the PDF version, the combined package
is still smaller than the original DOC file.  The glories of zip...

In any case, this is an example of something that
could be defined as a profile of ODF + PDF. The profile would likely tell
how the PDF version would be listed in the manifest as well as defining
the rules for dealing with out-of-synch data.  For example, if I am
an ODF+PDF aware application, we could say that it should check the date
stamps of the PDF and ODF streams, and if the ODF data is more recent than
the PDF version, then it should ignore the PDF stream.

-Rob