[Tests] automated Tests for FOP's XSL-Standard compilance

[Matthias Wessendorf <mw...@pironet-ndh.com>]

Hi there,

are there any (unit) tests regarding FOP's standard compilance?

I'd like to document the FOP behaivor when it becomes an input file that contains a <fo:table/> with NO table-layout="fixed".
So in my case (not a test case (yet)) I saw a PDF file on my disk (so "out.size() > 0" is true ;)), but that guy is empty, since
FOP isn't able to process that <fo:table/>. Such a test case would be fine to create automated test on my development cases.

I am using/evaluating (better testing?) some converters (html2fo and css2xslfo) to produce FO files from (x)html files. And that pain I would like to automate ;)

Any ideas? Or perhaps existing test cases ? ;)

Thanks and regards,
Matthias

Re: [Tests] automated Tests for FOP's XSL-Standard compilance

[Jeremias Maerki <de...@greenmail.ch>]

On 06.06.2005 13:29:30 Matthias Wessendorf wrote:
> Hi,
> 
> see comments inline
> 
> > We've started a systematic test suite for FOP 1.0dev development. It's
> > located here:
> > 
> > http://cvs.apache.org/viewcvs.cgi/xml-fop/test/layoutengine/
> > 
> > Some initial documentation is here:
> > http://wiki.apache.org/xmlgraphics-fop/HowToCreateLayoutEngineTests
> 
> thanks, I'll take a look at that pages.
> 
> > > I'd like to document the FOP behaivor when it becomes an 
> > input file that
> > > contains a <fo:table/> with NO table-layout="fixed".
> > > So in my case (not a test case (yet)) I saw a PDF file on 
> > my disk (so
> > > "out.size() > 0" is true ;)), but that guy is empty, since
> > > FOP isn't able to process that <fo:table/>. Such a test 
> > case would be
> > > fine to create automated test on my development cases.
> > 
> > According to the spec an empty fo:table element is illegal. It has to
> > contain at least one fo:table-body element.
> 
> sure I more meant a (valid) table, which doesn't contain a table-layout attribute;
> 
> > frozen. But if there are things that FOP 0.20.5 and (!) FOP 
> > 1.0dev fail
> 
> is FOP 1.0dev able to process <fo:table> elements that do not contain
> table-layout="fixed" ?

The table-layout property is currently ignored. Furthermore, without
table-column elements the column setup is not really usable right now,
as the first column takes up 100% of the available width. In the end you
currently have the same problem as in 0.20.5.

> > I don't know if it helps you in this particular case but I've 
> > written a
> > general Java API for converting XML documents to graphical output
> > (XSL-FO, SVG, XHTML to PDF, PS, SVG or whatever). I haven't 
> > published it
> > since I renamed the whole beast (now JAXG, formerly JAFOP), 
> > but I expect
> > to do that this month. I already use it to do all my private test code
> > for FOP. I can send you a snapshot if you're interested. I've got
> > implementations for FOP 0.20.5, FOP 1.0dev, FOray, JFOR and 
> > Batik. Write
> 
> that sounds fine to me, will this be released under the umbrella of xmlgraphics project of the 
> ASF ?

I don't intend to. It would send the wrong signal. I've already renamed
the API to avoid "FOP" in the name, so I don't scare potential
commercial implementors away. It's probably going to end up on java.net.
But it's Apache v2 licensed, just like FOP. The intention is to have as
many implementations as possible to make it easier to switch between
different XSL-FO implementations without modifying too much in Java code.

> > once, use whatever implementation you would like, basically. 
> > Of course,
> > the conversion of HTML to XSL-FO is outside the scope of JAXG 
> > since it's
> > a process that happens before the actual conversion of the XML dialect
> > to the final graphical format. But maybe preprocessors like the above
> > two could be somehow integrated. I'd have to think about that 
> > a little,
> > though.
> 
> 
> 
> > > Any ideas? Or perhaps existing test cases ? ;)
> > 
> > In the end I think what you really need is support for auto 
> > table layout
> > which neither FOP 0.20.5 and FOP 1.0dev support, yet. When converting
> 
> ok... that would be a *killer* feature for me ;)

