Re: [xsl] [XSL-FO] column of small width

Subject: Re: [xsl] [XSL-FO] column of small width
From: Arved Sandstrom <Arved_37@xxxxxxxxxxxxxx>
Date: Fri, 22 Dec 2000 06:45:13 -0400
At 16:34, Thu, 21 Dec 2000, James Robertson spake:

At 14:33 21/12/2000, Arved Sandstrom wrote:
>>As you suggest, some stuff one cannot handle this way. I was testing out
>>columns in FOP some time back, and ran an example that contained URLs, just
>>as you cite as an example above. No way would this be readable when
>>compressed.
>>
>>At some point, obviously, the formatter has to refuse to handle the problem,
>>though, and leave it up to the user to correct the situation and rerun.

>What do programs such as Framemaker, Pagemaker, Quark, etc do in
>these situations?
>
>In my experience, they break lines preferentially:
>
>1. Ends of words.
>2. Specified hyphens or other breakable characters.
>3. Implied hyphenation points (as looked up in the dictionary)
>4. Wherever it is required, if the "word" is simply longer
>    than the space it has to fit in.
>
>I haven't seen a program "compress" text to make it fit
>(this sounds pretty scary).

My personal perspective on this and similar situations follows from my last 
comment.

With reference to your bullets, I think points 1-3 are reasonable things for 
a typesetting program to do. These are all rules. Special rules to handle 
URLs (see the Lout mailing list archives for typical discussion) are an 
example of point 3, actually. Point 4 is no rule at all - it's an expression 
of failure. If the situation of point 4 happens, I'd say _any_ possible 
approach, including unintelligent wraparound, _or_ compression, is an 
equally valid way of doing _something_, while allowing the formatter to 
continue. But in the latter case the formatter should absolutely signal that 
it encountered something that it could not reasonably cope with.

Any consideration of what an XSL-FO formatter is responsible for must 
recognize that XSL-FO is a vocabulary for capturing typographic decisions 
from an external source, usually (right now) a human stylesheet designer. 
90% of the typography, or more, happens outside of the XSL-FO processor. The 
_only_ level at which the formatter is doing any rudimentary typesetting of 
its own is within text blocks. Even there the line-breaking and 
word-breaking is informed by external, ultimately human, typesetting choices 
as embodied in rule sets like hyphenation dictionaries.

In the case where the human typographer using XSL-FO has specified a text 
block 12 picas in length, but supplied a word with a large font that is 
unbreakable by any reasonable rules, and is too large for the space, I'd say 
that the ONLY reasonable option is for the human to lengthen the allocated 
block, explicitly resize the text, or both. Any automatic algorithm-driven 
"fix" is wrong. I would call reliance on the latter behaviour, by any 
program, "scary" also.

FOP, for example, is not a typesetting program, generally. It ought not to 
be making typesetting decisions. Down the road I hope to see automated tools 
for preparing true XSL stylesheets (XSLT + XSL-FO), and depending on how 
much intelligence is built in, *these* will be typesetting programs, with FO 
output. Things like Quark and TeX fall much more into this area - comparing 
an FO processor to one of these is apples and oranges.

Anyhow, this is personal philosophy. :-) Definitely just my opinion.

Regards, Arved Sandstrom

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread