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] The importance to users of documents looking the same

----- Original Message ----
From: Peter Dolding <oiaohm@gmail.com
Subject: Re: [oiic-formation-discuss] The importance to users of documents looking the same

> > I'm not sure "most of the information" is correct. As a simple example, ODF styles can have information about 
> > how wide paragraphs ought to be, and how high the text in them should be, but says little about word width. With
> > that in mind, words could be different widths, causing different line breaks and therefore different pagination. It's 
> > difficult to see how you could do deeper testing than what vendors are already going to be doing anyway, and from
> > that point of view it doesn't seem to make sense to ask a TC to do that work also.
> It makes perfect sence for TC to do it.  This way all applications only need to keep one set of test systems.  On top 
> its exactly the same test system not something a coder somewhere has made a error creating and not had it double 
> checked leading to a defective ODF supporting applications..

It makes sense for the new TC to develop test documents. It doesn't make sense for it to test or to feed back on issues/goals which are outside the scope of the ODF TC. I don't know how you can aim for pixel-perfect layout without compromising on separation of content and layout (which is a specific TC goal).

> ODF 1.1 section reference please I have never seen that allowed to change layout at will bit anywhere in the ODF 
> standard docs.  Soft page breaks have there uses for ease of editing as well so where is the docs backing showing 
> that it was not added for editing reasons.

It wasn't added for editing reasons; it was added for viewing reasons. The relevant part of the spec. is page 46 of ODF 1.1:

"A consuming application may handle the element while computing the layout, but it shall not depend on its existence".

Saying that it "may" handle the element means that it doesn't have to. If you think about it, enforcing it would be a slight nonsense: if the application wasn't able to put all the content on a single page in order to comply with the soft break, what would it do? Run the text off the end of the page? Enlarge the page to contain the content?

> This so far is sounding like you don't want ODF enforced to the max of its standard.

No, I'm just pointing out that I don't think the ODF specification goes that far.

It's fine for the new TC to give feedback on where the spec. causes problems. I think it's out of scope for the new TC to tell the ODF TC how the standard should be developed, though - if you want ODF to do pixel-perfect layout, I think that's an issue you take to the ODF TC. It's not an interoperability issue.


Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

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