[EMAIL PROTECTED] (ewitness - Ben Fowler) wrote: [snip] Well, this is drifting off topic for this list... but see the very end of this message. And some remarks anyway:
In the example > >The correct way to express > >procedure foo(); > > begin ... > >would be something like: > ><fo:block> > > <fo:block>foo();</fo:block> > > <fo:block margin-left="1em"> > > <fo:block>begin</fo:block> ... I meant "correct way to express the presentational aspects with XSLFO". There was no intention to feed this to a Pascal compiler. The use case was "I have some <Foo> source code and want to include it in my printed manual" If you want to have your specific (XML) data presented on a 2D area like paper sheets or a computer monitor screen, you probably have to 1. Assign some presentational semantic to your specific data elements like <para> or <proc> or <record> or <author> 2. Apply some commonly used concepts like kerning, space justification, word wrapping and such stuff XSL, both T and FO, attempts to make this possible, and XSLFO is the second part: a vocabulary for describing the presentation of stuff on a 2D area, perhaps splitted into a page stream (disregard audible properties, whose inclusion is just plain silly). Depending on your point of view, you can see either of the two steps or both together as the equivalent of typesetting. > Which is why I say [RETURN] for end of paragraph - </p>, and > [SHIFT][RETURN] for end of line - <br />; to make the easy way > the right way. XSLFO does not assign semantics to FOs beyond what's necessary to get them layed out. It does not have a concept of "paragraph", and the concept of "line" is not necessarily the same as what for example software manual writers or java compilers use. Note that there is no fo:line and no fo:para, just a fo:block, which is *not* a paragraph. Further note that HTML <p> has paragraph semantics, this means some space before and after by default. Also, in early HTML there was no possibility at all to restrict the, well, lets call it page width. Therefore you could not simply write <p>some line <p>next line in order to get a managable line length, it would result in a line spacing making it unreadable. In FO, you could write <fo:block space-before="3pt"> <fo:block space-before="0">some line</fo:block> <fo:block space-before="0">next line</fo:block> </fo:block> if you want to have your content formatted this way. I can't see a need for a <br> equivalent in FO. Another note: in TeX, semantic markup and presentational aspects are mixed in a sometimes annoying way. LaTeX tried to go as pure semantic as resonable, but, unfortunately, you have sometimes a semantic too special to explicitely define an abstraction for it and therefore describe it by its presentation instead. FO, on the contrary, is as pure presentation as possible, taking only really widely used concepts into account and leave the rest to the first step mentioned at the beginning (no formatting of mathematical formulas in FO, no theorem numbering ...) Conclusion: If you want to write documents, use DocBook, not XSLFO. DocBook btw contains linebreak elements, probably for some reasons already mentioned, and apparently there are no difficulties to map them to FOs. In order to clean up the seemingly contradiction that FO also allows for interpretation of LF characters: If you have already properly marked up text for lines, you can transform it (probably easily) into FO blocks. If you pull in whitespace formatted data from a file or DB or something, you might want to have the FO processor respect the existing formatting rather than to analyze and properly transform the whole stuff. That's a quick hack to fill a gap. I already experienced some times that the result is not as good as it should be and someone still has to wade through the data and convert it to properly marked up (or at least properly structured) data (usually leading to hot debates about "what *is* the structure behind the formatting?") Having said all that, FO still lacks stuff, but mostly related to the fact that pagination is a task of the FO processor and not known at the time FOs are generated, like: - elements to express conditional stuff on page breaks in other elements, like "continued on next page" or "continued from previous page" - conditions like "if this element does not fit the current page, start it on a new page" (not decisively solved by keep-together) or "if NN percent of this element do not fit onto the current page, start a new page" (some generalization of widows/orphans) Can one of the FOP developers comment on how easy/hard such stuff would be to implement as extension elements? Regards J.Pietschmann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
