Re: [xsl] XSL:FO - How to wrap non-word strings in table cells?

Subject: Re: [xsl] XSL:FO - How to wrap non-word strings in table cells?
From: "W. Eliot Kimber" <eliot@xxxxxxxxxx>
Date: Fri, 03 Oct 2003 10:38:50 -0500
Wendell Piez wrote:

At 03:25 AM 10/2/2003, DaveP wrote:

Since it is requested so often, perhaps asking the WG to consider
a solution is appropriate?

The most often requested place is a table cell,
so perhaps something like a hint to the processor,
break-at="20" meaning if needed, presume a soft-hyphen at character position
20 within any word?

Any other suggestions anyone?

Ken's solution (process to insert a zero-width space after certain characters where a line break is tolerated, such as a slash) is a good one; it'd be nice to tell the FO processor what these "break-after" characters are, and then not have to worry about the string pre-processing.

I don't think that Dave's solution is required. I think it should be sufficient for FO implementations to provide a way to indicate that the overflow behavior in this context should be to break the line. The FO spec does not limit how FO processors can react to overflow conditions.

Also, I think there have been two similar but different requirements discussed:

1. Allowing an arbitrary long sequence of non-blank characters to break anywhere

2. Controlling breaks at specific characters, such as following (but not before) "/" in URLs.

The first case can be solved by blindly inserting a zero-width space or soft hyhen between each pair of characters. This is easy to do as an XML input filter or even in XSLT using an extension function or recursive template.

The second case requires either adjusting the line breaking rules (for example, the behavior above for solidus is the opposite of what the Unicode line breaking properties state) or putting a zero-width joiner before the solidus and a zero-width no-breaking space or soft hyphen after it.

The first case could also be satisfied with a simple overflow behavior ("break line on overflow") but the second could not.

Note that the latest release of XSL Formatter version 2 includes some extensions for modifying the line breaking rules in the case where the Unicode rules do not suit.

While Dave has every right to submit requirements to the XSL-FO subgroup, let me remind everyone that every submission to the editors list forces us (the subgroup members) to formally evaluate the comment and respond to it. As for most standardization activities, we have very limited resources. So I would urge people to consider their requests very carefully before posting to the XSL-FO editors list. I think it's quite useful and appropriate to discuss new requirements here (or on the exslfo list ( before submitting them formally to the working group.

I will also tell you that one of our first questions for any new requirement is "is there any way this requirement can be satisfied using existing methods in common use?" Not only do we have to husband the resources of the subgroup, but we have to mindful of what FO implementors will be willing and able to do.


W. Eliot Kimber
ISOGEN International, LLC

XSL-List info and archive:

Current Thread