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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] XSL:TEMPLATES, Sachidanandam E.K | Thread | [xsl] Difficulty with an msxsl:scri, Tomas Olsson |
Re: [xsl] Remove <?xml version> lin, Jeni Tennison | Date | RE : Re: [xsl] [XSL-FO] column of s, Ext . ZXSPRCR2A015 |
Month |