[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
On 6/19/08, Simon Calderson <caldersons@yahoo.co.uk> wrote: > > > > ----- 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). > What you are not getting I am not outside the edge of TC coverage. Sorry to say "compromising on separation of content and layout" ODF rendered layout is dependant on content processing. If it was not you would not have images and the like connected to a particular line of text. So that has to be a TC error when covering rendering of the document. If you want separation between content and layout in render please go to PDF and all the document editing problems that causes. I more use the term Layout Perfect. I will tollerate this may not be do able with 1.1 ODF. The information in ODF allows for applications to be tested for layout/rendering inside the rules of ODF.. I am after clarifications for the simple reason I can build it now. But I am looking at some really large tolerance. So bad that over 20 pages one program could be 20 pages and another be 21 and still be inside tolerance. Even worse that difference could the what you see is what you get. Ie application on screen telling you 21 pages when you print you get 20 pages. That is quite a nasty one. Now rules on layout maths and font metrics scaling. Can cut my tolerances right down to + - 2 This is not pixel perfect this is still classed as layout perfect. You can depend on layout being side tolerance so document will not ever have anything more than minor errors. Since a pixel could be anywhere inside 4x4 box and be correct. Compared to by some points threw document now without clarifications being to + - 1 000 000 or higher on the document So 2 000 000 x 2 000 000 as long as the point is somewhere in there its correct. Key thing 2 000 000 x 2 000 000 is larger than most peoples computer screen res. Now to avoid such a completely useless tolerance level it will cause me to build up 8 different tolerance settings to cover all the nice grey factors. So every application will have to have its rendering system tested against 8 different sets of maths. And as long it passes one it passes. That is vial of course the tests are still inside what information ODF standard provides. I am simply after some answers. With answers test makers can develop tests of ODF application rendering. This will for ever draw a line in the sand. Past this point your application is now not rendering layout as per the information the ODF file provide. You have to have a math error somewhere. Of course I want as low as tolerance levels as I can in the test. It makes test writers job simpler. I am focusing on visual rendering. Others can focus on audio rendering for the deaf. Peter Dolding
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]