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 (exslfo.sourceforge.net)) 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.
Cheers,
Eliot
--
W. Eliot Kimber
ISOGEN International, LLC
eliot@xxxxxxxxxx
www.isogen.com
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list