Re: Batik images and resolution

[Manuel Mall]

On Fri, 12 Aug 2005 06:48 pm, Jeremias Maerki wrote:
> On 12.08.2005 12:00:05 Thomas DeWeese wrote:
> > Jeremias Maerki wrote:
> > > Ideally, the *Reader implementations (analyser package) for each
> > > format should actually read the extents and the bitmap resolution
> > > already. It should not be deferred to the actual codec, if
> > > possible. That makes it possible to work with the image (during
> > > layout) without fully loading it already.
> >
> > Well IMO the right thing is for the image codec to defer the
> > loading of the image data until requested.  This way you only need
> > one set of parsing code to get right and maintain.  It can also
> > simply the coding as you don't have to switch between multiple
> > representations.
> >
> > This is the way the imageio classes work.  Also some of the
> > Batik codec's work this way (Tiff).
>
> Of course, but we have to deal with a mix of different image sources
> here which don't all support that kind of stuff. That's why the
> analyser package exists. Also, it is necessary to support direct
> embedding of JPEG and EPS graphics into PDF and PS, for example. I
> hope I understood you right.
>
Actually 0.20.5 supports direct embedding of TIFF in PDF as well. This 
is a very important feature for our application as we have lots of TIFF 
images (actually incoming faxes) which we bundle into PDFs using FOP. 
Would hate to see that getting lost in the trunk code. Not sure how 
this could be done with the Batik stuff as the PDF renderer would need 
access to the undecoded stream in that case.

Manuel

Re: Relative font weights and font selection

[Vincent Hennebert]

Victor Mote a écrit :

Manuel Mall wrote:


