Re: White space handling Wiki page

On Oct 31, 2005, at 22:18, Andreas L Delmelle wrote: On Oct 27, 2005, at 06:29, Manuel Mall wrote: Actually something like: word1word2word3 currently causes an exception! The problem can be solved by a slight modification to OneCharIterator: * add a constructor with Character parameter (and

Re: White space handling Wiki page

On Tue, 1 Nov 2005 04:25 pm, Andreas L Delmelle wrote: > On Oct 31, 2005, at 22:18, Andreas L Delmelle wrote: > > On Oct 27, 2005, at 06:29, Manuel Mall wrote: > >> Actually something like: > >> word1 >> character=" "/> >> " "/>word2word3 >> character=" "/> > >> currently causes an exception! > > >

Re: Unicode compliant Line Breaking

On Tue, 1 Nov 2005 01:33 am, [EMAIL PROTECTED] wrote: > Hi all, > > Just an FYI, Batik also currently has an implementation of > the Unicode TR14 word breaking alg. > (org.apache.batik.gvt.flow.TextLineBreak). > > As far as performance is concerned it should be fairly fast > as it i

Re: Unicode compliant Line Breaking

Hi Manuel, Manuel Mall <[EMAIL PROTECTED]> wrote on 11/01/2005 04:24:05 AM: > On Tue, 1 Nov 2005 01:33 am, [EMAIL PROTECTED] wrote: > > Just an FYI, Batik also currently has an implementation of > > the Unicode TR14 word breaking alg. > > (org.apache.batik.gvt.flow.TextLineBreak). > Thom

DO NOT REPLY [Bug 37318] New: - fop.bat: NoClassDefFoundError: org/apache/fop/cli/Main

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 37318] - fop.bat: NoClassDefFoundError: org/apache/fop/cli/Main

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

zero width space

Currently if one puts a zero-width-space (U+200B) into an XSL-FO file (or specifies linefeed-treatment="treat-as-zero-width-space") it is rendered as a "missing character" in PDF. Is that correct, i.e. does this character have to exist in the font used or should the formatter or renderer simply

linefeed-treatment="preserve"

Assuming everything else is at default settings what is the expected outcome for: line 1 Is it a) line 1 or b) line 1 or c) line 1 or d) line 1 It seems we are doing c) at the moment which makes the above fo identical to: line 1 Is that correct? Manuel

Leading/trailing space removal in LineLM

This is probably a question for Luca or Simon. In LineLM we have this code: // ignore KnuthGlue and KnuthPenalty objects // at the beginning of the line seqIterator = seq.listIterator(iStartElement); tempElement = (KnuthElement) seqIt

Re: Unicode compliant Line Breaking

On Tue, 1 Nov 2005 07:27 pm, [EMAIL PROTECTED] wrote: > Hi Manuel, > > Manuel Mall <[EMAIL PROTECTED]> wrote on 11/01/2005 04:24:05 AM: > > On Tue, 1 Nov 2005 01:33 am, [EMAIL PROTECTED] wrote: >> Had a look at the Batik code: Same algorithm as Joerg wrote (not > > surprising as UAX#14 actually c

DO NOT REPLY [Bug 37318] - fop.bat: NoClassDefFoundError: org/apache/fop/cli/Main

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 37318] - fop.bat: NoClassDefFoundError: org/apache/fop/cli/Main

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: linefeed-treatment="preserve"

Manuel Mall wrote: Assuming everything else is at default settings what is the expected outcome for: line 1 Is it a) line 1 or b) line 1 or c) line 1 or d) line 1 It seems we are doing c) at the moment which makes the above fo identical to: line 1 Is that correct? No, it should

Re: zero width space

Manuel Mall wrote: Currently if one puts a zero-width-space (U+200B) into an XSL-FO file (or specifies linefeed-treatment="treat-as-zero-width-space") it is rendered as a "missing character" in PDF. Is that correct, i.e. does this character have to exist in the font used or should the formatte

Re: zero width space

On Nov 1, 2005, at 15:52, Manuel Mall wrote: Currently if one puts a zero-width-space (U+200B) into an XSL-FO file (or specifies linefeed-treatment="treat-as-zero-width-space") it is rendered as a "missing character" in PDF. Is that correct, i.e. does this character have to exist in the font use

Re: White space handling Wiki page

On Nov 1, 2005, at 10:04, Manuel Mall wrote: I am sure it is doable - but is it worth it at this stage? Possibly after a better understanding of the white-space handling issues that whole current system needs revision? One problem with the current char iterator is that it iterates over inline b

Re: linefeed-treatment="preserve"

On Nov 1, 2005, at 16:03, Manuel Mall wrote: Assuming everything else is at default settings what is the expected outcome for: line 1 Is it a) line 1 This one, IMO. It seems we are doing c) at the moment which makes the above fo identical to: line 1 Is that correct? Nope. Should be

Re: linefeed-treatment="preserve"

On Tue, Nov 01, 2005 at 06:54:08PM +0100, Andreas L Delmelle wrote: > On Nov 1, 2005, at 16:03, Manuel Mall wrote: > > >Assuming everything else is at default settings what is the expected > >outcome for: > > > >line 1 > > > > > >Is it a) > > > >line 1 > > > > This one, IMO. I agree, a) Simon

Re: Leading/trailing space removal in LineLM

On Tue, Nov 01, 2005 at 11:40:42PM +0800, Manuel Mall wrote: > This is probably a question for Luca or Simon. > > In LineLM we have this code: > // ignore KnuthGlue and KnuthPenalty objects > // at the beginning of the line > seqIterator = seq.listIt

Re: Unicode compliant Line Breaking

On Mon, Oct 31, 2005 at 03:25:12PM +0800, Manuel Mall wrote: > In a previous post Joerg pointed to the Unicode Standard Annex #14 on > Line Breaking (http://www.unicode.org/reports/tr14/) and his initial > implementation: http://people.apache.org/~pietsch/linebreak.tar.gz. > > I had since a clos

Re: Unicode compliant Line Breaking

Simon Pepping wrote: Is our current hyphenation method a subset of Unicode's method? Umm. What's the relation between hyphenation and TR14 (except for handling soft hyphens)? I guess you confuse finding line breaks in general and line breaking due to hyphenation. I seem to recall that the hyp

Re: linefeed-treatment="preserve"

On Wed, 2 Nov 2005 05:14 am, Simon Pepping wrote: > On Tue, Nov 01, 2005 at 06:54:08PM +0100, Andreas L Delmelle wrote: > > On Nov 1, 2005, at 16:03, Manuel Mall wrote: > > >Assuming everything else is at default settings what is the > > > expected outcome for: > > > > > >line 1 > > > > > > > > >Is

Re: Leading/trailing space removal in LineLM

On Wed, 2 Nov 2005 04:18 am, Simon Pepping wrote: > On Tue, Nov 01, 2005 at 11:40:42PM +0800, Manuel Mall wrote: > > This is probably a question for Luca or Simon. > > > Glue and penalty items are removed at the start of a line. This is > part of the Knuth algorithm. It does not touch the matter o

Re: zero width space

On Wed, 2 Nov 2005 01:03 am, Chris Bowditch wrote: > Manuel Mall wrote: > > Currently if one puts a zero-width-space (U+200B) into an XSL-FO > > file (or specifies linefeed-treatment="treat-as-zero-width-space") > > it is rendered as a "missing character" in PDF. Is that correct, > > i.e. does this