>[EMAIL PROTECTED] (ewitness - Ben Fowler) wrote: >[snip] > > [snip ] >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"
O.K. I was a bit harsh there, but I was trying to make the point that some blocks in a ideal presentational system, such as comments would flow, but others such as code statements and expressions would not. >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). (divided, or divided up rather than "splitted") My gripe is that your (2) above should include kerning, ligatures, justification, bidi, word wrapping, hyphenation, forced line break, rubber space, widow/orphan control, keeps, insert space and such stuff. >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. (laid out) And from my POV, that is a pity. I do think of a block as a paragraph, and my enter key or ETAG ending a paragraph and inserting the specified vertical space. 'lines' are largely the result of layout engine working with line length against word wrap, hyphenation and forced line break. I don't dispute the practicality of what you describe, I merely question the benfits of it. >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. 'Page width' is set by the user, he or she can set the width of the browser to what suits that person, it is little to do with HTML. If I can use HTML as an example, (which is not in general a good idea), then this fragment <H1>MacHTTP<BR> An early web server</H1> really needs the <BR>, as <H1>MacHTTP</H1> <H1>An early web server</H1> is not the same in structure or presentation, and there is no other way (outside of CSS) of getting the required presentation. Obviously FO does not have this problem. Your example is interesting & might work for me. The outer blocks represent paragraphs and the inner ones (typically only one) lines. I will try this before posting again. >Another note: in TeX, semantic markup and presentational aspects >are mixed in a sometimes annoying way. True >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. Again I will check that. I was working from a starting point of generating/editing FO by hand. Certinly, I would recommend DocBook for serious authoring. FO is so like WordPerfect codes, that it seems a shame to make it gratuitously non-editable >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?") Which is also (I think that this is what you were saying in your para (1) right at the top), part of the skills of a typesetter. An art which is most often best employed to keep the typography in the background so that the message is all that the reader takes away. I suspect that when one pulls in files or other material, then one must obey rules grandfathered from SGML. In such cases, even if getting perfect results is awkward, it is a standards compliant process, obeys the principle of least surprise (in the top three of the useability commandments) and will be future proof. >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" Oh dear, at some point I will need that... >- 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? I can't speak for the FOP team (I expect to add the first at least of your requests to my FOP tree sometime), but I suspect that the problem is not so much the ease or otherwise, but the standards compliance thereof. For example someone here wants watermarks, now watermarking (or layers in general) is not difficult to implement - it is only a few lines of java - but without a standard it is of very limited value. Ben. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]