Regarding the "bolder", "lighter" issue and the general font 
selection I looked at the "pre-patch for FOrayFont adaptation 
to Fop" 
(http://issues.apache.org/bugzilla/show_bug.cgi?id=35948) and 
concluded that meddling with the font selection system will 
interfere with the FOray font integration and that the FOray 
font system has addressed most of the font selection issues 
any way (not sure about the "bolder", "lighter" bits though). 
I will therefore back-off from that line of work and wait for 
the FOray font integration to complete, assuming that it is 
still going ahead.



Sorry to be so slow responding. I think Vincent is taking August off, but is
still working on the font integration work.


I confirm. Still one week offline (I'm connected only tonight) and I get back on 
my work on font integration.




Manuel and I have had an off-line conversation about the bolder/lighter
issue, and I think we will need to improve both the interface and the
implementation to handle this and the similar issues for font-stretch. I'll
work on that in the next week or two.


There was a TODO in the code where "bolder" and "lighter" should be handled. 
I've left it as is for now as it is not very important yet. I had the feeling 
that the new font mechanism would ease things but as you say there seems to be 
some work to do. We will have to discuss about that one day...


Cheers,
Vincent

Re: Batik images and resolution

[Jeremias Maerki]

On 12.08.2005 12:00:05 Thomas DeWeese wrote:
> Jeremias Maerki wrote:
> > Ideally, the *Reader implementations (analyser package) for each format
> > should actually read the extents and the bitmap resolution already. It
> > should not be deferred to the actual codec, if possible. That makes it
> > possible to work with the image (during layout) without fully loading it
> > already.
> 
> Well IMO the right thing is for the image codec to defer the loading
> of the image data until requested.  This way you only need one set of
> parsing code to get right and maintain.  It can also simply the coding
> as you don't have to switch between multiple representations.
> 
> This is the way the imageio classes work.  Also some of the
> Batik codec's work this way (Tiff).

Of course, but we have to deal with a mix of different image sources
here which don't all support that kind of stuff. That's why the analyser
package exists. Also, it is necessary to support direct embedding of
JPEG and EPS graphics into PDF and PS, for example. I hope I understood
you right.

> > Of course, that means that someone has to have a deeper understanding of
> > a bitmap format to be able to write the code that extracts the necessary
> > values.
> > 
> > On the other side, the Batik codecs actually parse the resolution
> > information. For PNG, see parse_pHYs_chunk() in [1]. Unfortunately, it
> > doesn't expose that information. 
> 
> Yes it does.  It uses the 'properties' interface to expose this
> (and lots of other) information.  The properties in question are
> "x_pixels_per_unit", "y_pixels_per_unit" & "pixel_units".
> 
> The TIFF reader exposes the entire tiff directory (property
> "tiff_directory").  You can get the resolution info from that
> using the constants in TIFFImageDecoder (TIFF_X_RESOLUTION,
> TIFF_Y_RESOLUTION, TIFF_RESOLUTION_UNIT).

Cool. Thanks for the info. I've already implemented it. I didn't realize
that there was a getProperty() method exposed RenderedImage and the
Batik codecs support these.

Sorry, Manuel, while looking through this information it was so easy to
hack in so I just committed it. 
http://svn.apache.org/viewcvs?rev=232263&view=rev

> > It's interesting to note, that
> > PNGImageDecoder [2] does almost the same as PNGRed. That confuses me.
> > Again, PNGImageDecoder doesn't expose the resolution info, either,
> > although it has it. We may need to ask the Batik guys if they know what
> > this is about. This almost screams for a patch. :-)
> 
> Hmm, I think PNGImageDecoder can be removed, at some point
> the PNGRed class was created as part of the Batik image hierarchy
> from the PNGImageDecoder which was donated by Sun.  I'm not sure
> why the PNGImageDecoder wasn't deleted at the time...
> 
> > [1] 
> > http://svn.apache.org/repos/asf/xmlgraphics/batik/trunk/sources/org/apache/batik/ext/awt/image/codec/PNGRed.java
> > [2] 
> > http://svn.apache.org/repos/asf/xmlgraphics/batik/trunk/sources/org/apache/batik/ext/awt/image/codec/PNGImageDecoder.java
> > 
> > On 12.08.2005 10:56:18 Manuel Mall wrote:
> > 
> >>I was looking at issues related to images not being displayed with their 
> >>correct resolution. As far as I understand all image formats apart from 
> >>GIF (which defaults to 72dpi) do carry resolution information. However, 
> >>it only works for JPEG at the moment. I managed to fix it for BMP 
> >>images by reading / interpreting the appropriate header fields. TIFF 
> >>and PNG are more complicated as the information is buried in the file 
> >>so you actually have to load the image to get to the information. Both 
> >>TIFF and PNG are currently implemented using BatikImage. However, it 
> >>appears that the Batik decoder doesn't make the resolution information 
> >>available. At least its not set in BatikImage.loadImage() and I 
> >>couldn't find a field in the 
> >>org.apache.batik.ext.awt.image.rendered.CachableRed class which looks 
> >>like holding the x and y resolutions.
> >>
> >>Any one knows how to get to the resolution settings for the Batik 
> >>images?
> >>
> >>Thanks
> >>
> >>Manuel
> > 
> > 
> > 
> > 
> > Jeremias Maerki
> > 



Jeremias Maerki

Re: Batik images and resolution

[Manuel Mall]

On Fri, 12 Aug 2005 06:00 pm, Thomas DeWeese wrote:
> Jeremias Maerki wrote:

> Yes it does.  It uses the 'properties' interface to expose this
> (and lots of other) information.  The properties in question are
> "x_pixels_per_unit", "y_pixels_per_unit" & "pixel_units".
>
> The TIFF reader exposes the entire tiff directory (property
> "tiff_directory").  You can get the resolution info from that
> using the constants in TIFFImageDecoder (TIFF_X_RESOLUTION,
> TIFF_Y_RESOLUTION, TIFF_RESOLUTION_UNIT).
>
Thanks Thomas. Yes, I saw that myself, did a quick hack to try it and it 
works. 

Now have to figure out to properly integrate it into FOPs image handling 
as extracting the resolution is obviously image format specific but the 
code is all stuck in the BatikImage class with the PNG and TIFF 
subclasses not having access to the underlying Batik properties stuff. 
Never mind, I'll think of something.

Re: Batik images and resolution

[Thomas DeWeese]

Jeremias Maerki wrote:

Ideally, the *Reader implementations (analyser package) for each format
should actually read the extents and the bitmap resolution already. It
should not be deferred to the actual codec, if possible. That makes it
possible to work with the image (during layout) without fully loading it
already.


   Well IMO the right thing is for the image codec to defer the loading
of the image data until requested.  This way you only need one set of
parsing code to get right and maintain.  It can also simply the coding
as you don't have to switch between multiple representations.

   This is the way the imageio classes work.  Also some of the
Batik codec's work this way (Tiff).


Of course, that means that someone has to have a deeper understanding of
a bitmap format to be able to write the code that extracts the necessary
values.

On the other side, the Batik codecs actually parse the resolution
information. For PNG, see parse_pHYs_chunk() in [1]. Unfortunately, it
doesn't expose that information. 


   Yes it does.  It uses the 'properties' interface to expose this
(and lots of other) information.  The properties in question are
"x_pixels_per_unit", "y_pixels_per_unit" & "pixel_units".

   The TIFF reader exposes the entire tiff directory (property
"tiff_directory").  You can get the resolution info from that
using the constants in TIFFImageDecoder (TIFF_X_RESOLUTION,
TIFF_Y_RESOLUTION, TIFF_RESOLUTION_UNIT).


It's interesting to note, that
PNGImageDecoder [2] does almost the same as PNGRed. That confuses me.
Again, PNGImageDecoder doesn't expose the resolution info, either,
although it has it. We may need to ask the Batik guys if they know what
this is about. This almost screams for a patch. :-)


   Hmm, I think PNGImageDecoder can be removed, at some point
