headers
bugzilla | 1 Nov 2005 06:49
Picon
Favicon

DO NOT REPLY [Bug 36977] - [PATCH]TextLayoutManager CJK line break

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=36977>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36977

ravenix2 <at> yahoo.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #16651|0                           |1
        is obsolete|                            |
  Attachment #16694|0                           |1
        is obsolete|                            |

------- Additional Comments From ravenix2 <at> yahoo.com  2005-11-01 06:49 -------
Created an attachment (id=16846)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16846&action=view)
line break patch

This is a line break patch without typesetting fine tuning.
It still base on BreakIterator and satisfy testcases.
Sorry for my previous buggy patch.
Befor the new Unicode Line Breaking algorithm available,
the patch make it possible to test FOP with CJK characters.

--

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andreas L Delmelle | 1 Nov 2005 09:25
Picon

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:
>> <fo:block background-color="yellow">word1<fo:character
>> character="&#10;"/><fo:character character=
>> " "/>word2<fo:character character=" "/>word3<fo:character
>> character="&#10;"/></fo:block>
>> currently causes an exception!
>>
>
>
> The problem can be solved by a slight modification to OneCharIterator:
> * add a constructor with Character parameter (and member)
> * add a remove() implementation which makes Character's parent  
> remove it from its list of child nodes
>
> Tested locally (very quickly), and seems to work nicely. If I get  
> the chance to commit it in the next few days, I'll do so myself,  
> but if you want to have a go, it's a pretty easy fix (adds up to  
> about 10-15 LOC incl. javadocs :-))

Oops, been too quick. From an UnsupportedOperationException to a  
ConcurrentModificationException...
The trick seems to be to introduce a small boolean 'discard' switch  
to the Character object, flip this upon calling OCIter.remove(), and  
have the Block/Inline later remove any of its characters marked as  
discardable, but do this (of course) only after the  
RecursiveCharIterator has finished --to avoid the childNodes list  
from being altered while it's being iterated over...
(Continue reading)

Permalink | Reply | 2 comments |
headers
Manuel Mall | 1 Nov 2005 10:04
Picon

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:
> >> <fo:block background-color="yellow">word1<fo:character
> >> character="&#10;"/><fo:character character=
> >> " "/>word2<fo:character character=" "/>word3<fo:character
> >> character="&#10;"/></fo:block>
> >> currently causes an exception!
> >
> > The problem can be solved by a slight modification to
> > OneCharIterator: * add a constructor with Character parameter (and
> > member)
> > * add a remove() implementation which makes Character's parent
> > remove it from its list of child nodes
> >
> > Tested locally (very quickly), and seems to work nicely. If I get
> > the chance to commit it in the next few days, I'll do so myself,
> > but if you want to have a go, it's a pretty easy fix (adds up to
> > about 10-15 LOC incl. javadocs :-))
>
> Oops, been too quick. From an UnsupportedOperationException to a
> ConcurrentModificationException...
> The trick seems to be to introduce a small boolean 'discard' switch
> to the Character object, flip this upon calling OCIter.remove(), and
> have the Block/Inline later remove any of its characters marked as
> discardable, but do this (of course) only after the
> RecursiveCharIterator has finished --to avoid the childNodes list
> from being altered while it's being iterated over...
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Manuel Mall | 1 Nov 2005 10:24
Picon

Re: Unicode compliant Line Breaking

