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.
Do you think the user should have control over that overflow action?
That's all I'm asking.
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.
My response here is that it could be done manually / programmatically,
but since its so common, why not provide that as part of the
formatter functionality.
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.
Again a 'manual' solution? I'm in favour of 'adjusting the rules'
via the formatter. I.e. requesting a break. The 'how' I'm more
than happy to leave to the WG, as Wendell suggests.
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.
Globally, or 'just in this block'?
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.
Which is what I'm asking.
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?"
Yes there is, but in extremis that could be taken to hand craft
all output?
I've watched this particular request come up time and time again,
and thought it worth discussing for a standards based solution.
regards DaveP.
-
DISCLAIMER:
NOTICE: The information contained in this email and any attachments is
confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of the
content of it or of any attachment; you are requested to notify the
sender immediately of your receipt of the email and then to delete it
and any attachments from your system.
RNIB endeavours to ensure that emails and any attachments generated by
its staff are free from viruses or other contaminants. However, it
cannot accept any responsibility for any such which are transmitted.
We therefore recommend you scan all attachments.
Please note that the statements and views expressed in this email and
any attachments are those of the author and do not necessarily represent
those of RNIB.
RNIB Registered Charity Number: 226227
Website: http://www.rnib.org.uk
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list