Re: [oiic-formation-discuss] The importance to users of documents looking the same

["Peter Dolding" <oiaohm@gmail.com>]

On Thu, Jun 19, 2008 at 7:09 PM, Simon Calderson <caldersons@yahoo.co.uk> wrote:

Peter,

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

> Most of the information to enforce some layout quality is in standard.
>
> Biggest issues is rounding how its handled is not covered.

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

You increase high a font by a small factor you do the same to its width.  This leads to fontwork failing to render a line of text that should be displayed to user in a circle with a big going around back to center on screen yet prints correctly or worse look like a perfect circle on screen yet it has a gap when printed in quite a few versions of Open Office.  Now poor user no longer has what you see it what you get.  These Font metric handling issues make real messes of editing and printing documents.  I am not asking about word widths at all if font scaling rules are placed in standard there is no need for word width information ever to be stored in ODF ie the font scaling rules can take care of it inside a very small tollerence less than +-1 pixel/printed dot out in high or width over the complete lenth of text line of text.  At worst only a few minor wrapping difference.

What is the policy on font metric scaling on its width.  When a exactly height request of font could not be granted?

Does application have to keep final displayed line length correct inside a small tolerance or not.  If there is a defined tollerence somewhere I have not found spill.    It is completely possible to have a good typesetting format without setting fixed boxes like XPS and PDF.  There are other typesetting formats that don't use that system they depend completely for word widths on strict font processing rules.   There is Zero reason to reduce means to edit to be a typesetting format.

Yes we have heights of things but no formal rules on how you are ment to add them up.

Do you convert them to pixels then add them up.   Do you add the raws number up then coveret to pixels.   Do you add on to prior calculated pixel locations.  How you do this can cause a whole set of different rounding issues.  Its possable to built tests that allow for all these errors.   If all thoose forms of tests are not required it is a large waste of time.  I am after solutions so testing is build able without have to allow for about 8 different versions of ODF interpertation.

What are the forumal rules for applications to perform there layout maths?

If neither of my questions can be answered from the standard we have a flawed standard.   So clarification needs requesting.  I don't know ODF inside and out yet.   So if there are answers no need to go up chain.  No answers must go up chain.

As another example, soft page breaks were put into ODF 1.1 (?) because it was judged relatively difficult for most apps to be good enough at laying out ODF that working out which content was on which page was basically impossible. As I understand it, though, if you can repaginate you can throw away the soft page breaks - the standard explicitly says you can change the layout, even if the content remains the same.

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.

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

Its possable to build rendering test either way.   Just addeds different tollerence rules to the tests.  It also will place limits on how far stuffed up a application can render a ODF document and still be a ODF render.   Get a ruling one way or another.  Then rendering tests can be developed.  With ruling test development can go forwards.

Peter Dolding