I know. It would be for many people. Still looking for volunteers.

> > HTML to PDF this automatically comes up. At some point someone has to
> > start implementing this feature and it's likely not going to 
> 
> do you know more details regarding the implementation of this feature?

Depends on what you want to know. I can surely give pointers to someone
who would like to try implementing it. But I haven't invested too much
thought into how this would be done.

> Thanks for your informations,
> Matthias
> 
> > be me since
> > I'm into strict XSL-FO business document where this was never 
> > an issue,
> > yet.
> > 
> > I hope the above helps.
> > 
> > Jeremias Maerki
> > 
> > 



Jeremias Maerki

Re: [Tests] automated Tests for FOP's XSL-Standard compilance

[Jeremias Maerki <de...@greenmail.ch>]

Hi Matthias

On 06.06.2005 10:41:37 Matthias Wessendorf wrote:
> Hi there,
> 
> are there any (unit) tests regarding FOP's standard compilance?

We've started a systematic test suite for FOP 1.0dev development. It's
located here:

http://cvs.apache.org/viewcvs.cgi/xml-fop/test/layoutengine/

Some initial documentation is here:
http://wiki.apache.org/xmlgraphics-fop/HowToCreateLayoutEngineTests

Please note that the checks are specific to the development code for FOP
(CVS HEAD) and do not apply to FOP 0.20.5. However, I frequently
cross-check the results with different FO implementations if only to see
that they fail in many tests that FOP already handles fine. *evil grin*

> I'd like to document the FOP behaivor when it becomes an input file that
> contains a <fo:table/> with NO table-layout="fixed".
> So in my case (not a test case (yet)) I saw a PDF file on my disk (so
> "out.size() > 0" is true ;)), but that guy is empty, since
> FOP isn't able to process that <fo:table/>. Such a test case would be
> fine to create automated test on my development cases.

According to the spec an empty fo:table element is illegal. It has to
contain at least one fo:table-body element.

If you like to help extend the test suite, that would be absolutely great!
Just be aware that it doesn't make sense to document what FOP 0.20.5
doesn't do well since that is already documented quite well in the
compliance document on FOP's website and the maintenance branch has been
frozen. But if there are things that FOP 0.20.5 and (!) FOP 1.0dev fail
to do then it would be good to have test cases if just as a reminder for
things that still need to be done.

Glen Mazza mentioned a couple of months ago, that the W3C working group
for XSL also seeks to create a test suite. Maybe they already have
something. I don't know. The old test suite at least is quite outdated
and wasn't updated to the Recommendation level.

> I am using/evaluating (better testing?) some converters (html2fo and
> css2xslfo) to produce FO files from (x)html files. And that pain I
> would like to automate ;)

I don't know if it helps you in this particular case but I've written a
general Java API for converting XML documents to graphical output
(XSL-FO, SVG, XHTML to PDF, PS, SVG or whatever). I haven't published it
since I renamed the whole beast (now JAXG, formerly JAFOP), but I expect
to do that this month. I already use it to do all my private test code
for FOP. I can send you a snapshot if you're interested. I've got
implementations for FOP 0.20.5, FOP 1.0dev, FOray, JFOR and Batik. Write
once, use whatever implementation you would like, basically. Of course,
the conversion of HTML to XSL-FO is outside the scope of JAXG since it's
a process that happens before the actual conversion of the XML dialect
to the final graphical format. But maybe preprocessors like the above
two could be somehow integrated. I'd have to think about that a little,
though.

> Any ideas? Or perhaps existing test cases ? ;)

In the end I think what you really need is support for auto table layout
which neither FOP 0.20.5 and FOP 1.0dev support, yet. When converting
HTML to PDF this automatically comes up. At some point someone has to
start implementing this feature and it's likely not going to be me since
I'm into strict XSL-FO business document where this was never an issue,
yet.

I hope the above helps.

Jeremias Maerki