Re: [oiic-formation-discuss] My perspective. display perferct?

["Sam Johnston" <samj@samj.net>]

On Mon, Jun 30, 2008 at 5:22 PM, <robert_weir@us.ibm.com> wrote:

"David Gerard" <dgerard@gmail.com> wrote on 06/30/2008 10:56:20 AM:

> 2008/6/30  <robert_weir@us.ibm.com>:
>
> > If users have the expectation of exact preservation of line breaks, etc., it
> > is from long participation in a software monoculture.
>
> As I said, saying "they're wrong to want this" doesn't stop them wanting this.

Right.  But they also want rich creamy ice cream with no calories, zero unemployment with no inflation, money without work, and love without consequences.  I can't stop them from wanting it all.  Having wants beyond needs is part of the human condition.  

Agreed, if they want typesetting then they can use a tool like PageMaker. Multiple decades of poor WYSIWYG implementations has hurt and we'll forever have data that is irretrievably lost or at least out of our reach because of tabs & spaces used for layout, fonts used instead of styles, and other oh-so-common WYSIWYG abominations.

 

But I also note the increasing move toward systems of less fidelity and greater collaborative reach.  For example, emails, blogs, wiki, online editors, etc.  These all have much poorer display/rendering fidelity than a desktop publishing package.  But their immediacy, easy of use and opportunities for instant collaboration are pulling users and documents that once would have been exchanged in DOC files.

Agreed 100%, the future is in collaboration and the next generation of digital natives will not accept what we have put up with for so long.

 

ODF is not here to replace desktop publishing packages.  We're not here to replace PDF.  We're here to do the things that you cannot do with desktop publishing packages.  

Exactly. However if a DTP package wants to embed precise layout information such that it can achieve pixel perfection (while being ignored by other apps) then so be it; if it's interesting enough to be included in the spec by the ODF TC then it can be implemented by others and eventually tested by the IIC TC.

 

> >  Although the format
> > may not encode the details of rendering, in practice the users are
> > accustomed to sharing their documents with others using the exact same
> > application, using the exact operating system, with the exact sameinstalled
> > fonts.  When you have identical software stacks, then achieving
> > interoperability is trivial.  In fact, if everyone ran the same version of
> > Ubuntu, with the same version of OpenOffice, then I guarantee you that every
> > ODF document would render identically for all users as well.
> > However, we don't have the luxury of mandating what operating systems or
> > applications the world will use.  So we're limited to that part of the
> > rendering stack that we can control.
>
> People want this and will do what they have to to get this. If that
> means mandating one application, they'll do that, as they do now with
> MS Word.

You would need to mandate more than the application.  You would need to mandate the version as well.  People actually have a lot less fidelity with Word than they think they do.  An interesting paradox.  The perception of fidelity interchange, to the average user, is much greater than what it is in practice.

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

 

> So a failure of the interoperability TC to address this will drive
> people to think in terms of applications rather than file formats ...
> again. Which would be a failure of addressing interoperability.
>
> You can keep trying to define away the problem, but by doing so you
> will merely perpetuate it and sabotage the application independence of
> ODF. People want layout fidelity; some start does need to be made on
> addressing this need.

I'm not defining the problem away.  I'm just noting that the proposed TC is not obligated to solve all problems in the world.  We're entitled to have a charter scoped to the problems that we can actually solve.  If anyone thinks we can, within the proposed TC, achieve pixel perfection, or anywhere close, then I'm all ears.  I'm also open to good zero calorie ice cream recommendations.  I have wants too, you know.

I'm surprised there has been so much discussion already on definitions et al as it seems fairly obvious. If the spec says something then an implementation should comply; for example, if the spec says 'bold' then the rendered font should be more 'bold' than normal... if it says object will appear at 100x100 pixels from the top right then that's where it should appear... if a table border should be 'on' the line rather than above/below it then so be it. These things are, as Thomas said, testable. Maybe testing orgs will need to use overseas labs, amazon mechanical turk, etc. to do it but if it's in the spec then it can be tested (profiles will break this task up into manageable chunks). Similarly, if you tell your app to make some text 'bold' and the spec says how to represent this in the file then the implementation should use this (and only this) approach.

Unlike PDF, ODF does not (and likely will not ever) concern itself with the exact positioning of each object on the canvas, which is arguably a good thing. We're moving away from pagination too which is another plus, and eventually the concept of a 'page' could go away altogether (webpages aren't paginated for example and pagination in documents & e-books is more of a pain than a feature a lot of the time). I would usually much prefer a mostly-text document with markup for section titles and placeholders for table-of-contents etc. which I can easily search, edit and manipulate programatically than something with too much (or indeed, any) layout info.

Anyway my point is that I think we need to accept that there will be (potentially significant) variation between implementations, versions, platforms, etc. and that this variation will often be out-of-spec and therefore tolerable.

Sam