AW: Regression tests was: Re: Output from NIST test suite

[Peter Kullmann]

J. Pietschmann wrote:
 
 John Austin wrote:
  RedHat 9.0 (my system anyhow) includes a command 'pdftopbm' 
 that will
  convert a PDF to multiple PBM (protable Bit Map) files that might be
  comparable.
 ...
  It would certainly help detect pixel-sized changes.
  That might help regression testing.
 
 We need regression tests badly. Some problems to ponder:
 a) Tests need to be automated for actually being useful.
   JUnit seems the way to go. Unfortuanately, it's still
   underutiliyed in FOP.
 b) We don't have much *unit* tests. There's only the
   UtilityCodeTestSuite.java. We need much more tests for
   basic functionality. The problem seems to be however
   that an elaborated test harness needs to be written in
   order to do unt tests for, e.g. layout managers.
 c) In order to test the whole engine at once, from FO input
   to generating PDF/whatever, well, a binary compare with
   a pregenerated PDF would be as sufficient as comparing
   bitmap images. Problems here:
   + The files to compare against are binary, and consume
a lot of space. Well, take a look at GenericFOPTestCase.java
which uses MD5 sums, one for the FO in order to detect
accidental changes to the source, and one for the result.
   + Even small changes have potential to break the whole test
suite, even if nothing important changed, let's say the
order of entries in a PDF dictionary. Rendering bitmaps
from PDF eliminates this, but then you wont find regressions
in non-visible stuff.
 All in all, if there are 143 template PDFs and a change causes
 mismatches for all, what will you do? Examine everything,
 comparing pixels, check whether there are visible differences
 at all, and then judge whether the original or the newly
 generated PDF is at fault? I don't think this will be done
 often.
 
 Ideas welcome!
 
 J.Pietschmann
 

As an alternative approach for c) one could create tests along 
the following lines: Suppose you want to test left margin 
properties of a block. For this a simple fo file is rendered as 
a bitmap. The bitmap will not be compared to a reference bitmap
but some elementary assertions are calculated. For instance one
such assertion could be: The rectangle of width 1 inch of the
left edge is blank. I don't know of a tool that can do this
but it should be pretty straight forward to implement. 

So, in the test suit one has a piece of fo containing a test 
document and some assertions in java or coded in xml that should
be fulfilled by the rendered image of the fo. 

Assertions could contain some of the following pieces:
- a specified rectangle is blank (or of some specific color)
- a specified rectangle has only colors x and y (to test background
and foreground colors of a block).
- a given line contains the color pattern white, yellow, 
(white, black)*, green, white. IE. a regular expression on the colors
along a line. This could be used to test border colors along 
a horizontal or vertical line through a bordered block.
- along a given line the size of the first and last black region
is at least xxx inches (to test border thickness)

The advantage of this approach seems to me that it is relatively
easy to maintain. The test suite is small (no binaries). It can
easily be automated in junit. 

On the other hand, the approach is limited to relatively simple
test cases. For instance it will not be possible to test font 
height, font style and text adjustments easily.

Peter

Implementation of margin shorthand

[Peter Kullmann]

Hi,

I'm new to FOP development and tried to implement the margin shorthand
to get started (working in the fop-0_20_2-maintain branch).

- foproperties.xml is changed to reflect that margin-top etc can be set
by the margin shorthand and the margin property is changed from
ToBeImplemented to List using a new shorthand parser.

- MarginShorthandParser is new and resembles the GenericShorthandParser.
I think it implements to fo spec correctly. The spec says (in 7.29.14)
for the margin shorthand: 

No. of| Set margin-* property to arg
arguments | top  | right  | bottom  | left
--
1 |1 |  1 |   1 |1
2 |1 |  2 |   1 |2
3 |1 |  2 |   3 |2
4 |1 |  2 |   3 |4

Some remarks:
- The MarginShorthandParser could possibly be generalized to handle
other properties using the same syntax in a
shorthand-{top,right,bottom,left} context. I'm not sure whether there
are such properties (candidates are padding and border-width but these
are handled already in a specialized parser).
- Is it really sensible to have a MarginShorthandParser or could this be
handled elsewhere, e.g. directly in the MarginMaker? 
- I didn't add an error message in the case of a wrong number of
parameters (eg margin=0in 5pt 5pt 5pt 24pt).

Please use the code if you think it's ok and otherwise please tell me
what's not ok with it.


Peter



Index: foproperties.xml
===
RCS file: /home/cvspublic/xml-fop/src/codegen/foproperties.xml,v
retrieving revision 1.25.2.3
diff -r1.25.2.3 foproperties.xml
831a832
   shorthandmargin/shorthand
837a839
   shorthandmargin/shorthand
843a846
   shorthandmargin/shorthand
849a853
   shorthandmargin/shorthand
2093,2094c2097,2098
 datatypeToBeImplemented/datatype
 default/default
---
 datatypeList/datatype
 datatype-parserMarginShorthandParser/datatype-parser


/*
 * $Id: $
 * Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
 * For details on use and redistribution please refer to the
 * LICENSE file included with these sources.
 */

package org.apache.fop.fo;

import java.util.Vector;
import java.util.Enumeration;

public class MarginShorthandParser implements ShorthandParser {

protected Vector list;// Vector of Property objects

public MarginShorthandParser(ListProperty listprop) {
this.list = listprop.getList();
}

protected Property getElement(int index) {
if (list.size()  index)
return (Property)list.elementAt(index);
else
return null;
}

protected int count() {
return list.size();
}

// Stores 1 to 4 values for margin-top, -right, -bottom or -left
public Property getValueForProperty(String propName,
Property.Maker maker,
PropertyList propertyList) {
Property prop = null;
// Check for keyword inherit
if (count() == 1)
{
String sval = ((Property)list.elementAt(0)).getString();
if (sval != null  sval.equals(inherit))
{
return propertyList.getFromParent(propName);
}
}
return convertValueForProperty(propName, maker, propertyList);
}


protected Property convertValueForProperty(String propName,
Property.Maker maker,
PropertyList propertyList) {
Property prop = null;
int idx = 0;

switch (count())
{
case 1: //
idx = 0;
break;
case 2: // 1st value top/bottom, 2nd value left/right
if (propName.equals(margin-top) ||
propName.equals(margin-bottom))
idx = 0;
else
idx = 1;
break;
case 3: // 1st value top, 2nd left/right, 3rd bottom
if (propName == margin-top)
idx = 0;
else if (propName.equals(margin-bottom))
idx = 2;
else
idx = 1;
break;
case 4: // top, right, bottom, left
if (propName.equals(margin-top))
idx = 0;
else if (propName.equals(margin-right))
idx = 1;
else if (propName.equals(margin-bottom))
idx = 2;
else if (propName.equals(margin-left))
idx = 3;
break;
default:
// TODO Error Message: Wrong number of args
return null;
}

Property p = getElement(idx);
prop = maker.convertShorthandProperty(propertyList, p, null);
return prop;
}

}



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]