UAX#14 commit

2006-12-22 Thread Manuel Mall
Just committed the UAX#14 changes. The commit looks much bigger than it 
really is because of the restructure of the codegen directories.

One point to note - There is one file without a license header: 
src/codegen/unicode/data/LineBreakPairTable.txt
This file is special in the sense that it is an input to the code 
generation and it is manually produced / maintained by going to 
http://www.unicode.org/reports/tr14/ and then simply from your browser 
copy and paste the table 2 (section 7.3). Yes, that's a bit of an 
unusual procedure but at least it works :-).

Note also that the code generation is still outside the normal build and 
would not usually required (see target codegen-unicode in build.xml).

Manuel


Fix for bugs 41019 + 41121

2006-12-22 Thread Luca Furini

Hi all

I have a patch fixing bugs 41019 and 41121, for both trunk and float 
branch, and I'm wondering how it's best for me to proceed in order to 
avoid merging problems: should I change both trunk and branch, or just one 
of them?


The patch is extremely simple and does not break any testcase: I only had 
to adjust the checks in a testcase because of the different line breaks. 
However, it adds some three lines to the TextLM, so maybe it's better if I 
wait for Simon to apply his unicode breaking changes?


I'm attaching the patches, just to let you see if they interfere with 
someone else's work-in-progress.


(sorry for repeating what I wrote some time ago, but I have experienced 
some e-mail problems and I probably lost some messages)


Regards
   LucaIndex: 
test/layoutengine/standard-testcases/block-container_content_size_percentage.xml

===

--- 
test/layoutengine/standard-testcases/block-container_content_size_percentage.xml
(revision 486106)

+++ 
test/layoutengine/standard-testcases/block-container_content_size_percentage.xml
(working copy)

