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)
- From: robert_weir@us.ibm.com
- To: "Peter Dolding" <oiaohm@gmail.com>
- Date: Thu, 12 Jun 2008 10:34:47 -0400
"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.
-Rob
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]