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

[David.Pawson@xxxxxxxxxxx]

> > 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