OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Profile of ODF + PDF

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]