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

Reply via email to