the PNGRed class was created as part of the Batik image hierarchy
from the PNGImageDecoder which was donated by Sun.  I'm not sure
why the PNGImageDecoder wasn't deleted at the time...


[1] 
http://svn.apache.org/repos/asf/xmlgraphics/batik/trunk/sources/org/apache/batik/ext/awt/image/codec/PNGRed.java
[2] 
http://svn.apache.org/repos/asf/xmlgraphics/batik/trunk/sources/org/apache/batik/ext/awt/image/codec/PNGImageDecoder.java

On 12.08.2005 10:56:18 Manuel Mall wrote:

I was looking at issues related to images not being displayed with their 
correct resolution. As far as I understand all image formats apart from 
GIF (which defaults to 72dpi) do carry resolution information. However, 
it only works for JPEG at the moment. I managed to fix it for BMP 
images by reading / interpreting the appropriate header fields. TIFF 
and PNG are more complicated as the information is buried in the file 
so you actually have to load the image to get to the information. Both 
TIFF and PNG are currently implemented using BatikImage. However, it 
appears that the Batik decoder doesn't make the resolution information 
available. At least its not set in BatikImage.loadImage() and I 
couldn't find a field in the 
org.apache.batik.ext.awt.image.rendered.CachableRed class which looks 
like holding the x and y resolutions.


Any one knows how to get to the resolution settings for the Batik 
images?


Thanks

Manuel





Jeremias Maerki

Re: [Bug 36004] - [PATCH] Block content in inline content

[Jeremias Maerki]

The branch is now merged back into the trunk. It's really cool how easy
this is with SVN in comparison to CVS.

On 08.08.2005 23:28:56 Jeremias Maerki wrote:
> So, I'll merge the branch back into the trunk tomorrow. Optionally
> fixing the LMs that don't return KnuthSequences, yet, should be easy.
> You had already done the big part.


Jeremias Maerki

Re: Batik images and resolution

[Jeremias Maerki]

Ideally, the *Reader implementations (analyser package) for each format
should actually read the extents and the bitmap resolution already. It
should not be deferred to the actual codec, if possible. That makes it
possible to work with the image (during layout) without fully loading it
already.

Of course, that means that someone has to have a deeper understanding of
a bitmap format to be able to write the code that extracts the necessary
values.

On the other side, the Batik codecs actually parse the resolution
information. For PNG, see parse_pHYs_chunk() in [1]. Unfortunately, it
doesn't expose that information. It's interesting to note, that
PNGImageDecoder [2] does almost the same as PNGRed. That confuses me.
Again, PNGImageDecoder doesn't expose the resolution info, either,
although it has it. We may need to ask the Batik guys if they know what
this is about. This almost screams for a patch. :-)


[1] 
http://svn.apache.org/repos/asf/xmlgraphics/batik/trunk/sources/org/apache/batik/ext/awt/image/codec/PNGRed.java
[2] 
http://svn.apache.org/repos/asf/xmlgraphics/batik/trunk/sources/org/apache/batik/ext/awt/image/codec/PNGImageDecoder.java

On 12.08.2005 10:56:18 Manuel Mall wrote:
> I was looking at issues related to images not being displayed with their 
> correct resolution. As far as I understand all image formats apart from 
> GIF (which defaults to 72dpi) do carry resolution information. However, 
> it only works for JPEG at the moment. I managed to fix it for BMP 
> images by reading / interpreting the appropriate header fields. TIFF 
> and PNG are more complicated as the information is buried in the file 
> so you actually have to load the image to get to the information. Both 
> TIFF and PNG are currently implemented using BatikImage. However, it 
> appears that the Batik decoder doesn't make the resolution information 
> available. At least its not set in BatikImage.loadImage() and I 
> couldn't find a field in the 
> org.apache.batik.ext.awt.image.rendered.CachableRed class which looks 
> like holding the x and y resolutions.
> 
> Any one knows how to get to the resolution settings for the Batik 
> images?
> 
> Thanks
> 
> Manuel



Jeremias Maerki

Batik images and resolution

[Manuel Mall]

