updated Batik libraries

[Glen Mazza]

Team,

Just updated the two libraries & source code on
maintenance and HEAD.  (Only took 45 minutes...not
bad!)

Just for reference, the process involves (for both
HEAD and maintenance):

1.) CVS download of the latest Batik, compilation of
it into a single jar (use batik's "ant all-jar"
command to get the .jar you need.).

2.) Replacing the old batik.jar in our fop\lib
directory with the new one created above.

3.) Fixing our code to conform to their changed API.

Then rebuild, test (embedding.fo in our examples is
good, because it uses SVG), and commit both the new
.jar and the changed FOP source code file(s).

Glen

Re: [GUMP@brutus]: xml-fop-maintenance/xml-fop-maintenance failed

[Glen Mazza]

I'll take care of it by this weekend, if not much
sooner.

Glen

--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:

> J.Pietschmann wrote:
> > I wonder why HEAD isn't affected?
> 
> Darn, HEAD got it too :-/
> 
> J.Pietschmann
> 

Re: [GUMP@brutus]: xml-fop-maintenance/xml-fop-maintenance failed

[J.Pietschmann]

J.Pietschmann wrote:
I wonder why HEAD isn't affected?
Darn, HEAD got it too :-/
J.Pietschmann

Re: [GUMP@brutus]: xml-fop-maintenance/xml-fop-maintenance failed

[J.Pietschmann]

