https://issues.apache.org/bugzilla/show_bug.cgi?id=38507
Glenn Adams gl...@skynav.com changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment
Manuel Mall wrote:
1. The suppress-at-line-break property can be applied to all characters.
I would take the position at the moment that explicit specification of
the suppress-at-line-break property is not supported and we worry about
it at a later stage. I would certainly argue against just
On Monday 06 February 2006 18:44, Luca Furini wrote:
Manuel Mall wrote:
snip/
1. Justified text: pen INF + elastic glue
2. All other justification modes: either just a box of the width of
the space or pen INF + fixed width glue.
I think in both cases (justified / unjustified text) we
Manuel Mall wrote:
IMO nbsp (and any other Unicode special spaces) are outside the scope of
XSL-FO whitespace handling. XSL-FO refers to whitespace as defined in
XML. In XML only x#20, x#9, x#a, and x#d are considered whitespace.
Therefore nbsp does not need to be considered when looking at
On Monday 06 February 2006 22:35, Luca Furini wrote:
Manuel Mall wrote:
IMO nbsp (and any other Unicode special spaces) are outside the
scope of XSL-FO whitespace handling. XSL-FO refers to whitespace as
defined in XML. In XML only x#20, x#9, x#a, and x#d are considered
whitespace.
Manuel Mall wrote:
This solves the first supposed problem (interaction between nbsp and
pretty-printing spaces), but the second one is still open: what
happens if we have
someContentnbspspaceotherContent ?
*IF* (and I'm not at all sure about this) there can be a break , then
both spaces
On Feb 6, 2006, at 08:17, Manuel Mall wrote:
[ME:]
snip/
A preserved carriage return can be treated the same way as a
linefeed, under the very exceptional condition that it survives
white-
space handling:
* white-space-treatment=ignore-if-*
* the CR does not follow/precede a linefeed
On Feb 6, 2006, at 17:04, Luca Furini wrote:
Hi Manuel / Luca,
Manuel Mall wrote:
IMO yes there can be a break and no only the space needs to be
removed. Again the argument is that nbsp is not whitespace as per
XSL-FO definition and need not to be removed.
What makes you think that
On Feb 6, 2006, at 19:40, Andreas L Delmelle wrote:
Currently, the fact that it is a fo:character is not known when
running this through the algorithm. The CharIterators deal with the
characters.
Say... I was just wondering: why does the TextLayoutManager create
its own copy of the
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38507.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
On Feb 5, 2006, at 14:13, [EMAIL PROTECTED] wrote:
Hi Manuel,
--- Additional Comments From [EMAIL PROTECTED] 2006-02-05
14:13 ---
Jeremias, no that is not it IMO. Knuth doesn't break between
elements as such.
The glue or penalty element itself is the break opportunity and is
On Feb 5, 2006, at 14:13, [EMAIL PROTECTED] wrote:
Hi Manuel,
--- Additional Comments From [EMAIL PROTECTED] 2006-02-05
14:13 ---
snip/
A preserved carriage return can be treated the same way as a
linefeed, under the very exceptional condition that it survives white-
space
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38507.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38507.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38507.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
15 matches
Mail list logo
