This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: [XSL-FO] column of small width
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] [XSL-FO] column of small width
- From: Arved Sandstrom <Arved_37 at chebucto dot ns dot ca>
- Date: Fri, 22 Dec 2000 06:45:13 -0400
- Reply-To: xsl-list at lists dot mulberrytech dot com
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