>[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]