On Tue, 1 Nov 2005 01:33 am, thomas.deweese <at> kodak.com 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 is mostly just table based.
>
Thomas, thanks for the pointer (Note to myself - need to become more 
aware of what's in the Batik code base. Feeble excuse - Joerg didn't 
seem to know either).
Had a look at the Batik code: Same algorithm as Joerg wrote (not 
surprising as UAX#14 actually contains real C code) very similar data 
structures internally. Data structures are hard coded and not generated 
from the Unicode text files. The API is different, especially it relies 
on Batik specific types being passed across not just plain Strings (but 
this could probably be handled by a wrapper).

This probably strengthens the argument of making all of this part of 
XMLGraphics Common....grumble...grumble...

My main reason for hesitation with the XMLGraphics Common approach is 
simple man power. We need to setup the infrastructure (subversion, 
mailing lists, web site, etc.). We need to maintain this. We would 
basically would publish APIs currently internal to Batik and FOP with 
all the resultant support headaches. For example, I would not like to 
see my time diluted in the moment by having to discuss API needs 
outside of FOP/Batik. Actually I am reluctant to even dive into the
(Continue reading)

Permalink | Reply | 2 comments |
headers
thomas.deweese | 1 Nov 2005 12:27
Picon
Favicon

Re: Unicode compliant Line Breaking

Hi Manuel,

Manuel Mall <mm <at> arcus.com.au> wrote on 11/01/2005 04:24:05 AM:

> On Tue, 1 Nov 2005 01:33 am, thomas.deweese <at> kodak.com wrote:
> >         Just an FYI, Batik also currently has an implementation of
> > the Unicode TR14 word breaking alg.
> > (org.apache.batik.gvt.flow.TextLineBreak).

> Thomas, thanks for the pointer (Note to myself - need to become more 
> aware of what's in the Batik code base. Feeble excuse - Joerg didn't 
> seem to know either).

    It's a fairly recent addition, to support proposals for flowing 
text in SVG 1.2.

> Had a look at the Batik code: Same algorithm as Joerg wrote (not 
> surprising as UAX#14 actually contains real C code) very similar data 
> structures internally. Data structures are hard coded and not generated 
> from the Unicode text files. 

   I would not think it would be worth the while to parse the Unicode
files on startup every time (they aren't small).  Passing in the table
mapping chars to types might be a useful extension (but in honesty
I doubt .5% of users would ever provide their own, unless the code
only included say Western Language by default).

> The API is different, especially it relies 
> on Batik specific types being passed across not just plain Strings (but 
> this could probably be handled by a wrapper).
(Continue reading)

Permalink | Reply | 1 comment |
headers
bugzilla | 1 Nov 2005 15:32
Picon
Favicon

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
<http://issues.apache.org/bugzilla/show_bug.cgi?id=37318>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37318

           Summary: fop.bat: NoClassDefFoundError: org/apache/fop/cli/Main
           Product: Fop
           Version: 1.0dev
          Platform: PC
        OS/Version: Windows 2000
            Status: NEW
          Severity: blocker
          Priority: P2
         Component: general
        AssignedTo: fop-dev <at> xmlgraphics.apache.org
        ReportedBy: mhilpert <at> gmx.de

I downloaded the latest trunk (r330052) and tried to beginn with the fop.bat 
batch file. After I removed the special characters in it (probably UNIX special 
line breaks), I got it started and it just prints:

Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/fop/cli/Ma
in

--

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla | 1 Nov 2005 15:33
Picon
Favicon

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
<http://issues.apache.org/bugzilla/show_bug.cgi?id=37318>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37318

------- Additional Comments From manuel <at> apache.org  2005-11-01 15:33 -------
Did you build fop using ant before trying to run it?

--

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
Manuel Mall | 1 Nov 2005 15:52
Picon

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 remove this character? It is the second approach 
that both AntennaHouse and RenderX appear to have chosen.

Manuel
Permalink | Reply | 14 comments |
headers
Manuel Mall | 1 Nov 2005 16:03
Picon

linefeed-treatment="preserve"

Assuming everything else is at default settings what is the expected 
outcome for:
<fo:block linefeed-treatment="preserve">
line 1
</fo:block>

Is it a)
<empty line>
line 1
<empty line>

or b)
line 1

or c)
<empty line>
line 1

or d)
line 1
<empty line>

It seems we are doing c) at the moment which makes the above fo 
identical to:
<fo:block linefeed-treatment="preserve">
line 1</fo:block>

Is that correct?

Manuel
(Continue reading)

Permalink | Reply | 5 comments |
headers
Manuel Mall | 1 Nov 2005 16:40
Picon

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) seqIterator.next();
                while (!tempElement.isBox() && seqIterator.hasNext()) {
                    tempElement = (KnuthElement) seqIterator.next();
                    iStartElement++;
                }
What is the background to this? This seems to interfere with certain 
combinations of white-space-collapse="false" and 
white-space-treatment="preserve/ignore-if-before-linefeed". I think 
there is similar code to remove trailing stuff with similar 
interference.

Manuel
Permalink | Reply | 8 comments |

Gmane