I was looking at issues related to images not being displayed with their 
correct resolution. As far as I understand all image formats apart from 
GIF (which defaults to 72dpi) do carry resolution information. However, 
it only works for JPEG at the moment. I managed to fix it for BMP 
images by reading / interpreting the appropriate header fields. TIFF 
and PNG are more complicated as the information is buried in the file 
so you actually have to load the image to get to the information. Both 
TIFF and PNG are currently implemented using BatikImage. However, it 
appears that the Batik decoder doesn't make the resolution information 
available. At least its not set in BatikImage.loadImage() and I 
couldn't find a field in the 
org.apache.batik.ext.awt.image.rendered.CachableRed class which looks 
like holding the x and y resolutions.

Any one knows how to get to the resolution settings for the Batik 
images?

Thanks

Manuel

Re: Reload in AWT Viewer broken due to parsing error.

[Jeremias Maerki]

I've just fixed it. See:
http://svn.apache.org/viewcvs?rev=232236&view=rev

On 11.08.2005 17:10:15 richardw wrote:
> [EMAIL PROTECTED] writes:
>  > 
>  > I've just noticed that the reload function in the awt viewer is broken.
>  > This also breaks all the widgets which rely on it, such as the scaling
>  > and scrolling mode ones. This is a fairly recent regression. It's not a c
> 
> Oops. Sent too soon. I was going to say it doesn't appear to be a bug
> directly in the awt viewer itself or the java2d rendering engine as
> I've checked both of these. Anyone got any suggestions where I should
> start looking ? The following exceptions are thrown whenever the reload
> is called. All the exceptions appears to originate in
> FObj.checkId(String id) but this hasn't changed in ages,
> 
> Richard
> 
> 
> 
> javax.xml.transform.TransformerException: 
> org.apache.fop.fo.ValidationException: 
> file:///home/richard/fop-head/xml-fop/reportimg.fo:40,60 Property id "N2528" 
> previously used; id values must be unique in document.
>   at org.apache.fop.apps.InputHandler.render(InputHandler.java:123)
>   at 
> org.apache.fop.render.awt.viewer.PreviewPanel$Reloader.run(PreviewPanel.java:331)
> 
> -
> 
> javax.xml.transform.TransformerException: 
> org.apache.fop.fo.ValidationException: 
> file:///home/richard/fop-head/xml-fop/reportimg.fo:40,60 Property id "N2528" 
> previously used; id values must be unique in document.
>   at 
> org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:469)
>   at org.apache.fop.apps.InputHandler.render(InputHandler.java:120)
>   at 
> org.apache.fop.render.awt.viewer.PreviewPanel$Reloader.run(PreviewPanel.java:331)
> Caused by: org.apache.fop.fo.ValidationException: 
> file:///home/richard/fop-head/xml-fop/reportimg.fo:40,60 Property id "N2528" 
> previously used; id values must be unique in document.
>   at org.apache.fop.fo.FObj.checkId(FObj.java:142)
>   at 
> org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:141)
>   at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:262)
>   at 
> org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1020)
>   at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
> Source)
>   at 
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown 
> Source)
>   at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
>  Source)
>   at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
> Source)
>   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
>   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
>   at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
>   at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
>   at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
> Source)
>   at 
> org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:452)
>   ... 2 more
> -
> org.apache.fop.fo.ValidationException: 
> file:///home/richard/fop-head/xml-fop/reportimg.fo:40,60 Property id "N2528" 
> previously used; id values must be unique in document.
>   at org.apache.fop.fo.FObj.checkId(FObj.java:142)
>   at 
> org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:141)
>   at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:262)
>   at 
> org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1020)
>   at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
> Source)
>   at 
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown 
> Source)
>   at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
>  Source)
>   at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
> Source)
>   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
>   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
>   at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
>   at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
>   at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
> Source)
>   at 
> org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:452)
>   at org.apache.fop.apps.InputHandler.render(InputHandler.java:120)
>   at 
> org.apache.fop.render.awt.viewer.PreviewPanel$Reloader.run(PreviewPanel.java:331)
> 
> -
> 
> javax.xml.transform.TransformerException: 
> org.apache.fop.fo.ValidationException: 
> file:///home/richard/fop-head/xml-fop/reportimg.fo:40,60 Property id "N2528" 
> previously used;

DO NOT REPLY [Bug 36146] - [PATCH] Image scaling broken in Java2d based renderers.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36146


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
Summary|[PATCH] Image scaling broken|[PATCH] Image scaling broken
   |in Java2d based renderers.  |in Java2d based renderers.




--- Additional Comments From [EMAIL PROTECTED]  2005-08-12 10:26 ---
Applied. Thanks!