@@ -61,9 +61,9 @@

 !-- from the spec: If that dimension is not specified explicitly (i.e., 
it depends on 

  content's blockprogression-dimension), the value is interpreted as 
auto. --

 !-- The 10% are ignored in this case. --

-eval expected=28800 xpath=//flow/block[2]/@bpd/ !-- 2 lines --

+eval expected=43200 xpath=//flow/block[2]/@bpd/ !-- 3 lines --

 eval expected=10 xpath=//flow/block[2]/@ipd/

-eval expected=28800 xpath=//flow/block[2]/block[1]/block[1]/@bpd/

+eval expected=43200 xpath=//flow/block[2]/block[1]/block[1]/@bpd/

 eval expected=5 xpath=//flow/block[2]/block[1]/block[1]/@ipd/

 

 !-- absolute --

@@ -76,9 +76,11 @@

 !-- from the spec: If that dimension is not specified explicitly (i.e., 
it depends on 

  content's blockprogression-dimension), the value is interpreted as 
auto. --

 !-- The 10% are ignored in this case. --

-eval expected=43200 xpath=//flow/block[4]/@bpd/ !-- 3 lines --

+eval expected=57600 xpath=//flow/block[4]/@bpd/ !-- 4 lines --

 eval expected=10 xpath=//flow/block[4]/@ipd/

-eval expected=43200 xpath=//flow/block[4]/block[1]/block[1]/@bpd/

+eval expected=28800 xpath=//flow/block[4]/block[1]/block[1]/@bpd/ 
!-- the first 2 lines ... --

 eval expected=5 xpath=//flow/block[4]/block[1]/block[1]/@ipd/

+eval expected=28800 xpath=//flow/block[4]/block[1]/block[2]/@bpd/ 
!-- ... and the other 2 lines --

+eval expected=5 xpath=//flow/block[4]/block[1]/block[2]/@ipd/

   /checks

 /testcase

Index: src/java/org/apache/fop/layoutmgr/inline/TextLayoutManager.java

===

--- src/java/org/apache/fop/layoutmgr/inline/TextLayoutManager.java 
(revision 486104)

+++ src/java/org/apache/fop/layoutmgr/inline/TextLayoutManager.java 
(working copy)

@@ -1285,7 +1285,12 @@

 (new KnuthGlue(lineStartBAP, 0, 0,

new LeafPosition(this, -1), false));

 } else {

+// the first penalty is necessary in order to avoid the glue 
to be a feasible break

+// while we are ignoring hyphenated breaks

 hyphenElements.add

+(new KnuthPenalty(0, KnuthElement.INFINITE, false,

+new LeafPosition(this, -1), false));

+hyphenElements.add

 (new KnuthGlue(0, 3 * 
LineLayoutManager.DEFAULT_SPACE_WIDTH, 0,

 new LeafPosition(this, -1), false));

 hyphenElements.add

Index: src/java/org/apache/fop/layoutmgr/BreakingAlgorithm.java

===

--- src/java/org/apache/fop/layoutmgr/BreakingAlgorithm.java(revision 
486104)

+++ src/java/org/apache/fop/layoutmgr/BreakingAlgorithm.java(working copy)

@@ -545,6 +545,17 @@

 log.debug(Could not find a set of breaking points  + 
threshold);

 return 0;

 }

+// lastDeactivated was a good break, while lastTooShort and 
lastTooLong 

+// were bad breaks since the beginning;

+// if it is not the node we just restarted from, 
lastDeactivated can 

+// replace either lastTooShort or lastTooLong

+if (lastDeactivated != null  lastDeactivated != lastForced) {

+if (lastDeactivated.adjustRatio  0) {

+lastTooShort = lastDeactivated;

+} else {

+lastTooLong = lastDeactivated;

+}

+}

 if (lastTooShort == null || lastForced.position == 
lastTooShort.position) {

 if 

Re: Fix for bugs 41019 + 41121

2006-12-22 Thread Manuel Mall
On Friday 22 December 2006 18:27, Luca Furini wrote:
 Hi all

 I have a patch fixing bugs 41019 and 41121, for both trunk and float
 branch, and I'm wondering how it's best for me to proceed in order to
 avoid merging problems: should I change both trunk and branch, or
 just one of them?

 The patch is extremely simple and does not break any testcase: I only
 had to adjust the checks in a testcase because of the different line
 breaks. However, it adds some three lines to the TextLM, so maybe
 it's better if I wait for Simon to apply his unicode breaking
 changes?


I woulds think that the patch I just submitted may force you to redo 
your patch for trunk as most of my changes are in TextLM.

 I'm attaching the patches, just to let you see if they interfere with
 someone else's work-in-progress.

 (sorry for repeating what I wrote some time ago, but I have
 experienced some e-mail problems and I probably lost some messages)

 Regards
 Luca
Manuel


Re: Codegen directory structure

2006-12-22 Thread Jeremias Maerki
Baaah, sorry. Looks like I misunderstood you. You meant src/codegen, of
course, not build/codegen. Sorry for the noise.

On 21.12.2006 21:16:51 Jeremias Maerki wrote:
 Me, too. In that case, I'd prefer not to place the generated sources
 under the build directory since this is, for me, strictly a temporary,
 build-related directory.
snip/

Jeremias Maerki



LineBreakUtils compilation error?

2006-12-22 Thread Luca Furini

I've just updated my local copy of trunk and rebuilt.

At first, I could not be able to successfully complete the compilation, as 
I received an error concerning the file 
src/java/org/apache/fop/text/linebreak/LineBreakUtils.java non containing 
the class org.apache.fop.text.linebreak.LineBreakUtils.


Indeed, the reported package inside the file was
   org.apache.commons.text.linebreak
after changing it to
   org.apache.fop.text.linebreak
ant ended with a success.

Is this a little oversight, or I simply wasn't following the right 
compilation procedure?


Regards
Luca


Re: Barcode4J and Fop Trunk

2006-12-22 Thread Jeremias Maerki
Yes, of course.

On 22.12.2006 11:35:40 Simon Pepping wrote:
 On Thu, Dec 21, 2006 at 09:03:51PM +0100, Jeremias Maerki wrote:
  I've been working on a DataMatrix implementation for Barcode4J lately
  which is partly responsible for my lack of presence here. This work is
  almost finished and I plan to do an alpha release of Barcode4J 2.0 in
  the first week of January 2007. When I get this off my table I have more
  time left for FOP again.
 
 Does that include the mentioned new FOP extension? If so, I will
 change the upgrade text to January 2007.
 
 Simon
  
  On 21.12.2006 17:09:47 Vincent Hennebert wrote:
   (As you can see I'm currently checking the consistency of the
   documentation before releasing)
   
   On the Upgrading page [1] it is stated that The new FOP extension for
   Barcode4J will be available in January 2006. By quickly looking at the
   Barcode4J I haven't found any relevant information about that extension.
   What is its status? Should we simply replace 2006 with 2007 ;-) ?
   
   Vincent
   
   [1] http://xmlgraphics.apache.org/fop/0.92/upgrading.html
 
 -- 
 Simon Pepping
 home page: http://www.leverkruid.eu



Jeremias Maerki