xsl-list
[Top] [All Lists]

RE: XSL:FO - How to wrap non-word strings in table cells?

2003-10-06 02:18:41
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