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] My perspective. display perferct?

"David Gerard" <dgerard@gmail.com> wrote on 06/30/2008 08:24:30 AM:

> 2008/6/30 Thomas Zander <zander@kde.org>:
> > Again, I think you are focussing too much on one small usecase of ODF. The
> > Office-suite part.  There are a LOT more usecases where details like
> > line-breaking is irrelevant and we should keep the balance.
> > Or, in other words, if we focus completely on pixel precision I amsure that
> > in 3 years our work is irrelevant and out of scope for most useages of ODF.
> > Next to that, forcing the details of linebreaking to be in the
> spec is akin to
> > having a hashing algorithm in OOXML, it just doesn't make much sense to
> > reproduce ongoing research in a specification.
> > I am wondering *why* you want to have something in there. Which
> probably means
> > I am asking you the question; what do you think ODF is meant to do?
> Because in the real world at present, users expect that when they make
> a document on one system and load it onto another, the line breaks and
> page breaks will be the same. It frustrates them deeply when this
> expectation is broken.
> You can say that's hard to do and that they're therefore wrong to
> think this, but it's an interoperability example that real users
> expect (as I've posted to the list before with examples - you said
> you'd read all past messages). People do expect that text stays where
> they put it, even if MS Office continually frustrates them on this
> matter.

The layout of text on the page is a product of many factors:

1) The way the data is encoded in the document format
2) The application
3) The installed fonts
4) The operating system (font manager/rasterizer, etc.)

With different systems, the logic for how the rendering is determined is partition across these subsystems in different ways.   In some cases, like with PDF (especially with embedded fonts) the document itself determines the rendering nearly 100%.  All conforming PDF applications on all operating systems give pretty much identical renderings.

But given ASCII test, the document format tells you the characters, but the fonts,t he layout and everything else is determined by the other layers in the stack.

ODF is similar to Word's DOC format, in that the document format determines some things, while other pieces, like line breaks and page breaks, and the exact placement (kerning, etc.) of text is left to the operating system.  This is intentional and by design.

If users have the expectation of exact preservation of line breaks, etc., it is from long participation in a software monoculture.  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 same installed 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.  


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