Re: [oiic-formation-discuss] Profile of ODF + PDF

[jose lorenzo <hozelda@yahoo.com>]

--- On Mon, 6/30/08, robert_weir@us.ibm.com <robert_weir@us.ibm.com> wrote:

> From: robert_weir@us.ibm.com <robert_weir@us.ibm.com>
> Subject: [oiic-formation-discuss] Profile of ODF + PDF
> To: oiic-formation-discuss@lists.oasis-open.org
> Date: Monday, June 30, 2008, 5:14 PM
> 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
... 
> 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.

Primitive, but assuming we can't peak into PDF or at least will not expend the resources to do so (may be out of scope), then it's actually fairly clever.

One problem I see is that the translation into PDF will not necessarily be done the same by the different apps, so we are back to square one in that once you make a tiny edit with a different app and recreate the PDF from that app, it may look very different.

Of course, we could just not allow edits (the ODF would still be useful as it would serve to give easier and higher quality access into the PDF data).

Another possibility is to provide a free converter. The app would only be responsible for editing the ODF and then would apply the freely available ODF2PDF converter. One problem here is that the edit may be legal but tap into bugs or go outside the capabilities of the ODF2PDF converter (an example of going beyond the capabilities would be if an edit pushes a limit boundary of some sort (eg, a very long id string that ODF2PDF can't handle)).

+1 if we tie down these details and any others that crop up.