While looking at your patch I realized there were a couple of other problems 
concerning images in the Java2DRenderer:
- JPEG painting doesn't always work (It's currently handled differently from 
the other formats)
- Clipping is not implemented

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: Code cleanup questions

[Jeremias Maerki]

On 11.08.2005 23:09:46 J.Pietschmann wrote:
> Hi devs,
> 
> in yet another attempt at getting back into FOP development I got
> distracted again by question regarding cleanup and testcases.

Rubbing my hands :-)

> - Do we still need the various .cvsignore files?

No. Their content has been converted to SVN properties.

> - build.xml
>   *  Do we still need the htmldoc, pdfdoc and various html-* targets?
>  The html-* targets probably wont run anyway.

I guess not. The build could instead call Forrest. In Barcode4J I have
split a build-dist.xml off of the main build which is used to build
documentation and the distribution. 

>   *  The "prepare-docs" target seems to be orphaned.

Agreed.

>   *  Why does the "package" target depend on "hyphenation-jar"?

Probably a simple oversight.

>   *  What's the purpose of "hyphenation-jar", anyway?

To provide the default set of hyphenation patterns distributed with FOP
that can be used instead of the one from OFFO? Not sure. Just realized
that fop-hyph.jar is empty on my machine. Oops.

>   *  Why is there a "compile-src" and an empty "compile"?

We might have had additional steps in the past. Optimize away...

>   *  Does anybody run the "test" target?

I don't. Not stable enough.

> - The README in /docs is outdated
> - Much of the content in /docs seems to be obsolete too.

Right. That's some left-over from the docs-refactoring.

> - Shouldn't the java examples reuse FO/SVG/XML from the FO examples
>directory rather than provide its own sample sources?

Not necessarily. These are minimal files. Focus is on Java code. The
stuff in FO examples are feature demos.

> - Is the FOP servlet considered an example or rather an end user
>application like the FOP CLI?

IMO, it's an example which is only usable for people with very basic
needs. I think it needs some additional work to become more generally
usable. That's why I'm not 100% happy with its placement. Examples was
not ideal, either. I don't even remember what I said back then when we
moved to servlet, :-( but if I haven't changed my mind in the meantime I
don't consider it an integral part of the FOP sources. The servlet must
be easily found and is ideally easily customized and extended separately
from the normal FOP source code, i.e. copy away a directory (with its
own build) and start improving the servlet. Just an idea

> - The /src/conf/web.xml for the FOP servlet seems to be a bit out of
>place. E.g. the AWT viewer has its jarred-in resources locally stored.

Shrug.

> - Shouldn't the TestConverter.java and perhaps the RunTest.java files
>be moved to the /test tree? Or, the other way around, move all the
>Java files from /test into the /src/java subtree and keep only the
>data files in /test? (I know it's custom to put JUnit test cases in
>/test, but our /test contains a lot more machinery) But see further
>below for more issues here.

If anything, move it into test. Please let's not pile up more code under
src.

> - Which of the tests in /test/xml/bugtests et. al. are obsoleted by
>the layoutengine test framework?

Never checked. Bugtests may still have the use. At one point the
layoutengine/testcases directory will become too crowded and we might
want to separate feature tests from bug/regression tests.

> - Which other test files are now obsolete? GenericFOPTestCase and
>related sources seem to be candidates.

Yep. As I always said, testing on hashes of the output files requires
very careful work and is unstable and therefore unattractive.

> - Should Keiron's test framework (TestConverter/RunTest) be considered
>obsolete? Should tests which are not layoutengine tests be converted
>to JUnit tests? (Well, probably...)

I don't use TestConverter/RunTest. Too unstable for my taste. I consider
this obsolete. Furthermore, I'm working on a visual testing framework so
the renderers, can be tested, too. I think that is going to be more
versatile.

As much as possible should be JUnit tests, but not necessarily
everything. The visual testing framework will at the beginning be not
JUnit test, but only a batch converter which creates a simple (local)
website where you can compare output. It's going to be closer to
TestConvert/RunTest but we may eventually automate this stuff in a
Solaris zone similar to what Forrest, Gump etc. have.

> - How should an acceptable structure of the /test/resources subtree
>look like?

Good question. Ideas welcome. I created the images directory to place
stuff I use in the layoutengine tests.

> - Should we really test for invalid XML (see /test/errors)?

In one way or another we should test how FOP reacts to invalid input.
But it would need to be integrated into the JUnit tests so these tests
are run by some people at least. I haven't done anything with these
until now.

> - How should Junit tests for proper handling of invalid input should
>look like?

- Checking if the right exceptions are thrown.
- Checking if loc