On Fri, 4 Nov 2005 01:27 pm, Peter S. Housel wrote:
> On Fri, 2005-11-04 at 11:55 +0800, Manuel Mall wrote:
> > On Fri, 4 Nov 2005 04:46 am, J.Pietschmann wrote:
> > > Manuel Mall wrote:
> > > > With respect to U+200B it says in
> > >
> > > [snip]
> > >
> > > > It therefore surprises me that you im
On Fri, 2005-11-04 at 11:55 +0800, Manuel Mall wrote:
> On Fri, 4 Nov 2005 04:46 am, J.Pietschmann wrote:
> > Manuel Mall wrote:
> > > With respect to U+200B it says in
> >
> > [snip]
> >
> > > It therefore surprises me that you imply U+200B may expand in
> > > justification.
> >
> > The Unicode 3.
On Fri, 4 Nov 2005 01:11 am, Andreas L Delmelle wrote:
> On Nov 3, 2005, at 10:41, Manuel Mall wrote:
> >
> > The only limitation I am aware off at the moment is that the
> > "suppress-at-line-break" property is not supported. This is because
> > the
> > char iterator used does only return charact
On Fri, 4 Nov 2005 06:22 am, Andreas L Delmelle wrote:
> On Nov 3, 2005, at 08:53, Manuel Mall wrote:
> > On Thu, 3 Nov 2005 06:03 am, J.Pietschmann wrote:
>
> > But I am not sure if this can be done in
> > all cases. Otherwise we may have to modify the UNICODE line
> > breaking algorithm to cater
On Fri, 4 Nov 2005 04:46 am, J.Pietschmann wrote:
> Manuel Mall wrote:
> > With respect to U+200B it says in
>
> [snip]
>
> > It therefore surprises me that you imply U+200B may expand in
> > justification.
>
> The Unicode 3.0 book explicitely mentions that ZWS may be expanded
> for justification,
On Nov 3, 2005, at 08:53, Manuel Mall wrote:
On Thu, 3 Nov 2005 06:03 am, J.Pietschmann wrote:
Computing line breaking opportunities and discarding whitespace at
the end (or beginning) of a line are different matters. If whitespace
has to be retained, trailing spaces after a non-space string m
Manuel Mall wrote:
With respect to U+200B it says in
[snip]
It therefore surprises me that you imply U+200B may expand in
justification.
The Unicode 3.0 book explicitely mentions that ZWS may be expanded
for justification, to my great surprise. The 2.0 book doesn't have
any remarks in this di
Manuel Mall wrote:
Hmm, to me it appears that UNICODE and XSL-FO have slightly different
models when it comes to white space in the context of line breaking
which is causing the discussion here.
I don't think so. The overlap between UAX14 and XSLFO is that both
mandate a line break for each LF
On Nov 3, 2005, at 10:41, Manuel Mall wrote:
The only limitation I am aware off at the moment is that the
"suppress-at-line-break" property is not supported. This is because
the
char iterator used does only return characters (in the pure Java
sense)
and not their related XSL-FO properties.
On Thu, 3 Nov 2005 05:56 pm, Manuel Mall wrote:
> On Wed, 2 Nov 2005 11:58 pm, Luca Furini wrote:
> > Manuel Mall wrote:
>
> > If we have two (or more) spaces, we could use the sequence:
> >
> > 1 glue w=endB&P
> > 2 penalty w=0
> > 3 glue w=(- endB&P - startB&P)
> > 4 glue w=spaceIPD1
> > 5
On Wed, 2 Nov 2005 11:58 pm, Luca Furini wrote:
> Manuel Mall wrote:
> > Luca wrote a longer response to this but my mail reader doesn't
> > like the character set (is that topical or what?).
>
> Sorry, it looks really horrible ... still don't know what went wrong,
> but I won't do it again! :-)
>
On Thu, 3 Nov 2005 04:08 am, Andreas L Delmelle wrote:
> Hi all,
> (Manuel, I guess this is mostly directed to you, as you may already
> have been browsing the same classes...)
>
> Just wandering a bit through the FOText source code (follow-up on
> Manuel's recent thread on whitespace handling), an
On Thu, 3 Nov 2005 05:57 am, J.Pietschmann wrote:
> Manuel Mall wrote:
> > That seems to be the consensus, that is consider ZWS for line
> > breaking but then discard and don't give it to the renderers.
>
> Renderers could deal with ZWS if the font would have a glyph for
> this character; unfortuna
13 matches
Mail list logo
