- From: Anders Kühne <Anders.K@primebase.com>
- Date: Tue, 25 Sep 2001 18:25:21 +0200
- To: www-xsl-fo@w3.org
Hi everybody, I'm evaluating the usability of XSL-FO and the available processors (particularly FOP) for a publishing project. Of course I expected to run into problems because of FOP not implementing parts of the spec. This was not the case so far -- for all the limitations in FOP it was quite easy to find a workaround sufficient for what we need. What I not expected was finding a severe shortcoming (that might lead us to deciding that the whole FO thing is not suitable for our project) in the spec itself: We need a text flow in two columns inside a table cell. So I am wondering, why does the spec allow column-count only in fo:region-body (instead of in any block level element)? It's definitely not _that_ out of the world to just need it somewhere else. Of course that would rise the threshold for application implementors -- but probably not too much, on the other hand. For LaTeX, there has been a package providing that functionality since, IIRC, 1988 or so. And I am well aware that XSL-FO just does'nt aim at copy-fitting and stuff like columns with dynamic widths flowing 'round moving triangular objects or what -- but, heck, a simple rectangle with flowing text content in more than one column is not at all that weird! If I did not misunderstand something fundamentally, the problem is severe because there is no reasonable workaround. Only the typesetting engine knows where the column break will take place, and even if you could make it tell you the exact location in the text, it would be hairy (if possible at all) to dynamically insert a block border there in the XSLT stage. The only tricks I could think of so far I considered too dirty and instable to really use. If the document fits on one page, and you need only one two-column area, the positioning of which is static, then you can define that as fo:region-body and the whole rest of the page as fo:region-before or so and fiddle with the margins till it fits. Works, but certainly not in the spirit of the inventor. Or you could use the whole two-column content twice in a left block with bottom overflow and a right one with top overflow, both clipped. Grunt. I didn't even try that. So I'm stuck with producing my two-col stuff as an extra page and then reimporting that, which FOP can't do but PassiveTeX but that doesn't process the rest of the page at all which will make me end up with some kind of PostScript surgery. Why? Thanks in advance for any answers, Anders
Received on Tuesday, 25 September 2001 12:29:59 UTC