RE: [oiic-formation-discuss] Reference implementation. Layout perfect.

["Hurley, Garry \(L&I - OIT\)" <ghurley@state.pa.us>]

-----Original Message-----
From: Dave Pawson [mailto:dave.pawson@gmail.com]
Sent: Friday, June 13, 2008 9:07 AM
To: oiic-formation-discuss@lists.oasis-open.org
Subject: Re: [oiic-formation-discuss] Reference implementation. Layout
perfect.


2008/6/13  <robert_weir@us.ibm.com>:
>
> "Dave Pawson" <dave.pawson@gmail.com> wrote on 06/13/2008 02:49:47 AM:
>
>> Rob talked about class 4, Rick mentioned an XML language which was used
>> to specify page layout, David Gerard suggested 'layout perfect' as an
>> pragmatic version of pixel perfect.
>> We could benefit from a reference implementation.
>>
>> Taking this in combination,

<snip/>


>
> Or just do it by manual inspection.  There are ways of making that approach
> tractable.
>
> For example, we could, as part of the test case development, produce a
> picture, or simple text description of each test case's expected result.  So
> something like text saying "Circle with dotted green edge and yellow fill".
>  So test inputs would be an ODF document, and image or text description of
> expected results.  Hundreds of pairs of these.

I think that would be challenged quite easily.
How would you originate the items for comparison (the expected test results).
How would you distribute identical items to anyone wanting them?
You would need to define how the comparison is made,
What accuracy provides a pass etc.

>
> Vendors could then write simple automation to take each of the test suite
> ODF files, load it in their editor and create a screen shot which they could
> save in JPG or PNG format.
>
> Then testing becomes a simple task of comparing the two images or the text
> description of the images with the images.  This is something that large
> vendors compare inexpensively at their off-shore labs.


Please look at these two (what, printouts, screenshots) and judge
if they are identical (for some definition of identical).

I know it wouldn't pass an ISO 9000 quality check.

<snip />


regards






-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

---------------------------------------------------------------------
To unsubscribe, e-mail: oiic-formation-discuss-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: oiic-formation-discuss-help@lists.oasis-open.org



******************
Now, first of all, I want this on record that although I work for a state government agency in Pennsylvania, my comments do not reflect those of the Commonwealth of Pennsylvania, its government agencies, or even the majority of its citizens.  That said, I do have a comment on your post, Dave.  First of all, shouldn't we restrict this discussion to the important matter at hand?  I mean, this is a file format, right?  Open Document FORMAT.  I think the first order of business is to describe the way that a file will be organized, what information will be encoded and how it will be encoded.  As for displaying on the screen, it is a moot point.  I know that as a state employee, we have to concern ourselves with accessibility issues.  "How does this document 'display' in a screen reader, or a type magnifier?" for example.  To that end, screen shots are largely implementation specific.  Now, what we need to do is to try to say something like "Okay, we know that we want this type to be in a 24-point Times-New Roman font.  Now, how do we store that information in the file and then read it back to display it properly on screen?"  We don't care if Microsoft Word displays 24-point Times-New Roman with four-pixels-on-screen-per-three-on-paper and MacWriter (is there such a program any more?) displays it with three-pixels-on-screen-and-on-paper display.  All we care about is that both programs know HOW to dsiplay 24-point Times-New Roman type.  Let their implementers figure out how that should look on the monitor.

As for spreadsheets, we need to specify how to write an equation or a value into a cell, specify its width, height, word-wrap, etc.  We don't need to tell anyone how to implement that on a display screen.  As long as we say "red font color for negative numbers" the individual OS and applications programmers can decide what "red" means.

Databases have a specification language called SQL.  (Yes, I know that only the Data Definition Language - DDL - portion of SQL can be loosely called a specification.)  That language is pretty much standardized, and some vendors have extensions to it.  Let us not say that no vendor may extend the standard, but rather that no vendor's extensions shall be adopted as the standard without input from the rest of the standards group.

I only point out these things in light of your ISO 9000 comment.  You see, I did work as an ISO 9001 Internal Auditor for a while at one of my factory jobs.  The way ISO 9000 was explained to me is that we "say what we do and we do what we say".  In other words, let's document what we ARE doing, and stick to it.  

To others in the group, I apologize if my comments seem rude, arrogant, or anything but genuine.  I only want to see the discussion stay focused on what I believe to be the primary goal:  to standardize the way documents are exchanged between similar programs.  Correct me if I am wrong, but isn't that what ODF is all about?

Garry L. Hurley Jr.
Application Developer 2
Office of Information Technology - Bureau of Application Development
PA Department of Labor & Industry
651 Boas Street, Harrisburg, PA 17121 
Phone: 717.506.9373 (UCMS) or 717.346.9799 (Harrisburg)  Fax: 717.506.0798  Mobile: 717.649.0597
www.dli.state.pa.us <http://www.dli.state.pa.us>