Clay Leeds wrote:
The thing that caught my eye is that it indicates xml-fop-maintenance.  
I thought the maintenance branch (fop-0_20_2-maintain) was frozen (I  
haven't noticed anyone updating the code--I doubt it, but could it be  
my manual update of the design/layout.html page?

It's probably a Batik API change -- again --, probably because of
the recent jumbo Batik commit. Look here:
apache/fop/svg/SVGElement.java:198:  is not abstract and does not 
override  abstract method deselectAll() in 
org.apache.batik.dom.svg.SVGContext
[javac] public float getFontSize(){
GUMP was designed exactly for the purpose of detecting these
problems. Which doens't give much of a guidance how to handle
this specific instance. We could just ignore it, and/or remove
fop-maintenance from the nightly GUMP.
I wonder why HEAD isn't affected?
J.Pietschmann

[Bug 29124] - New line breaking algorithm

[Simon Pepping]

On Tue, Aug 03, 2004 at 12:41:52PM -, [EMAIL PROTECTED] wrote:
> --- Additional Comments From [EMAIL PROTECTED]  2004-08-03 12:41 ---
> 
> Hi all
> 
> At long last, I have finished the patch implementing Knuth's line breaking 
> algorithm; it took me more than I expected, mainly because of a long sequence 
> of hw and sw troubles ... Murphy's laws are not something to laugh at! :-)

That is great. Congratulations with the successful completion of this
work. I will look at it soon, but since I will have holidays, it will
take a bit longer. I am curious to see how you negotiated all the
descendant LMs. 

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Switch from AddLMVisitor to FObj.addLayoutManager()

[Simon Pepping]

On Tue, Aug 03, 2004 at 04:45:58AM -0700, Glen Mazza wrote:
> --- Chris Bowditch <[EMAIL PROTECTED]> wrote:
> > Its the
> > getNextBreakPoss/addAreas methods in TextLM and 
> > LineLM that are scarey.
> > 
> 
> Yes, that code is very complex (I wasn't able to fix a
> problem with the space-after property despite much
> effort), and I'm not sure there's anything that can be
> done to make it simpler.  Fortunately, some (Simon,
> Luca) appear to be able to work better with it.

The getNextBreakPoss/addAreas methods in TextLM and LineLM are scary
indeed, probably because they try to deal with so many cases. I
believe Luca's patch made the logic much cleaner. Unfortunately, that
method has not yet been extended to the descendant LMs.

And that seems a more important problem, the difficulty of programming
the LM setup with its two passes, getNextBreakPoss and addAreas, over
the LM tree. I believe it must be made simpler to allow a decent Java
programmer to add code to the layout system. It is an aspect I want to
pay attention to, but I will take it slowly and cautiously.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: [GUMP@brutus]: xml-fop-maintenance/xml-fop-maintenance failed

[Clay Leeds]

The thing that caught my eye is that it indicates xml-fop-maintenance.  
I thought the maintenance branch (fop-0_20_2-maintain) was frozen (I  
haven't noticed anyone updating the code--I doubt it, but could it be  
my manual update of the design/layout.html page? If so, my apologies!).

At first I thought it was an extension of the problems I'm having with  
the xml-fop /forrest/ builds, but forrest isn't mentioned (although  
cocoon is, but that could just be because cocoon and the other projects  
use FOP's maintenance branch).

Web Maestro Clay
On Aug 3, 2004, at 4:19 PM, Sam Ruby wrote:
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact folk at [EMAIL PROTECTED]
Project xml-fop-maintenance has an issue affecting its community  
integration.
This issue affects 8 projects.
Project State : 'Failed', Reason 'Build Failed'
The following are affected:
- cocoon-block-fop :  Java XML Framework
- cocoon-block-tour :  Java XML Framework
- jakarta-turbine-3 :  A servlet based framework.
- jakarta-turbine-flux :  Servlet based framework
- jakarta-turbine-site :  Servlet based framework
- jgen :  Flash 5 Content Generation
- scarab :  Issue Tracking Built for the Ages
- xml-fop-maintenance :  XSL-FO (Formatting Objects) processor  
(Maintenance branch)

Full details are available at:
 
http://brutus.apache.org/gump/public/xml-fop-maintenance/xml-fop- 
maintenance/index.html

That said, some snippets follow:
The following annotations were provided:
 -DEBUG- Sole jar [fop.jar] identifier set to project name
 -INFO- Made directory  
[/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes]
 -INFO- Enable "verbose" output, due to 0 previous error(s).
 -INFO- Failed with reason build failed
 -INFO- Enable "debug" output, due to build failure.

The following work was performed:
http://brutus.apache.org/gump/public/xml-fop-maintenance/xml-fop- 
maintenance/gump_work/build_xml-fop-maintenance_xml-fop- 
maintenance.html
Work Name: build_xml-fop-maintenance_xml-fop-maintenance (Type: Build)
State: Failed
Elapsed: 30 secs
Command Line: java -Djava.awt.headless=true  
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/ 
build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/ 
java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/ 
java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml- 
commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main  
-verbose -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml  
-Dbuild.sysclasspath=only gump
[Working Directory:  
/usr/local/gump/public/workspace/xml-fop-maintenance]
CLASSPATH :  
/usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/ 
workspace/xml-fop-maintenance/build/classes:/usr/local/gump/public/ 
workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/ 
workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ 
ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/ 
lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant- 
junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant- 
launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant- 
nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/ 
local/gump/public/workspace/xml-batik/batik-20040803/lib/batik- 
util.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/ 
lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik 
-20040803/lib/batik-css.jar:/usr/local/gump/public/workspace/xml- 
batik/batik-20040803/lib/batik-bridge.jar:/usr/local/gump/public/ 
workspace/xml-batik/batik-20040803/lib/batik-xml.jar:/usr/local/gump/ 
public/workspace/xml-batik/batik-20040803/lib/batik-svg-dom.jar:/usr/ 
local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-awt- 
util.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/ 
lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/ 
batik-20040803/lib/batik-gui-util.jar:/usr/local/gump/public/ 
workspace/xml-batik/batik-20040803/lib/batik-dom.jar:/usr/local/gump/ 
public/workspace/xml-batik/batik-20040803/lib/batik-ext.jar:/usr/ 
local/gump/public/workspace/xml-batik/batik-20040803/lib/batik- 
svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/ 
lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik 
-20040803/lib/batik-extension.jar:/usr/local/gump/public/workspace/ 
xml-batik/batik-20040803/lib/batik-gvt.jar:/usr/local/gump/public/ 
workspace/avalon/framework/target/avalon-framework-20040803.jar:/usr/ 
local/gump/public/workspace/avalon/framework/impl/target/avalon- 
framework-impl-20040803.jar:/usr/local/gump/public/workspace/avalon/ 
framework/api/target/avalon-framework-api 
-20040803.jar

[GUMP@brutus]: xml-fop/xml-fop failed

[Sam Ruby]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact folk at [EMAIL PROTECTED]

Project xml-fop has an issue affecting its community integration.
This issue affects 1 projects.
Project State : 'Failed', Reason 'Build Failed'
The following are affected:
- xml-fop :  XSL-FO (Formatting Objects) processor


Full details are available at:

http://brutus.apache.org/gump/public/xml-fop/xml-fop/index.html

That said, some snippets follow:


The following annotations were provided:
 -DEBUG- Sole jar [fop.jar] identifier set to project name
 -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop/build/classes]
 -INFO- Enable "verbose" output, due to 0 previous error(s).
 -INFO- Failed with reason build failed
 -INFO- Enable "debug" output, due to build failure.


The following work was performed:
http://brutus.apache.org/gump/public/xml-fop/xml-fop/gump_work/build_xml-fop_xml-fop.html
Work Name: build_xml-fop_xml-fop (Type: Build)
State: Failed
Elapsed: 23 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -verbose 
-Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only gump 
[Working Directory: /usr/local/gump/public/workspace/xml-fop]
CLASSPATH : 
/usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop/build/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon/framework/target/avalon-framework-20040803.jar:/usr/local/gump/public/workspace/avalon/framework/impl/target/avalon-framework-impl-20040803.jar:/usr/local/gump/public/workspace/avalon/framework/api/target/avalon-framework-api-20040803.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-20040803.jar:/usr/local/gump/public/workspace/jfor/dist/lib/jfor-20040803.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar-
[javac] 
/usr/local/gump/public/workspace/xml-fop/src/java/org/apache/fop/svg/SVGUserAgent.java
[javac] 
/usr/local/gump/public/workspace/xml-fop/src/java/org/apache/fop/svg/SVGUtilities.java
[javac] 
/usr/local/gump/public/workspace/xml-fop/src/java/org/apache/fop/tools/TestConverter.java
[javac] 
/usr/local/gump/public/workspace/xml-fop/src/java/org/apache/fop/tools/anttasks/Compare.java
[javac] 
/usr/local/gump/public/workspace/xml-fop/src/java/org/apache/fop/tools/anttasks/Fop.java
[javac] 
/usr/local/gump/public/workspace/xml-fop/src/java/org/apache/fop/tools/anttasks/RunTest.java
[javac] 
/usr/local/gump/public/workspace/xml-fop/src/java/org/apache/fop/tools/anttasks/SerializeHyphPattern.java
[javac] 
/usr/local/gump/public/workspac

[GUMP@brutus]: xml-fop-maintenance/xml-fop-maintenance failed

[Sam Ruby]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact folk at [EMAIL PROTECTED]

Project xml-fop-maintenance has an issue affecting its community integration.
This issue affects 8 projects.
Project State : 'Failed', Reason 'Build Failed'
The following are affected:
- cocoon-block-fop :  Java XML Framework
- cocoon-block-tour :  Java XML Framework
- jakarta-turbine-3 :  A servlet based framework.
- jakarta-turbine-flux :  Servlet based framework
- jakarta-turbine-site :  Servlet based framework
- jgen :  Flash 5 Content Generation
- scarab :  Issue Tracking Built for the Ages
- xml-fop-maintenance :  XSL-FO (Formatting Objects) processor (Maintenance branch)


Full details are available at:


http://brutus.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/index.html

That said, some snippets follow:


The following annotations were provided:
 -DEBUG- Sole jar [fop.jar] identifier set to project name
 -INFO- Made directory 
[/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes]
 -INFO- Enable "verbose" output, due to 0 previous error(s).
 -INFO- Failed with reason build failed
 -INFO- Enable "debug" output, due to build failure.


The following work was performed:
http://brutus.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/gump_work/build_xml-fop-maintenance_xml-fop-maintenance.html
Work Name: build_xml-fop-maintenance_xml-fop-maintenance (Type: Build)
State: Failed
Elapsed: 30 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -verbose 
-Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only gump 
[Working Directory: /usr/local/gump/public/workspace/xml-fop-maintenance]
CLASSPATH : 
/usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-20040803/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon/framework/target/avalon-framework-20040803.jar:/usr/local/gump/public/workspace/avalon/framework/impl/target/avalon-framework-impl-20040803.jar:/usr/local/gump/public/workspace/avalon/framework/api/target/avalon-framework-api-20040803.jar-
[javac] 
/usr/local/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/tools/DocumentReader.java
[javac] 
/usr/local/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/tools/IOUtil.java
[javac] 
/usr/local/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/tools/TestConverter.java
[javac] 
/usr/local/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/tools/URLBuilder.java
[javac] 
/usr/local/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/tools/anttasks/Compare.java
[javac] 
/usr/local/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/tools

DO NOT REPLY [Bug 30448] New: - inline block render issues

[bugzilla]

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_bug.cgi?id=30448

inline block render issues

   Summary: inline block render issues
   Product: Fop
   Version: 0.20.5
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This bug is reproducible on my system - fedora core 2, fop 0.25.5, using inline
blocks.

I am using superscripting in inline blocks (12. 

Throughout my entire document, it works just fine except for one instance. When
the word with the superscript characters appears in shows up first on a new
line, but not the first word in the paragraph, all tags except font-size are
ignored when rendered. The 12 would not superscript until i put a test word in
front of it.

DO NOT REPLY [Bug 29124] - New line breaking algorithm

[bugzilla]

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_bug.cgi?id=29124

New line breaking algorithm





--- Additional Comments From [EMAIL PROTECTED]  2004-08-03 15:00 ---
Luca, I also thank you for your time and commitment. Grazie mille^H^H^H^H^H un 
miliardo! I'm sure it 
is very much appreciated by the other COMMITTERs, as well as the throngs who will 
benefit from your 
time and energy in the future. This is a very exciting addition to FOP, and I'm hoping 
it will help to 
simplify the code in other ways as well. It's really nice to have a multitude of 
people who 'capish' (grok) 
the inner workings of FOP.

Web Maestro Clay

DO NOT REPLY [Bug 29124] - New line breaking algorithm

[bugzilla]

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_bug.cgi?id=29124

New line breaking algorithm





--- Additional Comments From [EMAIL PROTECTED]  2004-08-03 14:42 ---
Thanks again for you work--we have very few who can work on layout.

Apparently, Dr. Knuth wouldn't seem to mind using his algorithms:
http://lpf.ai.mit.edu/Patents/knuth-to-pto.txt

DO NOT REPLY [Bug 29124] - New line breaking algorithm

[bugzilla]

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_bug.cgi?id=29124

New line breaking algorithm





--- Additional Comments From [EMAIL PROTECTED]  2004-08-03 13:32 ---
Thanks, you will need to add the comments in this patch to the *code*, people 
will not always have the benefit of this Bugzilla entry when looking at it.  
This is extremely important, as layout is very complex.

Also, is this Knuth algorithm copyrighted?  Where did you get it from?  It is 
rare that we have classes named after authors.

Glen

DO NOT REPLY [Bug 29124] - New line breaking algorithm

[bugzilla]

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_bug.cgi?id=29124

New line breaking algorithm





--- Additional Comments From [EMAIL PROTECTED]  2004-08-03 13:15 ---
I just realized that in the patch there is a line commented out, while it 
shouldn't be. 

It's in the LineLayoutManager, in the method getNextBreakPoss();
the code at the moment is:

  ...
  if (true) {
  //if ((iBPcount = findBreakingPoints(currPar, context.getStackLimit().opt, 
maxAdjustment)) == 0) {
  ...

The commented line should be uncommented, and the "if (true) {" removed.
Anyway, the program works all the same.

Sorry for the oversight!
Luca

DO NOT REPLY [Bug 29124] - New line breaking algorithm

[bugzilla]

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_bug.cgi?id=29124

New line breaking algorithm





--- Additional Comments From [EMAIL PROTECTED]  2004-08-03 12:45 ---
Created an attachment (id=12309)
test fo file

DO NOT REPLY [Bug 29124] - New line breaking algorithm

[bugzilla]

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_bug.cgi?id=29124

New line breaking algorithm





--- Additional Comments From [EMAIL PROTECTED]  2004-08-03 12:45 ---
Created an attachment (id=12308)
patch (second edition)

DO NOT REPLY [Bug 29124] - New line breaking algorithm

[bugzilla]

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_bug.cgi?id=29124

New line breaking algorithm





--- Additional Comments From [EMAIL PROTECTED]  2004-08-03 12:41 ---

Hi all

At long last, I have finished the patch implementing Knuth's line breaking 
algorithm; it took me more than I expected, mainly because of a long sequence 
of hw and sw troubles ... Murphy's laws are not something to laugh at! :-)

I have worked on [Line, Text, InlineStacking, LeafNode]LM, so the algorithm 
should work well with any fo file containing text, leaders, characters, 
inlines and the other formatting objects handled by a LeafNodeLM (external 
graphics, pagenumbers and citations).

The general idea of Knuth algorithm is:

  try to find breaking points without hyphenating words
  if this fails
hyphenate all words
try again

The "hyphenate all words" phase could be time-expansive, so this step is 
performed trying to use as much as possible the information already known, and 
to minimize the changes to the existing sequence of elements.
The old sequence is used to collect word fragments, and elements are replaced 
only if the LM which created them has something to change.
So, "hyphenate all words" means:

  scan the old sequence once:
collect word fragments
hyphenate word
  scan the old sequence once more:
if the LM which returned this element has changed something
  replace all elements returned by this LM
 
These are the new methods added; at the moment, I added them to the 
LayoutManager interface, but maybe it could be better to create a new 
interface implementd only by LM returning inline areas.

+ getNextKnuthElement()
This is used instead of getNextBreakPoss().
The next step (I have already started working on it) would be to use the same 
method all LM use.

+ addALetterSpaceTo()
The low-level LMs (TLMs, LNLMs) have only a partial view of the text, and 
therefore cannot know the exact number of letter spaces, while the LineLM has 
a full view.
If a TLM's text is "Tex", it can only suppose it has 2 letter spaces; if the 
following formatting object is a character "t", the LineLM tells the TLM to 
add a letter space, as the "x" is not the last letter of the word.

+ getWordChars()
This is not a new method, it just has different parameters; text is collected 
from fo:characters too.

+ hyphenate()
The TLM does not apply the changes to vecAreaInfo immediately, otherwise the 
existing Position objects stored in the old sequence couldn't be used any 
more. The LeafNodeLM returns a single area, so it can apply changes immediatly.

+ applyChanges()
This method tells the TLM to apply the changes to vecAreaInfo; all LM returns 
true if something is changed or false otherwise, so the LLM knows whether it 
has to replace the old elements or not.

+ getChangedKnuthElement()
This is used by the LLM to obtain the new elements.

+ getWordSpaceIPD()
This is used by the LLM to ask for the word space dimension; the LLM needs it 
to center text.

A few details to fix:

- word spacing and letter spacing are now fully implemented, they can both 
have MinOptMax values; but I am still thinking about how to differentiate a 
user-defined zero value from a default zero value ...

- Leaders with leader-pattern = "rule" or "space" work well; with "dots" the 
space left is right, but the dots don't fill it properly. Leaders with leader-
pattern="use-content" don't work, as the ContentLayoutManager has at the 
moment only a null implementation of the method getNextKnuthElement.
There is also a minor bug concerning (IMO) white space handling: if there 
white space both before and after the leader, the latter one is removed, so 
instead of
  word __ word
the output shows
  word __word

- with the other fo elements (fo:externalgraphic, fo:page-number and fo:page-
number-citation) the LeafNodeLM behave exactly the same way as with the old 
code, i.e. a fo:page-number-citation generates a "?  ".

- text-align-last is partially implemented; text-align-last = "justify" works 
only if text-align = "justify" too; this is because Knuth's algorithm doesn't 
provide for a different alignment for the last line.

I'm going to attach:
- the patch to existing files and new files
- a test fo file

Re: Switch from AddLMVisitor to FObj.addLayoutManager()

[Glen Mazza]

--- Chris Bowditch <[EMAIL PROTECTED]> wrote:
> Its the
> getNextBreakPoss/addAreas methods in TextLM and 
> LineLM that are scarey.
> 

Yes, that code is very complex (I wasn't able to fix a
problem with the space-after property despite much
effort), and I'm not sure there's anything that can be
done to make it simpler.  Fortunately, some (Simon,
Luca) appear to be able to work better with it.

Glen

Re: Switch from AddLMVisitor to FObj.addLayoutManager()

[Chris Bowditch]

Glen Mazza wrote:
Well, the number of patches and enhancements made to
layout/rendering has only been about 2-3 per month in
the 12 months that we've had AddLMVisitor.  FOP won't
finish at that rate, and that *will* affect the users.
I agree that FOP wont finish at its current rate of development! Not sure how 
to change this and still keep a roof over my head. LOL

In the 24 months preceding that change (i.e., the
original design I'm recommending we return to), I
believe it was several times higher, perhaps an
average of 25 changes per month.  Also, the developers
at that time seemed to obtain a much higher grokkage
of the layout/rendering code base.
The statistics dont tell the full story. The reason the patch rate was so much 
higher before the Visitor pattern was introduced is because Keiron (one of the 
main architects of the redesign) was allowed to work on FOP as part of his 
paid job, and he seemed to disappear not long before Victor started his 
modularization efforts. Also because the maintenance code had not yet been 
frozen (of course, you might not be including patches to branches in your 
statistics)

Nice things happen when you drop the IQ needed to work
in the code--and simplifications have a habit of
begetting more simplifications, as relationships that
were previously obscured/unknown become clearer.[1]  
I tend to agree, but I personally dont find the Vistor pattern the reason the 
code is so complex. Its the getNextBreakPoss/addAreas methods in TextLM and 
LineLM that are scarey.

In other words, I may be able to propose even more
simplifications after this on things I currently can't
see with the code as it is.  Let's try to get this
system down to something that a 12 year old can finish
in a weekend.  (I believe Victor has one he can lend
us as a guinea pig.)
Ouch!
At any rate, given that most FO's generate and/or
return areas (per the Rec), I don't have a problem
with one selecting and initializing its own
LayoutManager.  That is basically what happens anyway,
even with the middle man in between.
I dont have a problem with that either. I remain -0 on this change.
Chris

Re: Redesign

[Chris Bowditch]

Clay Leeds wrote:
On Aug 2, 2004, at 1:48 AM, Chris Bowditch wrote:
Clay Leeds wrote:

Just to be sure, are these amongst the changes you're looking for:

Hi Clay, yes these are the changes I was looking for. If you could 
apply the changes manually I would be most grateful. Thanks,

Chris

Done. Keep in mind, I *manually* edited the page (vi is my friend!), and 
that's how I made the update. I actually deleted the 3 TRs in the TABLE 
(the 2 modified indicated below, and the one between), and then pasted 
the updated version. If there were other changes you made to that file, 
they didn't make it in.
Hi Clay - thanks for that. The changes I made were all to the TODO table.
Web Maestro Clay
p.s. It was a bit of a rush editing the live xml.apache.org site... I 
probably shouldn't like it that much! :-D
Glad you enjoyed it!
Chris