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: Pixel Perfection (was: Re: [oiic-formation-discuss] (1)(f) and (1)(g) --audience and working language)

"Peter Dolding" <oiaohm@gmail.com> wrote on 06/12/2008 08:21:52 AM:

> Ok lets start off with a few basics.   There is a 3 reason why PDF is
> preferred over word for printing tasks.  Its called embeddable fonts
> and printer independant placement information and flat format.
> Word has a really bad beast option.  Printer Dependant Measurements
> saved in document with no printer independent placement information no
> way to convert this without have the printer driver install on machine
> to look up what the ratios should have been to convert to another
> printer.  So it guesses and screws documents up.  Next problem
> Microsoft own printer independent ratios change between word versions.
>  Poor users is sent straight to stuffed document hell.   This is
> something that should be 100 percent forbid in ODF.  Call it a MS
> design flaw and quality control issue.  Strange thing MS Publisher
> does not have this issue with its files.  So someone at Microsoft does
> know how to keep a size.
> Next font metrics and appearance issues.  Embedding fonts and being
> able to use them cures the font metrics issues.  Of course document is
> larger price of compadiblity.   This still of course leaves other
> issues like font hinting to correct font appearance problems that
> still needs to be resolved for all.
> Pixel perfect not a good target.  Location  and size perfect scaled up
> or down to page should be 100 percent acquirable without question.  If
> same document is printed A4 and A5 and user wishes the A5 document
> should only be a smaller form of the A4 document.  Scalable formating.
>  Cures the printer issues too scaled to the size the printer supports.
>   This kind of perfection is what print shops want.  So when you print
> a document its exactly how the customer wanted it even on a proof.
> Not all times do you need to print a document out full size.  Its
> cheep to print a draft smaller if you are just checking layout saves
> ink and paper.

Thanks for bring this up.  I think we need to be on the same page (no pun intended) with respect to the technical realities of office documents.  Their is this myth of 'pixel perfection' in Office documents.  It doesn't exist, and it never did.  The illusion is perpetuated by the client-side mono-culture.  If everyone runs the same version of MS Office on the same version of MS Windows, and uses the same printer drivers, then 'interoperability' is pretty good.  But the interoperability is not because of information encoded in the document.  It is not a virtue of the document format.  It is because the desktop infrastructure is the same, the fonts, the code, the layout engines, etc.  If you load the same document in different versions of Office, with different installed fonts, or on different machines, you will see subtle and not-subtle differences.

If I could snap my finders and make 90% of all desktops in the world run the same version of OpenOffice on the same version of Linux with the same printer drivers and same fonts, then everyone would be praising ODF for its wonderful interoperability !

But I can't do that.

For sake of argument it may help to think of 4 classes of document formats:

Class 1 formats encoded just the text with no styles and no structure -- ASCII text is the prime example.  It says nothing about styles or layout.  How it renders depends entirely on the application you use to render it.

Class 2 formats encode the text as well as the structure, perhaps with semantics.  XHTML Strict, for example, or DocBook.  Again, no rendering model is defined by the format, and what you see will depend on how your application decides to style the document.

Class 3 formats encode styles/attributes as well as structure, but have implementation-dependent or platform-dependent rules for page layout, i.e., how to deterime the XY position of each character, where line breaks will occur, where page breaks will occur.  These are often WYSIWYG-based, meaning the print driver selected will influence the page margins and therefore the layout.  All office formats out there are in this class:  Microsoft, WordPerfect, Lotus and ODF.

Class 4 formats encode fixed-layout document.  This means the text and graphics is drawn at specific locations on the page, using a device-independent coordinate system.  Fonts are often embedded in the document itself.  Examples include Postscript, PDF and XPS.

Note that ODF being in class 3 instead of 4 is not a bad thing, per se.  There are things that you can do in class 3 that you can not do in class 4, good things, important things.  For example, because the character placement is not fixed, you can re-layout the document as window sizes and page sizes change.  You can increase font size for those with poor eyesight, or when giving a presentation, and the page will magically re-flow.  You can programmatically insert or remove text using a very simple script and then rely on the editor to re-calculate the layout.  

PDF is nice and has its place.  But the fixed layout means you can only rescale (zoom in and out) which makes it harder to use on devices with different screen sizes or aspect ratios.  And have you ever tried to write a program that would insert a new paragraph into a PDF document?  You would need to re-layout the entire document, including line flows, page breaks, page numbers, footnotes, orphan/widow control, etc.  It really is not practical.  That doesn't mean PDF is bad.  It just means that it serves a different purpose.

So, my advice would be for us to do what we can to improve ODF interoperability, within the technical limitations that correspond to the class of document format ODF is.  There is a lot of work we can do in this area.  But if we try to treat ODF as if it encodes a fixed-layout document and has the same fidelity guarantees a fixed-layout format has, then we'll have no end of misery.


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