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

2008/6/12  <robert_weir@us.ibm.com>:

> 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 3 should be some analogy of xsl-fo. Content derived from class two
with formatting information present. No pagination, just style.
Totally neutral wrt implementation.

Your class 3 then becomes a class 4.5, i.e. moving towards class 4.

> 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.

> 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.

Unsure if this discussion is in scope, but I agree with the idea
that PDF is 'different' to ODF (yeah, one letter :-) and should
have no place in our testing.

> 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.

I'm unsure how such classification is of use to this TC, but it makes sense.


Dave Pawson

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