Re: cvs commit: xml-fop/test/layoutengine/testcases indent2.xml

2005-03-17 Thread Simon Pepping
On Thu, Mar 17, 2005 at 04:05:12PM +0100, Jeremias Maerki wrote:
 
 On 17.03.2005 15:02:02 Andreas L. Delmelle wrote:
   -Original Message-
   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
  
  snip/
  
   fo:block text-indent=20pt text-align=justify
 This is just for testing purpose and this line will be indented.
  
 fo:blockThis is the nested block./fo:block
  
 The text following the nested block should be indented as well.
  
  Errmm... Correction: The OP for the recent issue on fop-user claimed the
  exact opposite
  
  ...the text following the second block should not be indented since
  text-indent applies only to the first line of that block and not to any
  subsequent text in that block
  
  He did add, however, that he wasn't sure if this was as per spec.
 
 I'm not sure either, to be honest. You could argue that after a nested
 block you have a new block even if it's the same XML element creating
 these two blocks. Either way, it's good to have a test case around that
 reminds us about this issue. The checks still need to be written after
 all...

I agree with the submitter of bug 34058. Later parts of a block should
not be indented. A clear use case is this:

block: The following formula
nested block: displayed formula
block continued: proves our point.

In this example, even the sentence continues, and should not be
indented. The same is true if the second part would start with a new
sentence. If a user wants to start a new paragraph, with new
indentation, a new block should be specified.

Regards, Simon

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



Re: [VOTE] Move all hyphenation patterns to offo.sourceforge.net

2005-03-17 Thread Simon Pepping
On Thu, Mar 17, 2005 at 04:02:00PM +0100, Jeremias Maerki wrote:
 
 On 17.03.2005 15:02:02 Andreas L. Delmelle wrote:
or b) making the XML available via the userconfig.
  
   You mean the uncompiled hyphenation XMLs? Not sure here.
  
  Yes, I wasn't sure of it myself... Ultimately, a hyph-only JAR containing
  only compiled patterns would render this approach obsolete --suboptimal at
  the very least.
  In that case, the userconfig page might need a small update too; the
  hyphenation-dir setting can be dropped.
 
 I don't think it would render it obsolete. Automatic compilation of the
 hyphenation patterns could be seen as user-friendly. Fewer things to do.
 Just a thought. It's secondary anyway.

FOP is able to compile FOP-format hyphenation patterns at run time,
and use the result during that run. No compiled file is written. The
HEAD code does currently not listen to any user configuration to find
those files. hyphenation-dir is observed in fop-0.20. In principle it
would be nice to restore this behaviour, and to extend it to
OOo-format patterns. But it is certainly secondary.

Regards, Simon

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



Re: cvs commit: xml-fop/src/java/org/apache/fop/area/inline InlineParent.java

2005-03-17 Thread Simon Pepping
On Thu, Mar 17, 2005 at 08:48:03AM +0100, Finn Bock wrote:
 [EMAIL PROTECTED] wrote:
 
 gmazza  2005/03/16 15:18:43
 
   Modified:src/java/org/apache/fop/layoutmgr LineLayoutManager.java
 StaticContentLayoutManager.java
 AbstractLayoutManager.java
 PageSequenceLayoutManager.java
 BlockLayoutManager.java LeafNodeLayoutManager.java
 LayoutManager.java BlockContainerLayoutManager.java
 InlineStackingLayoutManager.java
 BlockStackingLayoutManager.java
 FlowLayoutManager.java ContentLayoutManager.java
 TextLayoutManager.java LeaderLayoutManager.java
src/java/org/apache/fop/layoutmgr/table Cell.java
 Caption.java Body.java TableLayoutManager.java
 Row.java TableAndCaptionLayoutManager.java
src/java/org/apache/fop/area LineArea.java Area.java
src/java/org/apache/fop/layoutmgr/list
 ListItemLayoutManager.java Item.java
 ListBlockLayoutManager.java
src/java/org/apache/fop/area/inline InlineParent.java
   Log:
   Changed from addChild(Area) to clearer addChildArea(Area).
 
 Yes, that looks like a good example of the kind of change which Jeremias 
 kindly asked you not to do right at this moment.

I second that. Glen, other team members than you expect that Jeremias
is about to make important improvements to these LMs, and agree with
Jeremias that your working on the same piece of code is going to
bother his work. Renaming, moving things around and refactoring is the
worst thing you can do at such a time. Code repositories are a
powerful tool, but they do not take away the problems that arise when
two people are working on the same piece of code. Please, leave this
area to Jeremias for the weeks to come.

Regards, Simon

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



TableLayout/KnuthElementsForTables

2005-04-09 Thread Simon Pepping
Jeremias,

I read your TableLayout/KnuthElementsForTables wiki page with
interest. Luca's algorithm is a fine algorithm.

I do have a problem with your last example. Half of the border-after
of the table-header is counted twice, once in the row heights and once
in the header itself. All heights before the page break except the
second one are 2 units too high, and those after the page break are 4
units too high when I compare them with your drawings of the table.

I believe it is better to omit half of the border-after
of the table-header and half of the border-before of the table-footer
from the row height. Then I get the following calculations:

Header is 5 + 8 = 13
Footer is 8 + 5 = 13

row1: 15 + (2/2) = (16,16,16)
row2: 20 + (2/2) = (21,21,21)
row group (37,37,37)

Step 1:
stepw= 10
maxRemainingHeight = 37
addedBoxHeight = 0
penalty = 10 + 37 - 37 = 10
effPenalty: w = 10 (space for block1) + 13 (header) + 4 (border-after-header) + 
4 (border-before-footer) + 13 (footer)
box = 10 - 0 - 10 = 0

Step 2:
stepw = 15
maxRemaningHeight = 20
addedBoxHeight = 0
penalty = 15 + 20 - 37 = -2
offPenalty: w = -2 (calc penalty) + 13 + 4 + 4 + 13
box = 15 - 0 - (-2) = 17

Step 3:
stepw = 10 + 10 = 20
maxRemainingHeight = 20
addedBoxHeight = 17
penalty = 20 + 20 - 37 = 3
effPenalty: w = 3 (calc penalty) + 13 + 4 + 4 + 13
box = 20 - 17 - 3 = 0

Step 4:
stepw = 10 + 10 + 10 = 30
maxRemaningHeight = 20
addedBoxHeight = 17
penalty = 30 + 20 - 37 = 13
effPenalty: w = 14 (calc penalty) + 13 + 4 + 4 + 13
box = 30 - 17 - 13 = 0

Step 5:
stepw = 15 + 2 + 20 = 37
maxRemainingHeight = 0
addedBoxHeight = 17
penalty = 37 + 0 - 37 = 0 (last step, omit penalty)
box = 37 - 17 - 0 = 20

box(0)
penalty(10) - 10/37
box(17)
penalty(-2) - 15/20
box(0)
penalty(3)  - 20/20
box(0)
penalty(13) - 30/20
box(20)
- 37

box(0)
penalty(44) //incl. header and footer - 44/71
box(17)
penalty(32) //incl. header and footer - 49/54
box(0)
penalty(37) //incl. header and footer - 54/54
box(0)
penalty(47) //incl. header and footer - 64/54
box(20)
box(17) //header
box(17) //footer
  - 71

You see I can avoid the subtraction of 2 for the second page break,
which makes the calculation more regular. I do get a negative
penalty. I do not believe that that is a problem, less so because it
is added to the penalty for the header/footer/borders. It expresses
the fact that for this page break the table is shorter than without
page break, due to the merger of the row border with the header and
footer borders.

Regards, Simon

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



Re: Error in LabelEndFunction?

2005-04-12 Thread Simon Pepping
On Tue, Apr 12, 2005 at 07:04:37PM +0200, Luca Furini wrote:
 Jeremias Maerki wrote:
 
 By the way, it seems that you forgot to commit some changes to
 KnuthPossPosIter.

With Jeremias being away for the week, I committed a quick fix. I hope
it works as intended.

Regards, Simon

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



Re: Branch deadline coming up

2005-04-20 Thread Simon Pepping
On Wed, Apr 20, 2005 at 05:51:47PM +0200, Luca Furini wrote:
 Simon Pepping wrote:
 
  I am worried about performance. Knuth elements are passed up and down
  the LM tree, and at each step the Position is wrapped or
  unwrapped. That probably occurs very many times, and together these
  operations could require considerable processing time. Perhaps it can
  be avoided. I do not see a fundamental reason why the whole stack of
  ancestral LMs should be contained in a Knuth element.
 
 Jeremias Maerki wrote:
 
 # With just a little additional flexibility in the addAreas()
 # methods we can probably get rid of the wrapping.
 
 A few wrappings could be avoided; for example, I think that the FlowLM
 could leave the Positions unchanged, as it is the PSLM only child (besides
 StaticContentLMs).
 
 But maybe your idea is much better. PSLM.addAreas would call directly
 LineLM.addAreas() (or TableContentLM.addAreas(), or ListItemLM.addAreas())
 which could make a simple check to see whether there is already a parent
 area or it must be created calling BlockLM.addAreas(), and so on. The
 stack of method calls would be turned upside-down.

Indeed. Another idea is that PSLM.addAreas calls the addAreas method
of each of its children, as it does now, but also passes the page
break Position. Then the LMs continue to add areas until one of them
reaches the page break Position.

Regards, Simon

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



Re: Collapsing border model

2005-05-03 Thread Simon Pepping
I am afraid I just followed your interpretation. I will try to read
the spec more independently and more critically.

Regards, Simon

On Tue, May 03, 2005 at 03:14:50PM +0200, Jeremias Maerki wrote:
 I've just realized I probably made a big mistake interpreting collapsing
 border model. While going through the specs to reread everything about
 the outer table border I carefully reread the following passages:
 
 XSL-FO 1.0, 6.7.2, Trait Derivation:
 If the value of the border-collapse property is collapse or
 collapse-with-precedence the border is determined, for each segment,
 at the cell level.
 
 So far I've based everything on being determined, for each segment, at
 the segment level as it seems. I even had the part about cell level
 highlighted in my print-out and still got it wrong. Damn me!
 
 But I think I know why I got it wrong:
 
 XSL-FO 1.0, 6.7.10, Trait Derivation:
 If the value of the border-collapse trait is collapse, the border for
 each side of the cell is determined by, for each segment of a border,
 selecting, from all border specifications for that segment, the border
 that has the most eye catching border style...
 
 Obviously sounded too much like a per-segment thing.
 
 Under the new light, this means a totally different thing. Looking at my
 (buggy) example [1] this means that the segment where the arrow points
 should actually be the same broad red border as the one next to it on
 the right side.
 
 That also means that it's making the whole border resolution a lot more
 complicated. If you started with the upper left cell and tried to
 determine the after border you can end up taking the after border
 specification from the cell on the right side of the cell. I'll have to
 think about how to implement this in an efficient way, first.
 
 But before I turn everything upside-down again, can please someone
 confirm that I was really wrong before and got it right now? Thanks a
 lot.
 
 
 [1] http://wiki.apache.org/xmlgraphics-fop/CollapsingBorderModel
 
 Jeremias Maerki
 
 PS: Can someone please beat me?
 

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



Re: Collapsing border model

2005-05-05 Thread Simon Pepping
Jeremias,

At first sight I agree with Andreas' interpretation in his reply to
this message, which I think is the same as your original
interpretation. Thinking on, however, I see that there may be a
problem with spanned cells. Is that what you are aiming at?

The cell level, means the level of the spanned cell. This suggests
indeed that each side of a spanned cell must be treated as a whole.
However, the spec says precisely:

 If the value of the border-collapse property is collapse or
 collapse-with-precedence the border is determined, for each segment,
   
 at the cell level.

and

 If the value of the border-collapse trait is collapse, the border for
 each side of the cell is determined by, for each segment of a border,
  
 selecting, from all border specifications for that segment, the border
 that has the most eye catching border style...

Moreover, the term 'cell level' is rather vague, and certainly not the
same as 'per cell'.

That seems to mean that the determination is done per segment indeed,
which agrees with your original interpretation. Note that the spec
does not define the notion of a segment, nor does the CSS2 spec. But I
take it to mean the side of a grid unit.

Your Wiki example shows a result that is probably undesirable, a
spanned cell with vastly different border segments. But apparently the
spec does not protect the user from specifying such a border
arrangement.

Probably it is not possible to define resolution of collapsing border
specifications per cell. Consider the following example:

   ++++
   ||||
   ||||
   ||||
   ||||
   ++---+++
   || |
   || |
   || |
   || |
   ++-+

On the border between rows 1 and 2 each segment is part of two cell
borders. Conflicting border specifications can only be resolved per
segment, not per cell.

Note also this remark in the spec (6.7.3 fo:table) about the
background of spanned cells: A cell that is spanned may have a
different background in each of the grid units it occupies. This is
somewhat similar to the spec allowing different segments on a side of
a spanned cell.

Regards, Simon

On Tue, May 03, 2005 at 03:14:50PM +0200, Jeremias Maerki wrote:
 I've just realized I probably made a big mistake interpreting collapsing
 border model. While going through the specs to reread everything about
 the outer table border I carefully reread the following passages:
 
 XSL-FO 1.0, 6.7.2, Trait Derivation:
 If the value of the border-collapse property is collapse or
 collapse-with-precedence the border is determined, for each segment,
 at the cell level.
 
 So far I've based everything on being determined, for each segment, at
 the segment level as it seems. I even had the part about cell level
 highlighted in my print-out and still got it wrong. Damn me!
 
 But I think I know why I got it wrong:
 
 XSL-FO 1.0, 6.7.10, Trait Derivation:
 If the value of the border-collapse trait is collapse, the border for
 each side of the cell is determined by, for each segment of a border,
 selecting, from all border specifications for that segment, the border
 that has the most eye catching border style...
 
 Obviously sounded too much like a per-segment thing.
 
 Under the new light, this means a totally different thing. Looking at my
 (buggy) example [1] this means that the segment where the arrow points
 should actually be the same broad red border as the one next to it on
 the right side.


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



Table code

2005-05-16 Thread Simon Pepping
Jeremias and Luca,

The code looks very good. I am impressed how all the details of the
stepping algorithm and the Knuth elements have been implemented by
you. I am also impressed by the strength of the stepping
algorithm. The more I turn it around, the stronger it seems to be.

I found two small points:

1. A penalty for the header and footer is added at the last step; it
   should be omitted.

2. When a grid unit is incomplete at the page break, it is not
   rendered on the first page.

Regards, Simon

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



Re: Footnotes working!

2005-05-17 Thread Simon Pepping
On Tue, May 17, 2005 at 04:48:07PM +0200, Luca Furini wrote:
 
 Footnotes should be working now.

Great.
 
 At the moment the page breaking algorithm is quite strict: it tries to
 insert every footnote in the same page where their citation is (the last
 footnote body could be split, and partially deferred to the next page).
 
 The recommendation seems to suggest that it could defer one or more
 *whole* footnotes, if there is not enough space in the page where their
 citations are, even if this is not very usual to happen in books; anyway,
 this could be fixed later.

In linguistic or theological works you may see many and long footnotes.

Regards, Simon

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



Re: Remove LayoutManager.initialize() method?

2005-06-09 Thread Simon Pepping
On Tue, Jun 07, 2005 at 12:18:50AM -0400, Glen Mazza wrote:
 Team,
 
 Anyone have a problem if I remove the initialize() method from the 
 LayoutManager interface (and assorted related code from 
 AbstractLayoutManager), by having the eight LM's currently using it 
 initialize themselves internally instead?
 
 Currently, for those 8 LM's using external initialization (i.e., 
 LM.initialize()), it is done immediately after the ParentLM is set for 
 the LM in AbstractLayoutManager.addChildLM().  So, at a minimum, I think 
 I can equivalently do this by having each class call initialize() within 
 an overridden setParent() implementation.  However, for most of the 
 eight it appears I can just call initialize() from the class' 
 constructor without needing a setParent() override.

I seem to recall that initialization in LMs was not very
consistent. If you can unify the required initializations, it would be
nice.

Regards, Simon

 This change will not prohibit specific LM's with unique requirements 
 from having a public initialize() method, if ever needed, it would just 
 require that a specific class variable be used instead of the generic 
 LayoutManager interface variable (i.e., for WidgetLayoutManager wlm, 
 call wlm.initialize() instead of LM.initialize().)
 
 Thanks,
 Glen
 

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



layoutengine test text-transform2.xml

2005-06-09 Thread Simon Pepping
Why is this expectation in text-transform2 correct:

  fo:block2: fo:wrapper text-transform=capitalizeThis tExT is 
cafo:wrapper color=redpit/fo:wrapperAfo:inline 
color=blueliZ/fo:inlineed./fo:wrapper/fo:block

eval expected=2: This Text Is CaPitALizEd. xpath=//flow/block[2]/

Reading the XSL spec, section 7.16.6, I expect 'This Text Is
Capitalized' despite the wrapper and inline elements. The spec only
speaks about words. There is no mention that fo child elements would
make a difference.

Regards, Simon

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



Re: Need help determining the cause for line spacing differences

2005-06-30 Thread Simon Pepping
Jeremias,

Here I lost you. I thought you referred to the fact that the line
distance in the trunk version is always larger than in the maintenance
version, even while the nominal line height is the same. That seems to
be due to the fact that the trunk version makes more room for the
descenders of the font (quantity follow?).

Now it seems you only refer to the ToC in the Nils' demo file.

Regards, Simon

On Wed, Jun 29, 2005 at 09:56:38PM +0200, Jeremias Maerki wrote:
 Found it myself. It's the page-number and page-number-citation LMs which
 cause bigger boxes than normal text. Test added, trying to fix it.
 
 On 29.06.2005 18:26:26 Jeremias Maerki wrote:
  I'm trying to track this down but I get nowhere. At first, I thought it
  was the default for line-height which is 1.2em for both FOP Trunk and
  0.20.5. Still, in Nils' example the document is much more compact in
  0.20.5 than in the trunk.
  
  When I dial down the default for line-height in the trunk the result
  gets better but I'm pretty sure that's the wrong approach.
  
  Does anyone else have an idea? My bag-o-ideas is soon empty.
  
  On 29.06.2005 09:12:28 bugzilla wrote:
   BTW, Nils' example shows again that we have another point to attend to: 
   Our 
   current nominal text box is much bigger than it was for 0.20.5. I've seen 
   this 
   before and I think we're approaching the time when this needs to be fixed.
  
  Jeremias Maerki
 
 
 
 Jeremias Maerki
 

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



Re: Moved files in subversion and modified working copy

2005-07-25 Thread Simon Pepping
I use svn, version 1.0.9 (r11378), as provided by Debian. If I
remember correctly, it said something like: Will not remove modified
file X, and then stopped updating. Perhaps different clients act
differently. I will get through it, one way or the other.

Regards, Simon

On Mon, Jul 25, 2005 at 05:09:35PM +0200, Jeremias Maerki wrote:
 I've just tried to simulate that scenario here. Here, my file with the
 local changes was left alone and now appears as if it were newly added.
 I could now merge it into the moved file. I wonder why it stopped
 updating on your machine (I've used SVN 1.2.1). Do you get an error
 message when the update stops?
 
 If normal updating and then merging doesn't work, I see no other way
 around doing it the hard way. :-( But then, I'm still not the total SVN
 expert.
 
 On 22.07.2005 20:55:36 Simon Pepping wrote:
  I tried out how subversion update reacts to files that were moved in
  the repository and were modified in the working copy. It does not seem
  to be very helpful. It stopped updating until I had moved the changes
  out of the way.
  
  So how do I go about moving my changes? The hard way: create a diff,
  revert the file, svn update and patch the moved file? Or is there an
  easier way?
 
 
 
 Jeremias Maerki
 

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



Re: Element list generation for tables (special case)

2005-07-27 Thread Simon Pepping
One thing that IMHO is still lacking in the table breaking code is
penalty values. ATM all penalties are 0. I believe the penalty value
should depend on the extra vertical size that the break contributes,
that is, on the penalty's width. I have no idea about the
multiplication constant, nor if it should be linear or quadratic. I am
not sure if it avoids the current case, but it is surely needed in
order to favour better breaks over worse ones.

Simon

On Wed, Jul 27, 2005 at 08:45:48PM +0200, Jeremias Maerki wrote:
 I got a test case for tables which raises not a technical but rather a
 interesting conceptual question. Please have a look at the attached test
 case. It defines a table with two columns and two rows. In the given
 setup the second row creates an break decision with the current code that
 can be argued as being bad (see the PDF). Here's an excerpt from the
 element list:
 
  8) box w=9600
  9) penalty p=0 w=0
 10) box w=28800
 11) penalty p=0 w=0
 12) box w=0 //-- this is where the second row starts
 13) penalty p=0 w=9600  //this penalty is due to the possible break after B
 14) box w=28800
 15) penalty p=0 w=0 //this is the next break poss after three lines
 //due to the orphan setting
 16) box w=28800
 
 While working on element list generation for tables I came across this
 question and decided not to do anything about it, especially since
 removing some of these break possibilities might not be desirable in all
 cases.
 
 A rule that could be easily implemented would be that we allow the first
 break possibility only after every cell in a new row contributed at
 least one of its own boxes to the combined element list.
 
 An example: If you look at page 1 of [1], step 1 would over ignored. On
 page 3 of [1], the steps 1 and 2 would be ignored.
 
 [1] http://people.apache.org/~jeremias/fop/KnuthBoxesForTablesWithBorders.pdf
 
 With this rule the element list would look like this:
 
  8) box w=9600
  9) penalty p=0 w=0
 10) box w=28800
 11) penalty p=0 w=0
 12) box w=28800 //-- this is where the second row starts
 13) penalty p=0 w=0
 14) box w=28800
 
 I'm unsure ATM what this would mean for cases with row spanning, though.
 
 I can see that this new rule would make this better in most cases. What
 worries me is that there might be cases where we wouldn't want that
 behaviour, although ATM I can't see them. So I just want to check with
 you that I haven't forgotten about anything. Or maybe someone has a
 better rule to implement this. Thoughts welcome.
 
 
 Jeremias Maerki




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



Re: getPageCount and FOP 1.0dev

2005-07-27 Thread Simon Pepping
Don't AreaTreeModel.getPageSequenceCount() and
AreaTreeModel.getPageCount(int seq) do this? AreaTreeHandler.model is
the AreaTreeModel object.

Simon

On Wed, Jul 27, 2005 at 08:43:50AM +0200, Jeremias Maerki wrote:
 Manuel,
 
 thanks for grabbing this. I think the easiest thing will be to recreate
 what was in 0.20.5. It doesn't offer very much and I have a better
 overall mechanism in mind (as a long-term solution) but for the moment
 it is easiest to do that. Here's what I would do:
 - Copy over FormattingResults and PageSequenceResults over from 0.20.5
 and replace the license header with the once you find all over FOP Trunk.
 - Go to org.apache.fop.area.AreaTreeHandler.endPageSequence() and build
 up the FormattingResults structure as it's done in 0.20.5 in
 StreamRenderer. AreaTreeHandler is more or less the old StreamRenderer.
 - When endPageSequence() is called you can probably derive the number of
 pages generated for a page-sequence by subtracting currentPageNumber
 from startPageNumber in layoutmgr.PageSequenceLayoutManager.
 - Find a way to access the FormattingResults structure in Fop.java like
 it was done in 0.20.5.
 
 As an alternative to doing this in AreaTreeHandler you might want to
 investigate fo.Root and fo.PageSequence but I'd prefer to have stuff
 like that in AreaTreeHandler.
 
 I hope that gives you some hints to do this. It shouldn't really be that
 hard.
 
 On 27.07.2005 08:13:58 Manuel Mall wrote:
  Jeremias,
  
  happy to do so - I just setup Fop under NetBeans 4.1.
  
  However, where do I start for something like this?
  
  Manuel
  
  PS: I moved this thread over to fop-dev as I assume its more appropriate
  here.
  
  -Original Message-
  From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
  Sent: Wednesday, 27 July 2005 14:08
  To: fop-users@xmlgraphics.apache.org
  Subject: Re: getPageCount and FOP 1.0dev
  
  
  No, but you're welcome to help improve the situation. :-)
  
  On 27.07.2005 03:50:46 Manuel Mall wrote:
   Jeremias post on fop-dev suggesting to push for a release made me curious
  to
   check out if the new trunk code will work with our application.
  Downloading
   it with subversion and building it with ant was not a big problem (These
   things never seem to be 100% straightforward). Some of the interfaces have
   changed and what was ...apps.Driver is now sort of ...apps.Fop. Not such a
   big deal especially as examples exist, just a nuisance if you only want to
   see if the new trunk code works with what we have got as it means code
   changes to existing code. However I am stuck with how to replace the old
   driver.getResults().getPageCount(). Is there something equivalent in
   1.0dev?
  
  
  Jeremias Maerki
  
  
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 Jeremias Maerki
 

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



Re: Element list generation for tables (special case)

2005-07-30 Thread Simon Pepping
On Wed, Jul 27, 2005 at 10:40:25PM +0200, Jeremias Maerki wrote:
 But I get the impression that this avoids the topic I raised. :-) I
 think this here is not about whether these special break conditions are
 favored or avoided but if they should be allowed at all.

OK. Yes, the rule you propose sounds OK.

Inside a row group, you may limit the rule to those columns which
start a grid unit in this row, and exclude the columns which span into
this row from a previous row.

Regards, Simon

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



Re: Element list generation for tables (special case)

2005-07-30 Thread Simon Pepping
On Wed, Jul 27, 2005 at 10:40:25PM +0200, Jeremias Maerki wrote:
 I was under the impression that the breaker automatically favors break
 decisions that take up less space. It even goes so far that if you have
 a minimum=0pt and an optimum=2opt on a space-before, that it
 currently chooses 0pt which is not so good, actually.

Penalties would help. If there were a penalty associated with the
break below 'B', then the break above it becomes more favourable. I do
not think the breaker could do that otherwise (without the newly
proposed rule).
 
 Well, we have several documented examples on the Wiki which we could
 play through to see if the breaker is likely to make bad break decisions.
 
 But I get the impression that this avoids the topic I raised. :-) I
 think this here is not about whether these special break conditions are
 favored or avoided but if they should be allowed at all.
 
 On 27.07.2005 21:54:00 Simon Pepping wrote:
  One thing that IMHO is still lacking in the table breaking code is
  penalty values. ATM all penalties are 0. I believe the penalty value
  should depend on the extra vertical size that the break contributes,
  that is, on the penalty's width. I have no idea about the
  multiplication constant, nor if it should be linear or quadratic. I am
  not sure if it avoids the current case, but it is surely needed in
  order to favour better breaks over worse ones.

Regards, Simon

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



Re: Element list generation for tables (special case)

2005-07-31 Thread Simon Pepping
On Sat, Jul 30, 2005 at 03:46:31PM +0200, Jeremias Maerki wrote:
 Sorry, but I have trouble understanding what you mean. Could you please
 elaborate with an example? Thanks.

 On 30.07.2005 13:54:25 Simon Pepping wrote:
  On Wed, Jul 27, 2005 at 10:40:25PM +0200, Jeremias Maerki wrote:
   I was under the impression that the breaker automatically favors break
   decisions that take up less space. It even goes so far that if you have
   a minimum=0pt and an optimum=2opt on a space-before, that it
   currently chooses 0pt which is not so good, actually.
 
  Penalties would help. If there were a penalty associated with the
  break below 'B', then the break above it becomes more favourable. I do
  not think the breaker could do that otherwise (without the newly
  proposed rule).

If there were a penalty value associated with a break that makes the
table longer, e.g. 0.1 * w, then the following list would result:

 8) box w=9600
 9) penalty p=0 w=0
10) box w=28800
11) penalty p=0 w=0
12) box w=0 //-- this is where the second row starts
13) penalty p=960 w=9600  //this penalty is due to the possible break after B
14) box w=28800
15) penalty p=0 w=0 //this is the next break poss after three lines
//due to the orphan setting
16) box w=28800

Now a break at 12 would have 960 demerits. A break at 10 would have 0
demerits, but because it would have less content on the page it would
have a larger stretch and that would itself associated demerits, say
500. Then the break at 10 would be selected.

In general, the table breaker may select breaks with a skew placement
of table contents, e.g.

xxx  |
 |
   --|-
 |
xxx' | yyy

over breaks with a more even placement of table contents, e.g.

xxx  | yyy'
 |
   --|-
 |
xxx' | yyy

Such breaks are rather ugly. They also make the table considerably
longer. One can use the extra length of the table as a measure of
skew placement and thus of ugliness and of the penalty value
associated with this break. This makes that breaks with a skew
placement of content are disfavoured, and only selected when more
even breaks have lots of demerits themselves, due to other causes.

Regards, Simon

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



Re: Handling of block-level FOs inside fo:inline and related

2005-08-03 Thread Simon Pepping
I have been working on that, rather slowly, as I do not have much
time.

My solution for the Knuth Elements is that each inline level LM
returns a list of Knuth sequences, inline or block. This part works
well.

The code works well for fo:inline with inline or block content. I have
not yet implemented it in other LMs except BasicLinkLM.

I have done some work for rendering. But I am not very familiar with
that part of FOP, and have not yet paid attention to details.

I will post a patch on Bugzilla. The present state of the code breaks
other inline level LMs as they do not yet return the correct data
structure for the next Knuth elements. Therefore I cannot commit it to
HEAD. I could commit it into a branch.

For the next few weeks I will also spend a lot of time on other
things. So, if I am progressing too slowly, someone else should feel
free to take this further.

Regards, Simon

On Wed, Aug 03, 2005 at 08:30:56PM +0200, Jeremias Maerki wrote:
 fo:inline, fo:bidi-override and fo:inline-container are all inline-level
 FOs and all allow block-level content. Currently, they are not
 implemented. See, for example, inline1.xml which fails with a
 ClassCastException. The FO I skipped here is fo:wrapper which in the
 current implementation doesn't really wrap its content and therefore
 avoids an important problem:
 
 Inline FOs return element lists processed by the line breaker. They
 don't have a way to return elements for the page breaker.
 
 I've been asked to do a time estimate for implementing fo:inline.
 fo:inline is particularly important since a lot of people use empty
 fo:blocks, for example, to mimic newlines. Now I wonder about how to
 implement fo:inline. The only way I came up with was to try normalizing
 the FO tree and to let fo:inline be what it currently is:
 
 Input:
 
 fo:block color=blueblah blah fo:inline 
 font-style=italicblahfo:block/blah/fo:inlineblah/fo:block
 
 Output:
 
 fo:block color=blueblah blah fo:inline 
 font-style=italicblah/fo:block
 fo:block color=blue font-style=italic/
 fo:block color=blue fo:inline 
 font-style=italicblah/fo:inlineblah/fo:block
 
 or:
 
 fo:block color=blue
   fo:blockblah blah fo:inline font-style=italicblah/fo:block
   fo:block font-style=italic/
   fo:blockfo:inline font-style=italicblah/fo:inlineblah/fo:block
 /fo:block
 
 Replicating the properties of an fo:inline to a copy shouldn't be much
 of a problem. Replicating the properties for the contained block might
 already me a little more difficult because of the whole inheritance
 stuff.
 
 Is there another way? A better way? Any ideas?
 
 For fo:bidi-override, the same approach would be used.
 
 For fo:inline-container this whole thing is easier since it generates a
 viewport/reference pair, so it will ultimately need its own breaker
 (like absolutely positioned block-containers).
 
 
 Jeremias Maerki
 

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



Re: svn: eol-style

2005-08-04 Thread Simon Pepping
I am also trying svn:keywords=Id. Many files have 'svn:keywords :
Author Date Id Revision', but my subversion manual suggests that of
those only Id is recognized, along with e.g. LastChangedDate. Id
comprises all known keywords.

Simon

On Thu, Aug 04, 2005 at 03:52:30PM +0200, Jeremias Maerki wrote:
 Maybe it would make sense to enable the auto-props feature of SVN
 client. See the SVN config file (on Windows found in
 %USERPROFILE%\Application Data\Subversion\):
 
 
 
 snip/
 ### Set enable-auto-props to 'yes' to enable automatic properties
 ### for 'svn add' and 'svn import', it defaults to 'no'.
 ### Automatic properties are defined in the section 'auto-props'.
 # enable-auto-props = yes
 
 ### Section for configuring automatic properties.
 ### The format of the entries is:
 ###   file-name-pattern = propname[=value][;propname[=value]...]
 ### The file-name-pattern can contain wildcards (such as '*' and
 ### '?').  All entries which match will be applied to the file.
 ### Note that auto-props functionality must be enabled, which
 ### is typically done by setting the 'enable-auto-props' option.
 # [auto-props]
 # *.c = svn:eol-style=native
 # *.cpp = svn:eol-style=native
 # *.h = svn:eol-style=native
 # *.dsp = svn:eol-style=CRLF
 # *.dsw = svn:eol-style=CRLF
 # *.sh = svn:eol-style=native;svn:executable
 # *.txt = svn:eol-style=native
 # *.png = svn:mime-type=image/png
 # *.jpg = svn:mime-type=image/jpeg
 # Makefile = svn:eol-style=native
 
 
 
 I'll give it a try.
 
 On 04.08.2005 15:44:07 Jeremias Maerki wrote:
  Well, for XML Files this is not a big problem usually, but for Java
  files it usually is. But for text files in general, native EOLs make
  life easier for certain people. Furthermore, I don't see any such
  conventions documented (which doesn't mean there's no project standard):
  http://xml.apache.org/fop/dev/conventions.html
  
  Within the ASF in general I see a wide-spread use of the native
  setting.
  
  On 04.08.2005 15:37:12 Chris Bowditch wrote:
   fellow devs,
   
   should this really be set to native ?
   
   I just did a merge conflicts using SVN Tortoise (BTW, SVN is really 
   superior to CVS, Im really impressed!) and it changed the line endings 
   of CR+LF. I thought the Project standard was Unix style LF line endings. 
   So shouldn't this setting reflect this?
   
   Chris
   
  
  
  
  Jeremias Maerki
 
 
 
 Jeremias Maerki
 

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



Re: ant junit target fails

2005-08-07 Thread Simon Pepping
I have always commented this test out in my working copy. I do not
like tests that actually (also) test the exact innards of certain
Xerces and Xalan versions.

I have got several copies of those two on my system, and I use them
via the endorsed-dirs mechanism. Some scripts use a different copy
than others, and for me FOP should just work with any recent parser
and transformer. IMHO An upgrade of the jars in FOP does not solve the
problem of this test file.

Regards, Simon

On Sun, Aug 07, 2005 at 06:46:17PM +0200, Jeremias Maerki wrote:
 There were a number of these issues in the past. Yes, it's definitely
 time to upgrade the Xerces and Xalan JARs, although it won't fix the
 problems for those people who don't know how to replace the default
 Xerces/Crimson and Xalan versions coming with the JDK. But that can't be
 helped. As a rule, I always use the latest Xerces and Xalan versions on
 my machine. I even have a customized Xalan ATM since the Xalan people
 haven't fixed a bug which causes a problem with Barcode4J and FOP for
 over a year now.
 
 On 07.08.2005 14:21:55 Manuel Mall wrote:
  On Sat, 6 Aug 2005 10:37 pm, you wrote:
   I am consistently getting the error below on the ant junit target.
  
  snip/
  
  Further investigation showed that I can get rid of the error by
  upgrading the xerces/xalan combination. Here is a summary of what I
  found:
  
  xalan 2.4.1/xerces 2.2.1 as extracted from SVN doesn't work
  xalan 2.5.x/xerces 2.?.? doesn't work
  xalan 2.6.1/xerces from xalan 2.6.1 bundle does prevent the error below 
  but I then get similar NAMESPACE_ERR errors from within the layout 
  engine test suite
  xalan 2.7.0/xerces from xalan 2.7.0 bundle does work
  
  All this evaluated under RH Enterprise ES 3 with Sun Java 5.0 latest
  release.
  
  Time to upgrade the xalan/xerces jars in SVN?
  
  Manuel
  
   There was 1 error:
   1)
   testFO2PDFWithDOM(org.apache.fop.BasicDriverTestCase)javax.xml.transf
  orm.TransformerException: org.w3c.dom.DOMException: NAMESPACE_ERR: An
   attempt is made to create or change an object in a way which is
   incorrect with regard to namespaces.
   at
   org.apache.xalan.transformer.TransformerIdentityImpl.transform(Transf
  ormerIdentityImpl.java:511) at
   org.apache.fop.BasicDriverTestCase.loadDocument(BasicDriverTestCase.j
  ava:62) at
   org.apache.fop.BasicDriverTestCase.testFO2PDFWithDOM(BasicDriverTestC
  ase.java:78) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
   Method)
 
 
 
 Jeremias Maerki
 

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



Re: ant junit target fails

2005-08-08 Thread Simon Pepping
On Mon, Aug 08, 2005 at 09:20:19AM +0200, Jeremias Maerki wrote:
 On 07.08.2005 20:41:42 Simon Pepping wrote:
  I have always commented this test out in my working copy. I do not
  like tests that actually (also) test the exact innards of certain
  Xerces and Xalan versions.
 
 They were not supposed to check the innards of certain Xerces and Xalan
 versions. The tests check the basic functionality of the FOP API. Given
 that most of the directy dependencies on the input source are now removed 
 (only getDefaultHandler() remains) we can probably remove some of those
 methods, especially the DOM-related ones. Do you agree?

That is right. Since FOP receives the data in all cases as a SAX
content handler, the different tests do not make a difference for FOP
anymore.

  I have got several copies of those two on my system, and I use them
  via the endorsed-dirs mechanism. Some scripts use a different copy
  than others, and for me FOP should just work with any recent parser
  and transformer.
 
 That's right, but there's simply the fact the there were a lot of little
 bugs in the TraX portion of Xalan WRT DOM. There's not much we can do
 about that in FOP.

That could be. I have just worked around the annoyance that the test
failed for reasons that I could not understand or change. But this
means that people get exceptions when they do this kind of work with
FOP and older versions of X + X. That is indeed a reason to upgrade
them in FOP's distribution.
 
  IMHO An upgrade of the jars in FOP does not solve the
  problem of this test file.
 
 Any additional ideas?

Not really, esp. if it is suspected that it is a bug in X + X.
 
Regards, Simon

  On Sun, Aug 07, 2005 at 06:46:17PM +0200, Jeremias Maerki wrote:
   There were a number of these issues in the past. Yes, it's definitely
   time to upgrade the Xerces and Xalan JARs, although it won't fix the
   problems for those people who don't know how to replace the default
   Xerces/Crimson and Xalan versions coming with the JDK. But that can't be
   helped. As a rule, I always use the latest Xerces and Xalan versions on
   my machine. I even have a customized Xalan ATM since the Xalan people
   haven't fixed a bug which causes a problem with Barcode4J and FOP for
   over a year now.
   
   On 07.08.2005 14:21:55 Manuel Mall wrote:
On Sat, 6 Aug 2005 10:37 pm, you wrote:
 I am consistently getting the error below on the ant junit target.

snip/

Further investigation showed that I can get rid of the error by
upgrading the xerces/xalan combination. Here is a summary of what I
found:

xalan 2.4.1/xerces 2.2.1 as extracted from SVN doesn't work
xalan 2.5.x/xerces 2.?.? doesn't work
xalan 2.6.1/xerces from xalan 2.6.1 bundle does prevent the error below 
but I then get similar NAMESPACE_ERR errors from within the layout 
engine test suite
xalan 2.7.0/xerces from xalan 2.7.0 bundle does work

All this evaluated under RH Enterprise ES 3 with Sun Java 5.0 latest
release.

Time to upgrade the xalan/xerces jars in SVN?

Manuel

 There was 1 error:
 1)
 testFO2PDFWithDOM(org.apache.fop.BasicDriverTestCase)javax.xml.transf
orm.TransformerException: org.w3c.dom.DOMException: NAMESPACE_ERR: An
 attempt is made to create or change an object in a way which is
 incorrect with regard to namespaces.
 at
 org.apache.xalan.transformer.TransformerIdentityImpl.transform(Transf
ormerIdentityImpl.java:511) at
 org.apache.fop.BasicDriverTestCase.loadDocument(BasicDriverTestCase.j
ava:62) at
 org.apache.fop.BasicDriverTestCase.testFO2PDFWithDOM(BasicDriverTestC
ase.java:78) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
 Method)
   
   Jeremias Maerki
  
  Simon Pepping
 
 Jeremias Maerki

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



Re: [Bug 36004] - [PATCH] Block content in inline content

2005-08-08 Thread Simon Pepping
On Mon, Aug 08, 2005 at 04:36:40PM +0200, [EMAIL PROTECTED] wrote:
 http://issues.apache.org/bugzilla/show_bug.cgi?id=36004
 
 --- Additional Comments From [EMAIL PROTECTED]  2005-08-08 16:36 ---
 Simon, thanks for your work on inlines and for setting up the branch. As you 
 will have seen, I've hacked around a little bit in the branch and I think 
 we're ready to merge the branch back into trunk. All necessary tests pass. 
 Would you please review? My KnuthElement/KnuthSequence mixture might be 
 subject to discussion but it allowed not adjusting some of the LMs and 
 creates 
 fewer objects that way. WDYT?

I do not have much time to look at it more closely until Friday or the
weekend. From what I saw by scanning the svn commit logs, my first
reaction is that it works, but it is not what I like. It makes the
code less clean and more complicated by allowing and checking for two
alternative allowed datastructures. My idea is that all InlineLevelLMs
return a list of KnuthSequences for getNextKnuthElements. Of course
you can move it back into the trunk. I can always work further on it
when it is there.

Regards, Simon

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



Re: More about build.xml

2005-08-14 Thread Simon Pepping
On Sun, Aug 14, 2005 at 07:43:36PM +0200, J.Pietschmann wrote:
 Jeremias Maerki wrote:
 I think the hyphenation patterns were supposed to be in the fop-hyph.jar
 which can be used or replaced by the one offered by OFFO. AFAIK, there's
 no need for a fop.xconf to be compiled into the fop.jar anymore with the
 Avalon, uhm, Excalibur-style configuration. I wonder how many people
 actually used the possibility to compile the configuration into the JAR
 file. This seems very unflexible to me.
 
 I see. It seems I killed the fop-hyph.jar target prematurely.
 Is the spin off of the serialized hyphenation patterns the
 start of a trend which will end with a fop-core.jar, fop-api.jar,
 fop-pdfrenderer.jar, fop-j2drenderer.jar, fop-awt-application.jar,
 fop-cli.jar, fop-anttask.jar and, of course, a fop-all.jar? :-)

In spring of this year it was proposed that all hyphenation patterns
be removed from fop and only be made available by OFFO. In fact, the
same old set is still in xml-fop/src/hyph.

Users could put their hyphenation patterns in xml-fop/hyph. The
hyphenation target uses this directory. If it is empty, no hyphenation
patterns will be compiled. The patterns in xml-fop/src/hyph are not
used.

hyphenation-jar collects the patterns in xml-fop/build/hyph in a separate
jar file, to preserve independence of fop.

In fact I offer ready made hyphenation jars in OFFO,
http://prdownloads.sourceforge.net/offo/offo-hyphenation-fop-HEAD.zip?download. 

Simon

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



Re: Assimilating PDF and PS output

2005-08-21 Thread Simon Pepping
On Sat, Aug 20, 2005 at 08:56:09PM +0200, Jeremias Maerki wrote:
 I'm currently working on the PS renderer and as part of that I tried to
 factor out more common code between the PDF and PS renderers. As a
 result of that I already have some of the more important features
 (borders and viewports) working locally. But this meant switching the PS
 renderer's own coordinate system from millipoints to points because PDF
 works in points. At the moment I'm looking at what this means for
 PSGraphics2D which still operates on millipoints. I think I should
 change that, too. I don't think this should have any negative effects on
 anybody, since the output will still look the same. Do I maybe miss

The layout system works with millipoints. Is this discrepancy between
areas and renderers not an endless source of errors and confusion?

Regards, Simon

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



Re: JAXG snapshot available (was: Re: API discussion (revived))

2005-08-25 Thread Simon Pepping
Jeremias,

It is a good package. I have a few remarks.

1. At some point I wanted it to be possible to set input and output
   types on the Factory. In that way it would be possible to write a
   factory implementation which knows about several of the processing
   engines, and depending on the input and output types (and some user
   configuration, at the discretion of the factory implementation)
   could choose the best engine, e.g. JFOR for fo to rtf, FOP head for
   fo to all other, Batik for SVG to other.

   But that would introduce input type dependence into the
   code. Currently the following code:

   XGProcessorFactory factory = XGProcessorFactory.newInstance();
   XGProcessor processor = factory.newXGProcessor();
   Source src = new StreamSource(new File(args[0]));
   XGResult res = new StreamXGResult(application/pdf, new File(args[1]));
   processor.process(src, res);

   together with the appropriate value of the system property can be
   used to process both FO and SVG, with the engine of choice by the
   invoker.

2. I am a bit suprised that you use a specific factory implementation
   in your examples, and not the engine agnostic newInstance
   method. This is counter to the goal of engine agnostic code.

   This made me think that perhaps another goal is more important:
   This is a framework that allows one to access each engine through
   the same interface. It does so by writing adapters between the
   defined interface and the engines.

   Viewed this way, the reference implementation is not just that. It
   is the essential part of your package, viz. the set of adapters.

3. The interface is not limited to XML Graphics applications. It is
   suitable for any engine that exposes a SAXResult interface, or can
   be made to expose such an interface by an adapter.

I hope these thoughts make sense.

Regards, Simon

On Mon, Aug 22, 2005 at 12:23:45PM +0200, Jeremias Maerki wrote:
 I've cleaned up JAXG and published it on my website:
 
 http://www.jeremias-maerki.ch/dev/jaxg/
 
 Comments are welcome.
 
 Jeremias Maerki
 

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



Build error

2005-09-05 Thread Simon Pepping
Hi,

I get a build error:

[javac] Compiling 653 source files to /fsb/fsc/source/xml-fop/build/classes
[javac] 
/fsb/fsc/source/xml-fop/src/java/org/apache/fop/render/ps/PSFontUtils.java:166: 
cannot resolve symbol
[javac] symbol  : method copy 
(org.apache.fop.util.SubInputStream,org.apache.fop.util.ASCIIHexOutputStream)
[javac] location: class org.apache.commons.io.IOUtils
[javac] IOUtils.copy(sin, hexOut);
[javac]^
[javac] 1 error

BUILD FAILED

How can I solve this?

Simon

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



Re: Logging for FOrayFont

2005-09-05 Thread Simon Pepping
On Mon, Sep 05, 2005 at 07:33:33PM +0200, Jeremias Maerki wrote:
 
 On 05.09.2005 17:05:48 Victor Mote wrote:
  Jeremias Maerki wrote:
  
  The design considerations are as follows:
  1. FOrayFont needs to be able to log messages.
 
 For whom? For the developer or for the end-user? Because that's what
 I've learned during the past months: That it should be well divided
 between the two audiences. The speciality is that the developer doesn't
 need a logger per processing run (i.e. non-static logging) and the
 end-user often needs more than just pure Strings through a generic
 logging interface. Note that this is not yet reality in FOP but I
 believe it will be soon.
 

   Now, I know this has the potential to spark a heated debate 
   again and it raises question marks about the FOrayFont 
   integration, but ATM I really don't know what to do about it 
   right now. I just realized we have a problem here. I/we made 
   promises on general@xmlgraphics.apache.org to try to remove 
   logging and other external dependencies (like Avalon) for the 
   common components because that's something which is very 
   important to the Batik side.
  
  So, then, how are those components supposed to log anything? Or, if they are
  to log using their own static stuff, how can this be configured by the
  client?
 
 Eventually such basic libraries shouldn't log anything anymore. That's
 the big dilemma I'm sitting in, the one I need to find a way out of.
 Anyway, ways to remove the necessity to log are: unit tests and
 stabilization. The problem is getting rid of something so extremely
 handy but actually completely unnecessary for something basic like a PDF
 or font library. But I'd never want to get rid of the ability to log in
 a complex system like a layout engine.

I am not sure that I understand everything that is being said
here. But I am alarmed when I hear that basic libraries, in this case
the FontServer, shouldn't log anymore. In my experience a font system
requires powerful logging, in order to expose runtime behaviour to the
systems manager or end user. Configuring font systems and
understanding why a piece of font software does not use it as you
expect, is a hard task that requires suitable runtime information from
the software.

Regards, Simon

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



Re: [VOTE] Manuel Mall as new FOP committer

2005-09-05 Thread Simon Pepping
+1 from me.

Regards, Simon

On Mon, Sep 05, 2005 at 10:29:36AM +0200, Jeremias Maerki wrote:
 Manuel Mall has been investing a tremendous amount of time and effort
 into making FOP better lately. The results were just great. It's been a
 pleasure to apply his patches, even though it ate up a lot of my time.
 ;-) Manuel has been around since at least late 2002, even submitted a
 patch back then. He shows a good understanding of how things work in our
 project and is quick to learn in other areas. He doesn't fear diving
 into the code of the layout engine. That's exactly the sort of people we
 need in the project team. That's why I'd like to nominate him for
 committership in Apache FOP.
 
 Jeremias Maerki
 

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



Re: Build error

2005-09-05 Thread Simon Pepping
On Mon, Sep 05, 2005 at 09:21:09PM +0200, Jeremias Maerki wrote:
 You can't, I can. My fault, sorry.
 http://svn.apache.org/viewcvs?rev=278816view=rev

Thanks, that works. Another error, in junit:

[junit] Testcase: 
testGenericPDFTranscoder(org.apache.fop.BasicPSTranscoderTestCase):   
Caused an ERROR
[junit] org/apache/fop/util/SubInputStream
[junit] java.lang.NoClassDefFoundError: org/apache/fop/util/SubInputStream

Indeed, fop-transcoder.jar and fop-transcoder-allinone.jar do not
contain Service and SubInputStream in the util package.

Simon

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



Re: Build error

2005-09-06 Thread Simon Pepping
On Mon, Sep 05, 2005 at 11:14:09PM +0200, Jeremias Maerki wrote:
 Weird, why does it want Service? I've added SubInputStream and all runs
 through.

Thanks. I do not mean that it requires Service. I mean that those two
classes are in util and not in the transcoder jars.

Simon

 On 05.09.2005 22:17:41 Simon Pepping wrote:
  On Mon, Sep 05, 2005 at 09:21:09PM +0200, Jeremias Maerki wrote:
   You can't, I can. My fault, sorry.
   http://svn.apache.org/viewcvs?rev=278816view=rev
  
  Thanks, that works. Another error, in junit:
  
  [junit] Testcase: 
  testGenericPDFTranscoder(org.apache.fop.BasicPSTranscoderTestCase):   
  Caused an ERROR
  [junit] org/apache/fop/util/SubInputStream
  [junit] java.lang.NoClassDefFoundError: 
  org/apache/fop/util/SubInputStream
  
  Indeed, fop-transcoder.jar and fop-transcoder-allinone.jar do not
  contain Service and SubInputStream in the util package.
  
  Simon
  
  -- 
  Simon Pepping
  home page: http://www.leverkruid.nl
 
 
 
 Jeremias Maerki
 

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



Re: Line LM, Inline LM and LAST_AREA

2005-09-06 Thread Simon Pepping
On Tue, Sep 06, 2005 at 12:46:19PM +0200, Luca Furini wrote:
 Manuel Mall wrote:
 
 I think there is a bit of ambiguity in the names: at the moment, the 
 LAST_AREA flag signals to a LM that it is adding the last inline area in a 
 line, or the last block area in a page, but this can cause confusion with 
 the is-last area trait described by the specs (4.2.2 Common traits). Maybe 
 we can find out a more significant and univocal name.

I think I have used it in the meaning of is-last trait, back in
January, before the page breaking algorithm was applied. I see that
BlockStackingLM now uses isFirst(Pos) and isLast(Pos). I am not sure
why this LM introduces the methods; every LM needs to be able to mark
its areas as first or last, is it not? Anyway, I have always felt that
this needed a review as it seemed to be implemented in a patchy
manner.

Regards, Simon

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



Re: Logging for FOrayFont

2005-09-06 Thread Simon Pepping
On Mon, Sep 05, 2005 at 09:35:26PM +0200, Jeremias Maerki wrote:
 As I said, widely differing views between Batik and FOP about this. In
 my own personal opinion, I'm with you. From the POV of XML Graphics
 Commons we have a problem. We've voted on the plan for Commons where we
 said that we'd try to remove the dependency on Commons Logging. If there
 is a problem with that, the right place to raise this is
 [EMAIL PROTECTED]

That means that those Commons components will have to define their own
interface to which they are willing to send logging events, just like
ForayFont does. FOP will have to implement all interfaces defined by
the libraries it uses. It should do so on top of a Commons Logger
instance, to preserve Commons Logging user configurability.

It would of course be easier if all components would use a standard
interface like Commons Logging. But that is not going to happen in
this world.

My remark about runtime information to debug a system configuration is
inspired by a TeX system, which needs to load many component files. I
realized that it uses a different method. Its resolver library does
indeed no logging. Instead, there is a stand-alone front end to it
that the user must run separately to obtain configuration debugging
information. For example, when in my LaTeX run class X is not loaded
as I expect, I use this app (kpsewhich) to find out where the resolver
library thinks the class X is. It also displays search path
information, and information about how the search path is constructed
from the configuration file and the built in path components.

Regards, Simon
 
 On 05.09.2005 21:15:50 Simon Pepping wrote:
 snip/
  I am not sure that I understand everything that is being said
  here. But I am alarmed when I hear that basic libraries, in this case
  the FontServer, shouldn't log anymore. In my experience a font system
  requires powerful logging, in order to expose runtime behaviour to the
  systems manager or end user. Configuring font systems and
  understanding why a piece of font software does not use it as you
  expect, is a hard task that requires suitable runtime information from
  the software.
 
 Jeremias Maerki
 

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



Re: More style issues

2005-09-10 Thread Simon Pepping
On Fri, Sep 09, 2005 at 08:38:18AM +0800, Manuel Mall wrote:
 On Fri, 9 Sep 2005 07:55 am, J.Pietschmann wrote:
  Hi devs,
  while examining the Checkstyle and JavaDoc complaints I
  got a few more questions about the FOP style:
  1. There is still quite a bit of hungarian notation here and
there. Hungarian notation generally sucks unless it is
consistently applied. Furthermore, it is systems hungarian
(see http://www.joelonsoftware.com/articles/Wrong.html),
which unconditionally sucks.
And yes, we do already have an int bFooFlag.
I'd like to exterminate this.
 
 +1 I am with you here - allthough I am guilty as well: If I find a class 
 written in hungarian style and I have to make a modification I will 
 sick with the style of the original author. What I dislike most is 
 mixing styles as this make code IMO very difficult to read.

Hmm, if I remember FOP code uses b and i for boolean and int, and I
have added to that usage. I do not have a problem with it. It may not
add information, but I like the fact that it carries type info with
it. It certainly does not bother me.
 
  2. There are two different styles for constructors and setters
in use:
  Constructor(int foo) {
this.foo=foo
  }
and
  Constructor(int f) {
foo=f
  }
We should standardize on one form. I'd like the first because
the second may have the undesirable effect of using unintuitive
abbreviations or alternative names for the parameter.
I told Checkstyle laready to accept the first form (there are
*lots* of warnings about it). Unfortunately, Checkstyle can't yet
enforce it.
 
 Doesn't worry me too much although I prefer the style you prefer as 
 well.

That is my position as well.
 
  3. We have too much weird abbreviations everywhere. In particular,
usage of abbreviations is wildly inconsistent. I'd like to
remind everyone that using proper words to compose identifiers
has advantages. With the autocompletion features of modern IDEs,
long identifiers shouldn't impair typing too much.
I'll probably expand randomly choosen names in the future, which
may include class names. Tell me now if you don't like this.
 
 
 That's a difficult one - I don't think there is a right or wrong here. 
 And yes consistency would be great (e.g. all layout manager classes 
 should be called ...LayoutManager and not some ...LM). I agree that 
 this is not really a typing issue but it is arguable at what length an 
 identifier actually gets in the way of readability, e.g. is 
 'lineStartBorderAndPaddingWidth' preferable to 'lineStartBAP' if that 
 variable is used a lot in expressions which are then split over multi 
 lines everywhere this variable is used?
 
 What about a WIKI page listing commonly used abbreviations found in the 
 code base?
 
 So +1 for consistent class names and +1 for consistent and considered 
 use of abbreviations but please don't ban them altogether.

I feel the same way.

Regards, Simon

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



Re: Classpath setup problem

2005-09-10 Thread Simon Pepping
On Tue, Sep 06, 2005 at 10:48:11PM +0200, J.Pietschmann wrote:
 Next question: I used to have old (maintenance branch) jars
 for FOP and Batik in the repository, which causes compilation
 problems. Therefore it might be a good idea to include only
 specific fles rather than *.jar in the classpath set. WDYT?

What do you mean with repository? xml-fop/lib?

Simon

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



Re: Space-resolution doesn't work

2005-09-10 Thread Simon Pepping
On Fri, Sep 09, 2005 at 02:04:08PM +0200, Luca Furini wrote:
 Luca Furini wrote:
 
 For example, if we have this LM tree
 
Outer BlockLM
  |
 +++
 |||
 BlockLM 1BlockLM 2BlockLM 3
  |
   +--+-+
   ||
   BlockLM ABlockLM B
 
 BlockLM1.getNextKnuthElements() would return to the outer BlockLM only the 
 elements representing its block content, without any space.
 
 In order to decide which elements it has to create, the outer BlockLM 
 could have some lines like:
 
 (currentChild = BlockLM 1
  nextChild = BlockLM 2)
 
 space1 = currentChild.getSpaceAfter();
 space2 = nextChild.getSpaceBefore();
 if (this.mustKeepTogether()
 || currentChild.mustKeepWithNext()  !nextChild.hasBreakBefore()
 || !currentChild.hasBreakAfter()  nextChild.mustKeepWithPrevious) {
 // there cannot be a break between the two children,
 createElementsForSpace(resolve(space1, space2, false, false));
 } else {
 // there can be a break between the children
 createElementsForSpace(resolve(space1, null, false, true),
resolve(null, space2, true, false),
resolve(space1, space2, false, false));
 }

This is a good idea. Each LM would invoke this whenever it steps from
one child to another. Only the top level LM would also invoke it for
its before and after edges.

I would think of a different treatment of the spaces (space specifiers):
List spaces = new List(currentChild.getSpacesAfter(),
  nextChild.getSpacesBefore());
createElementsForSpaces(spaces);

createElementsForSpaces would create a single glue and a single
penalty, because all space specifiers in a single block stacking
constraint need to be considered together to calculate the space
value. Resolution and creating elements go together, as a penalty must
be created to reflect the influence of a page break.

Regards, Simon

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



Re: Tables, Columns... : FOTree or Layout?

2005-09-10 Thread Simon Pepping
Andreas,

You are asking a lot of questions. To most I have no answer, but I
have one reservation.

On Sat, Sep 10, 2005 at 01:41:05AM +0200, Andreas L Delmelle wrote:
 The other ones I encountered so far: implicit columns (from cells in 
 first row), column-number and number-columns-repeated.
 
 Especially the second seems out of place in layout, since it is needed 
 by the (currently unimplemented) function from-table-column(). If the 
 column-numbering is deferred until layout, it seems to become all the 
 more difficult to provide an eventual implementation for this function. 
 The other two are closely related to this, since they are necessary to 
 get the column-numbers right.
 
 This kind of on-the-fly normalization of the tree structure has 
 advantages for layout in that the table-grid co-ordinates will be 
 readily available (no interpretation needed, just pick up the cells as 
 building-blocks and map them onto the grid without too much effort). 
 The only downside is that certain information is lost. The tree 
 structure won't be the structure as specified in the source document, 
 but will actually correspond to another structure that yields exactly 
 the same results.

This bothers me. It may hinder proper calculation of property value
inheritance, which follows the tree as given by the user. We do
property refinement on the tree; other than that it is a precise
reflection of the user's fo document. I am reluctant to change that. 

Regards, Simon

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



Re: Space-resolution doesn't work

2005-09-11 Thread Simon Pepping
On Sun, Sep 11, 2005 at 11:19:38AM +0200, Jeremias Maerki wrote:
 
 On 10.09.2005 21:54:56 Simon Pepping wrote:
  On Fri, Sep 09, 2005 at 02:04:08PM +0200, Luca Furini wrote:
   Luca Furini wrote:
   
   For example, if we have this LM tree
   
  Outer BlockLM
|
   +++
   |||
   BlockLM 1BlockLM 2BlockLM 3
|
 +--+-+
 ||
 BlockLM ABlockLM B
   
   BlockLM1.getNextKnuthElements() would return to the outer BlockLM only 
   the 
   elements representing its block content, without any space.
   
   In order to decide which elements it has to create, the outer BlockLM 
   could have some lines like:
   
   (currentChild = BlockLM 1
nextChild = BlockLM 2)
   
   space1 = currentChild.getSpaceAfter();
   space2 = nextChild.getSpaceBefore();
   if (this.mustKeepTogether()
   || currentChild.mustKeepWithNext()  !nextChild.hasBreakBefore()
   || !currentChild.hasBreakAfter()  nextChild.mustKeepWithPrevious) {
   // there cannot be a break between the two children,
   createElementsForSpace(resolve(space1, space2, false, false));
   } else {
   // there can be a break between the children
   createElementsForSpace(resolve(space1, null, false, true),
  resolve(null, space2, true, false),
  resolve(space1, space2, false, false));
   }
  
  This is a good idea. 
 
 I agree.
 
  Each LM would invoke this whenever it steps from
  one child to another. Only the top level LM would also invoke it for
  its before and after edges.
  
  I would think of a different treatment of the spaces (space specifiers):
  List spaces = new List(currentChild.getSpacesAfter(),
nextChild.getSpacesBefore());
  createElementsForSpaces(spaces);
 
 Good idea, too. I actually wondered how to implement Luca's suggestion
 and I ended up subclassing Knuth classes (in my mind for now) to hold
 the additional space specifier info, but this is a much cleaner approach
 even if a little more objects might be instantiated here. I'll try to
 document this on the Wiki once I'm through playing through my examples
 so I really understand every aspect of the topic.

An alternative procedure is this: Let each LM return spaces together
with the Knuth elements in getNextKnuthElements. At a higher level,
the returned list is scanned for consecutive lists of spaces, which
are then resolved. The advantage is that it fits in with the existing
getNextKnuthElements, and the LMs can calculate their spaces when they
are calculating their Knuth elements, like they do now.

Simon

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



Re: svn commit: r280872 - in /xmlgraphics/fop/trunk/test/layoutengine: disabled-testcases.txt testcases/block_padding_2.xml

2005-09-14 Thread Simon Pepping
On Wed, Sep 14, 2005 at 05:05:37PM +0200, Jeremias Maerki wrote:
 Can one of the Knuth specialist please review my element list in the new
 test case below? Thanks.

The element list seems OK to me. The first page also seems OK to
me. What is strange is that the first line on the second page has
vpos=190800, i.e. 6 below the end of the last line on page
1. Clearly 3 padding after and padding before are added. Is this
not a problem of the area part of the code?

 BTW, if you run this test, the output looks good, but add two or three
 additional lines and you'll see the problem in the output, too.

Regards, Simon

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



Re: baseline-shift and KnuthInlineBoxes

2005-09-16 Thread Simon Pepping
On Fri, Sep 16, 2005 at 09:42:01PM +0800, Manuel Mall wrote:
 On Fri, 16 Sep 2005 07:10 pm, Luca Furini wrote:
  Manuel Mall wrote:
 Would be really nice to get some wider variety of fonts to play with. 
 May be including some unusual scripts with strange baselines. Do we 
 need something like OFFO for fonts, i.e. a repository of open licensed 
 but incompatible with Apache license fonts already converted for use 
 with fop?

OFFO could easily host FOP-specific tables for such fonts. It could
also maintain a list of such fonts. I am not sure it should host such
fonts itself, but it could if there is a good reason.

Regards, Simon

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



Re: svn commit: r280872 - in /xmlgraphics/fop/trunk/test/layoutengine: disabled-testcases.txt testcases/block_padding_2.xml

2005-09-17 Thread Simon Pepping
I see my error; I did not realize the influence of the retained
padding.

This situation is very similar to tables with their headers and
footers. There needs to be a penalty equal to the widths of the
padding-after and padding-before below each block. A block equal to
the widths of the padding-after and padding-before comes at the end of
the block.

I do not have time to look up the details, as I am going away
for a few days.

Regards, Simon

On Thu, Sep 15, 2005 at 08:58:37AM +0200, Jeremias Maerki wrote:
 
 On 14.09.2005 22:44:07 Simon Pepping wrote:
  On Wed, Sep 14, 2005 at 05:05:37PM +0200, Jeremias Maerki wrote:
   Can one of the Knuth specialist please review my element list in the new
   test case below? Thanks.
  
  The element list seems OK to me. The first page also seems OK to
  me. What is strange is that the first line on the second page has
  vpos=190800, i.e. 6 below the end of the last line on page
  1. Clearly 3 padding after and padding before are added. Is this
  not a problem of the area part of the code?
 
 I didn't even look at the area tree, but you're right vpos is a bit
 strange, though I get 162000, not 190800. :-) But I wouldn't put too
 much weight on the vpos attribute since it simply writes out the
 currentBPPosition. I'm going to investigate that a little more. I
 believe we can't start talking about something wrong in the area part if
 the element list is wrong in the first place. Both parts need to be
 synchronized. That's why it's important not only to test the area tree
 but also the element lists. Otherwise, you get strange line or page
 breaking decisions and you don't know why.
 
 Thanks for the feedback!
 
 I realized with this bug that I need to take borders and padding from
 parent LMs into account when I'm trying to create the right element
 lists for spaces. Looks like we need a stack on the LayoutContext for
 non-conditional borders and paddings. ATM I believe we will end up
 extending the use of unresolved list elements which get resolved to
 normal Knuth elements prior to breaking. Otherwise, the code gets too
 complicated if the complex break possibilities (like
 pen-glue-box-PEN-glue) are becoming more common. I will write something
 up on the Wiki about that.
 
   BTW, if you run this test, the output looks good, but add two or three
   additional lines and you'll see the problem in the output, too.
  
  Regards, Simon
 
 
 Jeremias Maerki
 

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



Re: Funny side-effects from space-resolution

2005-09-29 Thread Simon Pepping
On Wed, Sep 28, 2005 at 10:48:11PM +0800, Manuel Mall wrote:
 Jeremias,
 
 looks OK to me although a bit strange but hey...that's the spec.
 
 On Wed, 28 Sep 2005 10:00 pm, Jeremias Maerki wrote:
  I've just stumbled over the testcase block_margin_inherit while
  fixing problems revealed by the test suite after having
  space-resolution work on blocks. Here's how it looks like:
 
  fo:flow flow-name=xsl-region-body
fo:block margin=5% background-color=yellow
  fo:block margin=inherit background-color=blue
 margin=inherit - should have the same margin as the
  enclosing block /fo:block
/fo:block
fo:blockYellow block has margin=5% - 18pt margin based
  on 5in page width/fo:block /fo:flow
 
  The 5% in this case evaluate to 18000mpt. margin, as a short-hand,
  results in space-before and space-after of 18000mpt each, and that
  for both blocks. In terms of 4.3.1 Space-resolution Rules, we have
  two sequences of space-specifiers due to stacking constraints. On the
  before edge, we have case 1 (under 4.2.5 Stacking Constraints), and
  on the after edge, we have case 2.
 
 Agree
 
  All space-specifiers are not conditional, because of 5.3.2 (last
  sentence in first paragraph). So, rule 1 in 4.3.1 does not suppress
  any space-specifiers. Rule 2 doesn't apply, either, since no
  space-specifier is forcing. Going on to rule 3 we have to collapse
  the two space-specifiers to one.
 
 Agree
 
  What's the effect? The test now fails because the space-resolution
  wasn't taken into account. Furthermore, the result looks funny due to
  the background colors. Both times it's the last space-specifier that
  survives (rule 3, second part) and I'm strictly taking the last by
  looking at the block-progression-direction here.
 
 Agree

I agree with your arguments. If I understand you correctly then this
implies that the resulting space-start is 18000mpt, blue, and the
space-end is 18000mpt, yellow. But I do not see that in the attached
pdf file, in which the space-start is yellow and the space-end is
blank.

Simon

 
  So this may be a somewhat unexpected result but I think it's correct.
  If anyone could verify that, I'd be grateful.
 
 Agree
 
  I'm attaching the PDF output of my local code.
 
  Jeremias Maerki
 Manuel

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



Space resolution implementation and break possibility building

2005-09-30 Thread Simon Pepping
Hi,

Some thoughts about the space resolution implementation notes.

I believe that borders and padding are not unresolvable elements. They
can always be determined by their LM because they do not interact with
the borders and padding of other LMs. They do influence space
resolution. They act as fences and break space sequences into several
separate stacking constraints. This can be taken into account by the
Space Resolver if the Knuth elements for the borders and padding make
it clear that they are a fence to stacking constraints.

And some (perhaps irrelevant) observations about break possibility
building.

The situation regarding retained borders and padding resembles the
situation of table headers and footers closely. Nevertheless, Jeremias
presents a Knuth element list which is simpler:

penalty(pb-after) glue(-pb-before) box PENALTY glue(pb-before)

According to the table header/footer treatment, the list would be:

penalty(pb-before + pb-after) at each break possibility, representing
the border and padding on the page before the break.

glue(pb-before + pb-after) at the end, representing the single
occurrence of the border and padding that occurs without any break.

This solution would be especially more complicated for borders and
paddings of nested blocks.

I am wondering why the element list for borders and paddings can be
constructed in a simpler way than that for table headers/footers. I
think it is due to the fact that glue can be undone, while boxes
cannot.

Regards, Simon

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



Re: Sponsorship

2005-09-30 Thread Simon Pepping
On Fri, Sep 30, 2005 at 08:27:45AM +0100, Peter B. West wrote:
 Jeremias Maerki wrote:
 On 29.09.2005 11:58:57 Peter B. West wrote:
 
 I can understand that some sponsors may be sensitive to divulging such 
 information, for at least two reasons. Firstly, the treat of being 
 inundated with begging letters, and secondly, the possibility that they 
 might be upsetting their own business partners.
 
 Before you took up the sponsorship offer, you mentioned to me that it 
 was on the cards, which I appreciated.  I assume you told others as 
 well. Targeted sponsorship is potentially extremely disruptive to a 
 group, and it seems to me that the process must be as open as possible. 
  If it can't be as open as the code, it should be nearly so.

Do you mean that such a sponsorship changes the relations within the
group? It certainly does. I feel that Jeremias has done an admirable
job in managing the relations within the group, and in balancing his
full time input in FOP with the more limited input of other group
members.

Regards, Simon

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



Re: The space resolution examples

2005-10-05 Thread Simon Pepping
On Wed, Oct 05, 2005 at 09:54:17AM +0200, Jeremias Maerki wrote:
 
 On 05.10.2005 09:07:36 Finn Bock wrote:
  So for inlines we get
  
  fo:blockxxx xx xxx xx xxx x xxx  fo:inline space-start=nniii i 
  iii iii ii iii  iii  i ii i ii/fo:inline xxx xxx  xxx 
   xxx xxx/fo:block
  
  xxx xx xxx xx xxx x
  xxx iii i
  iii iii ii iii
   iii  i
  ii i ii xxx
  xxx  xxx 
  xxx xxx
  
  where a retained space-start is applied to each inline area, not just 
  the first one generated?
 
 Unexpected for inlines maybe, yes, but not necessarily for the b-p-direction
 and it's what the spec says IMO.

I found this unexpected too. But I have realized that it is only true
if the conditionality is 'retain'. If it is 'discard', which is the
default, you only get the space where an inline area starts inside a
line, which is usually only the first area.

For block areas a similar situation exists. A space-before with the
default conditionality of 'discard' will generally only be present on
the first area, because almost always the other areas will start a
reference area. This is not true for a block inside another block
which has a fence. In general the parent block only has a fence for
its non-first areas if the border or padding has a conditionality of
'retain'.

In all cases the user has to do quite a lot to get a space-before on
non-first areas.

  My understanding is more in line with Simon.

I felt like I had missed something obvious. I feel better now. :-)
 
  I would guess that the key sentence is also true if the space is applied 
  to only the first area.
 
 How so? The spec talks about spaces around the generated areas of an FO,
 not the space around an FO. Or take the first sentence in 7.11.2:
 Specifies the minimum, optimum, and maximum values for the space before
 any areas generated by this formatting object and the conditionality and
 precedence of this space. I don't read any restriction to only the
 first and last generated area of an FO for spaces out of this.

The phrase 'before the areas generated by this formatting object' is
certainly not unambiguous. I read it as 'before all areas', i.e. only
once. Now I am not sure anymore. The other phrase, 'before any areas
generated by this formatting object' is clearer, although I have
trouble precisely understanding the meaning of the word 'any'. I
presume it means the same as 'before each area', but why doesn't the
spec use that unambiguous phrase?

Maybe this phrase in 4.2.2, 'Unless otherwise specified, the traits of
a formatting object are present on each of its generated areas, and
with the same value.', also indicates that the trait 'space-before' is
present with the same value on each area?

 Once again we probably hit a flaw in the spec. AltSoft repeats the
 space-before on every page, XEP does not. And no changes to the text in
 XSL 1.1 WD. :-(

I am glad to see that we are not the only ones who have a problem with
this part, but it is worrysome at the same time.
 
 I think we should start a Wiki page listing all these bloody flaws in
 the spec for everyone to see.

That is a good idea. As an extra benefit, the Wiki allows users to add
their interpretations.

Regards, Simon

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



hyphenation-present and junit-layout

2005-10-12 Thread Simon Pepping
I think junit-layout should fail if hyphenation-present is not
true. Now the layoutengine tests are silently skipped when hyphenation
is not present.

Simon

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



junit-transcoder classpath in build.xml

2005-10-14 Thread Simon Pepping
  target name=junit-transcoder depends=junit-compile description=Runs 
FOP's JUnit transcoder tests if=junit.present
...
  classpath
pathelement location=${build.dir}/test-classes/
path refid=libs-run-classpath/
fileset dir=${build.dir}
  include name=fop-transcoder.jar/
/fileset
  /classpath

Should the classpath not contain libs-build-classpath instead of
libs-run-classpath, so that fop.jar (and fop-hyph.jar) are not in it?

Simon

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



Re: hyphenation-present and junit-layout

2005-10-14 Thread Simon Pepping
On Fri, Oct 14, 2005 at 12:07:13AM +0200, Andreas L Delmelle wrote:
 On Oct 13, 2005, at 21:50, Simon Pepping wrote:
 
 But basically, why would anyone want to run regression tests without
 hyphenation present?
 
 Good point. I guess if there weren't any tests that don't require 
 hyphenation support, we wouldn't be having this conversation...
 Anyway, since we don't distribute any patterns with FOP anymore, 
 enforcing hyphenation to be present would mean that running the basic 
 layout regression test suite straight off the trunk code would always 
 result in failure of the whole target --which sounds a bit drastic.

We are talking about regression tests by developers. You cannot say
you have regression tested code if you have skipped a number of tests.

Regards, Simon

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



Re: hyphenation-present and junit-layout

2005-10-17 Thread Simon Pepping
On Sat, Oct 15, 2005 at 10:04:37AM +0200, Andreas L Delmelle wrote:
 I'm not following here... You will have regression tested code with 
 certain parts not being tested because the optional feature necessary 
 for running those tests smoothly isn't present.
 If presence of support for hyphenation (the respective patterns) is 
 left to the potential developer, then the testing cycle should take 
 into account that there is the possibility that hyphenation won't be 
 present, and thus skip those hyph-dependent tests with a big warning. 
 The tests won't *fail*. There just isn't enough info/resources 
 available to even perform them. (Failure only becomes applicable if 
 hyphenation is present, and the test can be run in a meaningful way.)

That is true indeed. The tests will not fail.

My focus is on the Ant target. I want an Ant target to run a
predefined set of tests. And if this set includes hyphenation
dependent tests, and the required hyphenation support is not
available, the Ant target has failed.

Simon

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



Re: svn commit: r320826 - /xmlgraphics/fop/branches/Temp_SpaceResolution/

2005-10-17 Thread Simon Pepping
On Thu, Oct 13, 2005 at 08:23:50PM +0200, Jeremias Maerki wrote:
 I finally uploaded my space resolution work so far. It's still not
 finished. When you go through the details you always find more stuff to
 look into and to fix. But most of it works now and is available for
 review while I work on the remaining issues. I assume there is room for
 optimization here and there. So don't hesitate to jump in and help. The
 enabled test cases all pass.
 
 What I forgot to include in the commit message: I changed from empty
 block areas to space-before and space-after traits! This caused a lot of
 changed checks in the test cases. That was a project on its own. :-) But
 the area trees are much clearer now.

That is a lot of code. The result looks very robust.

The following case seems to present a problem:

 ...
  /fo:block
  fo:block/
  fo:block space-before=10pt background-color=#B5
 ...

The empty block seems to split the stacking constraint into two
constraints, one containing the space-after of the preceding block,
and another containing the space-before of the following block. IMHO,
this should be a single stacking constraint, case 3d in the spec.,
section 4.2.5, Stacking Constraints.

When the empty block has space-before and/or space-after, it results
even in a rule in the output.

Regards, Simon

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



Re: Space resolution - ready for merge

2005-10-20 Thread Simon Pepping
On Wed, Oct 19, 2005 at 03:13:53PM +0200, Jeremias Maerki wrote:
 I'm comfortable now with the space resolution code. If it's ok for
 everybody, I'd like to merge the space resolution branch into Trunk.
 I've documented the open issues I know. All these issues have a
 (disabled) test case to demonstrate the problem. The only thing that I
 will probably do right now is clean up a few LM since I've only
 commented older code passages dealing with spaces.

I agree that the code is ready to be merged into the trunk.

Simon

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



Re: alignment-baseline and aligment-adjust properties

2005-10-21 Thread Simon Pepping
On Fri, Oct 21, 2005 at 08:28:42AM +0800, Manuel Mall wrote:
 
 See the response at
 http://lists.w3.org/Archives/Public/xsl-editors/2005OctDec/0006.html.
 
 We have taken the opposite approach and added the property values to the
 property defintions.
 
 We could now:
 
 a) just remove them
or
 b) leave the values in and issue a warning when used
 
 Given that FOP 0.20.5 doesn't support this at all and it is therefore
 unlikely we would be breaking anything for users moving from FOP 0.20.5 to
 FOP trunk if we go for option a) I would recommend to apply the KISS
 principle in this case and just remove them.

+1 for this proposal.

Simon

 
 Manuel

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



Re: Simplifying the configuration file

2005-10-24 Thread Simon Pepping
It is a matter of taste if one uses base url=.// or
base.//base. Either is OK with me, but I do not like seeing it
going backward and forward. Anyway, I suggest
base-url.//base-url.

Giving the resolution in dpi is much better.

Simon

On Mon, Oct 24, 2005 at 04:10:46PM +0200, Jeremias Maerki wrote:
 I'm currently documenting the new configuration layout. I must say it
 feels a little awkward right now. Does anybody mind if I simplify it a
 little in the following way?
 
 Old:
 fop version=1.0
 
   base url=.//
   !-- pixel to millimeter to specify dpi, 72dpi --
   pixelToMillimeter value=0.3528/
   pagesettings
   !-- default page-height and page-width, in case
value is specified as auto --
 pageHeight value=11in/
 pageWidth value=8.26in/
   /pagesettings
 
 New:
 fop version=1.0
 
   !-- Base URL for resolving relative URLs --
   base.//base
   !-- Internal resolution in dpi (dots per pixel), default: 72dpi --
   resolution72/resolution
   !-- default page-height and page-width, in case
value is specified as auto --
   default-page-settings height=11in width=8.26in/
 
 
 I think no mortal prefers pixelToMillimeter over a resolution value in
 dpi. The value can easily converted to pixelToMillimeter internally.
 
 Jeremias Maerki
 

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



Re: White space handling Wiki page

2005-10-25 Thread Simon Pepping
Hi Manuel,

On Tue, Oct 25, 2005 at 04:57:41PM +0800, Manuel Mall wrote:
 Hi,
 
 I haven't got any technical comments to the issues raised on the Wiki 
 page. Is this 'too hard' or 'too boring' or 'too messy' or what? The 
 problem is not going away. We currently don't do it right in some parts 
 (that is established) but I don't know overall what is right or wrong. 
 May be if I ask for comments on an issue by issue basis we get 
 somewhere?

You and Jeremias both turning in so much work is too much to follow. I
really would like to comment on your analysis, but I do not right now
have time for it. Perhaps in one of the next weeks.

Simon

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



Position and order of pendingaftermarks

2005-10-27 Thread Simon Pepping
Jeremias,

In the SpaceResolver constructor the pendingaftermarks are added to
the start of first:

first.addAll(0, breakPoss.getPendingAfterMarks());

I think they should be added to the end. Also I think the order of the
pendingaftermarks in BreakElement is wrong, or they should be added to
first in reverse order.

This is a test case:

fo:block space-after=10pt space-before=10pt
  background-color=#55
  fo:block space-after=7pt space-before=7pt
background-color=#55
fo:block space-after=5pt background-color=#656565
  Some text.
/fo:block
fo:block space-before=4pt background-color=#757575
  Some text.
/fo:block
  /fo:block
/fo:block

Regards, Simon

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



Re: fop.sh vs fop

2005-10-29 Thread Simon Pepping
On Sat, Oct 29, 2005 at 05:12:11PM +0800, Manuel Mall wrote:
 This has been done now.
 
 In the process I updated the fop script to match the latest ant script. 
 I would appreciate if other committers working on *nixes could test the 
 new script in their environments and fix or report any problems.

Committed a few small changes. Otherwise it works OK for me.

Simon

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



Re: Leading/trailing space removal in LineLM

2005-11-01 Thread Simon Pepping
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.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.

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 of
white-space-collapse. If there is whitespace that may not be
removed/collapsed at the start of the line, it must be protected by a
preceding zero-width box. I.o.w., the value of white-space-collapse
needs to be taken into account at the phase of getNextKnuthElements.

Simon

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



Re: Unicode compliant Line Breaking

2005-11-01 Thread Simon Pepping
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 closer look at both UAX#14 and Joerg's code. Because I 
 liked what I saw I went about adapting Joerg's code it to Unicode 4.1 
 and added fairly extensive JUnit test cases to it mainly because it 
 really helps to go through the various different cases mentioned in the 
 spec in some structured fashion.

Is our current hyphenation method a subset of Unicode's method?

 Assuming now that this will be agreed as well the next step would be the 
 more detailed design of the integration. But this is well beyond the 
 scope of this e-mail as there are some tricky issues involved and they 
 probably need to be tackled in conjunction with the white space 
 handling issues. Many of the problems are related to our LayoutManager 
 structures which create barriers when it comes to the need to process 
 character sequences across those boundaries as is the case for both 
 line breaking and white space handling. Add to that the design of the 

I seem to recall that the hyphenation code collects words across LM
boundaries.

It seems a useful goal to implement Unicode hyphenation. But since it
is a major effort, it does not fit in working towards a release. In
any case it would have to be in a separate branch until it proves to
work and to implement a substantial part of hyphenation. Then it does
not immediately matter if it is a separate project or a part of FOP.

Simon

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



Re: Unicode compliant Line Breaking

2005-11-02 Thread Simon Pepping
On Tue, Nov 01, 2005 at 11:17:08PM +0100, J.Pietschmann wrote:
 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 mean, will our current method of finding possible line breaking
points using the hyphenation tables be part of a TR14 compliant system
to find line break opportunities?

Simon

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



Re: Leading/trailing space removal in LineLM

2005-11-02 Thread Simon Pepping
On Wed, Nov 02, 2005 at 04:58:09PM +0100, 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! :-)

It is in the quoted-printable format, probably due to non-ascii
or non-latin-1 characters in it, the TR14 symbols. 

Simon

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



Re: svn commit: r332007 - /xmlgraphics/fop/trunk/test/fotree/testcases/no_namespace_prefix.fo

2005-11-09 Thread Simon Pepping
On Wed, Nov 09, 2005 at 08:58:24AM -, [EMAIL PROTECTED] wrote:
 Author: jeremias
 Date: Wed Nov  9 00:58:20 2005
 New Revision: 332007
 
 URL: http://svn.apache.org/viewcvs?rev=332007view=rev
 Log:
 Test to check FO tree building when no namespace prefix is used.

Why is this necessary? Doesn't the parser resolve the prefix and then
hide it from FOP?

Simon 

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



Re: White space handling Wiki page

2005-11-09 Thread Simon Pepping
On Tue, Nov 08, 2005 at 11:19:15AM +0800, Manuel Mall wrote:
 On Tue, 8 Nov 2005 04:40 am, Simon Pepping wrote:
 
  Step 2. Refinement: white-space-collapse
  
 
  Issue 1. The spec intentionally addresses only XML white space,
  because only such white space is manipulated by editors to obtain
  pretty printing.
 
 Point taken, although I have no experience with non western editors. Do 
 they all use 0x20 for 'pretty printing'?

The XML spec does not allow one to use other characters than XML white
space for pretty printing, at least not in element content. It would
result in an invalid XML file because PCDATA would be present where
the DTD or schema does not allow it. That is even true for
non-breaking-space, U+A0.

   ul
   liSome text./li
   /ul

is valid XHTML, but

   ul
#xA0;#xA0;#xA0;#xA0;liSome text./li
   /ul

is not.

In PCDATA it is slightly different.

   p
  This is some content.
  We wrap the lines at
  a narrow width.
   /p

Formally these data are different from the case when the text of the
paragraph were written in one line: spaces have been converted to
linefeeds, and sequences of spaces have been inserted. The XML parser
reports all linefeeds and spaces as character data to the
application. But almost all applications treat the two cases as
equivalent, certainly when the data are considered as textual data. It
is exactly this convention that the FO spec tries to formalize.

   fo:block
  This is some content.
  We wrap the lines at
  a narrow width.
   /fo:block

_is_ equivalent to the case when the text of the block were written in
one line, due to the line-feed-treatment and white-space-collapse
properties (at default values).

Such a convention is not usually applied to non-XML-whitespace
characters, and the FO spec shows no intention to do so.

A side effect is that 'This is some content' is equivalent to
'This  is   some  content', but that is not the case with any
other character, even if that is considered as white space in
some script.

  Example 2
  =
 
  The space in fo:block.fo:block is suppressed because it is at
  the start of the block. 
 Interesting - I agree that this is the intention but you don't find that 
 sentence in the spec. In 1.1 this is covered by the deleting spaces at 
 the beginning of a line under white-space-treatment / line building. 
 Again the discussion is probably academic - we all agree what the 
 expected outcome is. If we can derive that outcome from the spec or not 
 is a very interesting discussion but won't change what we will do.

This is convered under the notion that the start and end of an fo:block are
equivalent to line breaks.

  And fo:blockfo:block does not generate 
  an empty line. fo:block starts a new line, but that is not
  equivalent to a linefeed. When at the start of the nested fo:block
  there is no content in the line yet, it starts the same line. A
  similar thing happens in the case of /fo:block#x0A;/fo:block,
  which was discussed in an email thread.
 I assume you mean the discussion under linefeed-treatment=preserve. I 
 am still confused about that because
 /fo:block#x0A;#x0A;/fo:block 
 will generate one linefeed or should this create also none?

Yes, I am referring to that discussion, and I quoted it
wrong. The case is: #x0A;/fo:block. The linefeed creates a
linebreak, /fo:block does not add another one since the line has
already been ended. /fo:block#x0A;/fo:block should create one
empty line, and /fo:block#x0A;#x0A;/fo:block two empty lines, I
suppose.

  Nowhere in the spec is a conversion of tabs and CRs to spaces
  specified.
 Under 7.15.8 it says:
 
 preserve
 
 Specifies that any character flow object whose character is 
 classified, before any linefeed-treatment handling is considered, as 
 white space in XML, except for U+000A (linefeed) characters, shall be 
 converted during the refinement process into a character flow object 
 whose Unicode code point is U+0020 (space).

But they removed it in 7.16.8 in the 1.1 draft.

Regards, Simon

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



Re: Sandbox created

2005-11-11 Thread Simon Pepping
On Fri, Nov 11, 2005 at 04:13:18PM +0100, Andreas L Delmelle wrote:
 On Nov 11, 2005, at 16:04, Jeremias Maerki wrote:
 
 Ok, the sandbox is created and the PCL, SVG and MIF support moved  
 there.
 Would someone on Unix please verify that the fop script picks up the
 new fop-sandbox.jar and that the three renderers in there are  
 recognized?
 
 FYI: ran a test for PCL and SVG output on OS X, and encountered no  
 problems whatsoever, so seems to be fine.

The script works OK on Debian GNU/Linux. 

Regards, Simon

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



block children of inlines fixed?

2005-11-15 Thread Simon Pepping
On the Wiki, ReleasePlanning:

  fo:inline - Does not support block-level objects as children (isn't that 
fixed?)

Mostly, but perhaps not completely. I seem to recall that Finn
reported an Exception related to a LM not recognizing the double list
structure of Knuth elements returned by some inline level LMs.

Simon

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



Re: Exceptions

2005-11-15 Thread Simon Pepping
Today, 15 November 2005, revision 344223 only gives an exception on
the first test file.

Simon

On Thu, Sep 01, 2005 at 02:45:30PM +0200, Finn Bock wrote:
 Hi
 
 Running the NIST test suite I get 2 table related exceptions and 1 
 KnuthElement related exception:
 
 
 java.lang.NullPointerException
 org.apache.fop.layoutmgr.table.GridUnit.resolveBorder(GridUnit.java:246)
 org.apache.fop.layoutmgr.table.GridUnit.resolveBorder(GridUnit.java:230)
 org.apache.fop.layoutmgr.table.TableRowIterator.resolveStartEndBorders(TableRowIterator.java:480)
 org.apache.fop.layoutmgr.table.TableRowIterator.buildGridRow(TableRowIterator.java:419)
 org.apache.fop.layoutmgr.table.TableRowIterator.prefetchNext(TableRowIterator.java:294)
 
 ?xml version=1.0 encoding=UTF-8?
 fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format;
 fo:layout-master-set
 fo:simple-page-master master-name=test-page-master 
 margin-right=1.0in margin-bottom=1.0in margin-top=0.2in 
 margin-left=1.0in page-width=8.5in page-height=11in
 fo:region-body margin-bottom=1.0in margin-right=1.0in 
 margin-top=0.2in margin-left=1.0in/
 /fo:simple-page-master
 /fo:layout-master-set
 fo:page-sequence master-reference=test-page-master
 fo:flow flow-name=xsl-region-body
 fo:block space-after.optimum=0.4in space-after.maximum=0.4in
This test evaluates the border-before-color property on a 
 table-body FO. The border-before-color property (see red border) for 
 the next table-body FO was set to red.
   /fo:block
 fo:table border-collapse=collapse-with-precedence
 fo:table-body border-before-style=solid border-before-color=red
 fo:table-row
 fo:table-cell
 fo:block
The border above should be red.
   /fo:block
 /fo:table-cell
 /fo:table-row
 /fo:table-body
 /fo:table
 /fo:flow
 /fo:page-sequence
 /fo:root

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



URL of FOP trunk web pages

2005-11-15 Thread Simon Pepping
The wiki page ReleasePlanFirstPR says

Copy xdocs/trunk to xdocs/0.90alpha1 to create the release
documentation when it's good enough.

That is very unstable. Wouldn't xdocs/0.90 be good? I need to create a
reference to the hyphenation pages in OFFO.

Simon

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



Re: fo:marker and white space

2005-11-16 Thread Simon Pepping
On Wed, Nov 16, 2005 at 08:15:47AM +0800, Manuel Mall wrote:
 I have no problems with the suggestion to move the white space handling 
 from Block into its own class so other fo's that need it can make use 
 of it.
 
 However, I still need to be convinced that pushing it down to inline 
 level is actually of benefit. I am afraid we will end up with the same 
 problem we now have at LM level, that is text for a paragraph needs to 
 be analysed across fo boundaries and the current LM structures are very 
 much in the way of doing that. Whitespace needs to be handled across fo 
 boundaries as well. The current iterator structure was designed to 
 exactly facilitate that. It seems to be doing it well and I see no 
 reason to replace it.

linefeed-treatment is a local operation on a single character.

white-space-collapse does not cross FO boundaries because the spec
limits this to sibling character FOs.

Only white-space-treatment extends beyond FO boundaries, but its
treatment in handleWhitespace is only the first stage. At line
building it needs to be revisited.

That means that theoretically handleWhitespace can be done within each
FO. But practically it may be better to wait until we have settled
ideas about this stage, scanning for linebreak opportunities and
gathering of Knuth elements.

Simon

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



Re: [VOTE] Release FOP Trunk as FOP 0.90alpha1

2005-11-16 Thread Simon Pepping
+1

Simon

On Tue, Nov 15, 2005 at 09:14:12PM +0100, Jeremias Maerki wrote:
 This is it. Just to make it clear again: This is a a release vote and
 therefore a PMC vote, but every FOP committer is invited to place his
 vote or raise any objections. Noone gets ignored. Although fop-dev is in
 the CC, please place your votes on [EMAIL PROTECTED]
 
 Even though I haven't fully finished all of the documentation, yet, I'd
 like to start the vote. I'll have everthing finished by tomorrow evening
 (CET). I don't intend to do any more code changes, only the last
 documentation updates.
 http://wiki.apache.org/xmlgraphics-fop/ReleasePlanFirstPR shows the
 release plan and the status of the proceedings.
 
 I know of no legal problems needing attention. The external dependencies
 are well documented and every JAR in the lib directory is accompanied by
 its license. Hyphenation files have been removed. The unknown origin of
 some long-existing example FO files is not a problem IMO.
 
 0.90alpha1 will carry a big warning sign in the README file that the
 software is a preview release and should not be used in production
 unless thoroughly tested for the target environment. It is intended to
 let everybody know that FOP is back in business and to produce feedback
 on our new piece of software from users that don't (or can't) download
 the code from SVN.
 
 I'd like to propose to release FOP SVN Trunk as version 0.90alpha1.
 
 +1 from me, obviously.
 
 Jeremias Maerki
 
 
 -
 Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

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



Completeness of fop-0.90alpha1-src

2005-11-18 Thread Simon Pepping
I compared a newly built fop-0.90alpha1-src.zip with my source
directory from the repository. The following files are not in the
distribution zip file, while I think they should:

fop-0.90alpha1/KEYS
fop-0.90alpha1/lib/xalan.BCEL.LICENSE.txt
fop-0.90alpha1/lib/xalan.LICENSE.txt
fop-0.90alpha1/lib/xalan.NOTICE.txt
fop-0.90alpha1/lib/xalan.regexp.LICENSE.txt
fop-0.90alpha1/lib/xalan.runtime.LICENSE.txt
fop-0.90alpha1/status.xml

Simon

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



Re: Issues with layout engine test framework

2005-11-18 Thread Simon Pepping
On Fri, Nov 18, 2005 at 09:39:03PM +0100, J.Pietschmann wrote:
 Hi,
 a few thoughts about the layout engine test harness:
 - It won't run if CWD!=project.home, i.e. ant -find build.xml from a
 subdirectory fails the tests with a file not found exception.
 Neither the disabled testcase file nor any of the style sheets are
 found. This can be quite annoying with some IDEs.

Indeed, it annoyed me yesterday evening. It would be good if we would
reestablish independence of the current working directory by passing
the base directory to the code.

 BTW. Ant 1.6.1 complains: build.xml:808: The fail type doesn't
 support the nested condition element.
 Do we really need a bleeding edge ant? (although the Ant people could
 be a bit less aggressive with adding features in minor releases too).

The else attribute of the condition element (line 1046) requires Ant
1.6.3. Well, I upgraded.

Simon

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



Re: svn commit: r345335 - /xmlgraphics/fop/trunk/src/documentation/content/xdocs/compliance.ihtml

2005-11-19 Thread Simon Pepping
On Fri, Nov 18, 2005 at 10:20:09PM +0100, Jeremias Maerki wrote:
 A matter of definition, I guess. :-) Maybe we should really write
 [0.90alpha1] instead of [Latest] then. Care to do that? Or what do you
 prefer?

When I visit a site with software, I expect the name latest to point
to the latest stable distribution. The latest unstable distribution
could be named something like development, unstable, testing or next.

The file latest/.htaccess points to fop/0.20.5, and I think that is
best.

Simon

 On 18.11.2005 21:43:18 Simon Pepping wrote:
  Wouldn't latest point to the stable distribution, 0.20.5?
  
  Simon
  
  On Thu, Nov 17, 2005 at 09:45:59PM -, [EMAIL PROTECTED] wrote:
   Author: jeremias
   Date: Thu Nov 17 13:45:55 2005
   New Revision: 345335
   
   URL: http://svn.apache.org/viewcvs?rev=345335view=rev
   Log:
   Changed Trunk to Latest Release/[Latest]
   
   Modified:
   xmlgraphics/fop/trunk/src/documentation/content/xdocs/compliance.ihtml

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



Re: latest and other symbolic names [was: svn commit: r345335 - /xmlgraphics/fop/trunk/src/documentation/content/xdocs/compliance.ihtml]

2005-11-19 Thread Simon Pepping
I had a look at some other Apache projects:

cocoon: latest
excalibur:  current
jakarta-struts: current
lucene: current
jakarta-regexp: current
james:  current
logging/log4j:  latest=1.2.12, unstable=1.3alpha7
rivet:  current
tomcat: 5.0.30beta = link to 5.0.30
ws-jaxme:   current

I propose the following:

unstable is a link to 0.90
0.90alpha1 is a link to 0.90
current is a link to 0.20.5

The links appear as directory names on the distribution servers and on
the web site, as Unix soft links or as empty directories with
redirection.

Simon

On Sat, Nov 19, 2005 at 05:00:01PM +0100, Simon Pepping wrote:
 On Fri, Nov 18, 2005 at 10:20:09PM +0100, Jeremias Maerki wrote:
  A matter of definition, I guess. :-) Maybe we should really write
  [0.90alpha1] instead of [Latest] then. Care to do that? Or what do you
  prefer?
 
 When I visit a site with software, I expect the name latest to point
 to the latest stable distribution. The latest unstable distribution
 could be named something like development, unstable, testing or next.
 
 The file latest/.htaccess points to fop/0.20.5, and I think that is
 best.
 
 Simon
 
  On 18.11.2005 21:43:18 Simon Pepping wrote:
   Wouldn't latest point to the stable distribution, 0.20.5?
   
   Simon
   
   On Thu, Nov 17, 2005 at 09:45:59PM -, [EMAIL PROTECTED] wrote:
Author: jeremias
Date: Thu Nov 17 13:45:55 2005
New Revision: 345335

URL: http://svn.apache.org/viewcvs?rev=345335view=rev
Log:
Changed Trunk to Latest Release/[Latest]

Modified:

xmlgraphics/fop/trunk/src/documentation/content/xdocs/compliance.ihtml
 
 -- 
 Simon Pepping
 home page: http://www.leverkruid.nl

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



Re: latest and other symbolic names

2005-11-19 Thread Simon Pepping
I should have browsed a bit further. fop and batik already use
current, as do several other projects in the xml subdirectory.

Simon

On Sat, Nov 19, 2005 at 08:09:49PM +0100, Simon Pepping wrote:
 I had a look at some other Apache projects:
 
 cocoon:   latest
 excalibur:current
 jakarta-struts: current
 lucene:   current
 jakarta-regexp: current
 james:current
 logging/log4j:latest=1.2.12, unstable=1.3alpha7
 rivet:current
 tomcat:   5.0.30beta = link to 5.0.30
 ws-jaxme: current
 
 I propose the following:
 
 unstable is a link to 0.90
 0.90alpha1 is a link to 0.90
 current is a link to 0.20.5
 
 The links appear as directory names on the distribution servers and on
 the web site, as Unix soft links or as empty directories with
 redirection.
 
 Simon

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



Re: latest and other symbolic names

2005-11-20 Thread Simon Pepping
On Sun, Nov 20, 2005 at 10:57:37AM +0100, Christian Geisert wrote:
 Simon Pepping schrieb:
 I had a look at some other Apache projects:
 
 cocoon:  latest
 excalibur:   current
 jakarta-struts: current
 lucene:  current
 jakarta-regexp: current
 james:   current
 logging/log4j:   latest=1.2.12, unstable=1.3alpha7
 rivet:   current
 tomcat:  5.0.30beta = link to 5.0.30
 ws-jaxme:current
 
 I propose the following:
 
 unstable is a link to 0.90
 0.90alpha1 is a link to 0.90
 current is a link to 0.20.5
 
 Are you talking about the documentation or the download directory now?

In principle, both. These names could certainly be applied to the
download directory, and we could use them also in the documentation.

It is a bit debian-like. Everything has a real name and a symbolic
name (more a role name).

Simon

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



Re: Release

2005-11-22 Thread Simon Pepping
OK, except that I could not verify your signature:

gpg --verify fop-0.90alpha1-src.tar.gz.asc fop-0.90alpha1-src.tar.gz
gpg: Signature made Mon 21 Nov 2005 23:05:36 CET using DSA key ID 8408F755
gpg: BAD signature from Christian Geisert [EMAIL PROTECTED]

gpg --verify fop-0.90alpha1-bin-jdk1.4.tar.gz.asc 
fop-0.90alpha1-bin-jdk1.4.tar.gz.asc 
gpg: Signature made Mon 21 Nov 2005 23:05:12 CET using DSA key ID 8408F755
gpg: BAD signature from Christian Geisert [EMAIL PROTECTED]

Simon

On Mon, Nov 21, 2005 at 10:36:13PM +0100, Christian Geisert wrote:
 Hi,
 
 as you've probably noticed I've tagged the 0.90alpha1 release.
 It would be nice if someone else could have a look at the builds
 (available at http://people.apache.org/~chrisg/fop-0.90alpha1-test/)
 for a quick test.
 
 If no showstoppers are reported within the next hours I'll move this to
 the distribution area (and wait 24 hours for the mirrors to catch up).
 
 Christian
 

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



Re: [ANNOUNCEMENT] Apache FOP 0.90 alpha 1 released

2005-11-23 Thread Simon Pepping
On Wed, Nov 23, 2005 at 12:23:34AM +0100, Jeremias Maerki wrote:
 The Apache FOP team is excited to announce the release of Apache FOP
 0.90 alpha 1, the first preview release after over three years of
 redesign and after two and a half years without a new release.

Hoera, Hurray, Hurra, etc.

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



Re: Version numbers

2005-11-26 Thread Simon Pepping
On Fri, Nov 25, 2005 at 11:53:41AM +0100, Christian Geisert wrote:
 Jeremias Maerki schrieb:
  Not necessarily. We've called it 0.90alpha1. I'd assume we'd have a
  0.90beta or directly a 0.90 (final) first. But I guess that's open for
 
 I thought we do it like 0.91alpha2, ... 0.93 beta ... 1.0
 
  discussion. I don't care too much about it.
 
 What do others think?

Upping two different numbers at the same time is not logical. I go
with Jeremias' idea, but I do not care too much either.

Simon

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



Re: Version numbers

2005-11-27 Thread Simon Pepping
On Sat, Nov 26, 2005 at 01:41:23PM +0100, Simon Pepping wrote:
 On Fri, Nov 25, 2005 at 11:53:41AM +0100, Christian Geisert wrote:
  Jeremias Maerki schrieb:
   Not necessarily. We've called it 0.90alpha1. I'd assume we'd have a
   0.90beta or directly a 0.90 (final) first. But I guess that's open for
  
  I thought we do it like 0.91alpha2, ... 0.93 beta ... 1.0
  
   discussion. I don't care too much about it.
  
  What do others think?

I see now better what Christian means: number the releases 0.91, 0.92
etc. and append an indicator of our judgment of quality. That would
make 0.91alpha, 0.92beta etc., and it makes sense to me.

Simon

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



Using Docbook stylesheets in FOP (was: Re: ToUnicode table for CID embedded fonts patch available)

2005-12-04 Thread Simon Pepping
(Cross-posting to fop-user)

On Fri, Dec 02, 2005 at 01:58:39PM +0100, Jeremias Maerki wrote:
 
 On 02.12.2005 13:39:53 Adam Strzelecki wrote:
  Hello Jeremias,
  
  3) Last thing I would really appreciate is I would love to generate PDF
  directly from XML files using stylesheets but FOP XSLT routine is
  somehow broken so I need to do the conversion with XSLTPROC which does
  it without the problem.
  
  This is the error when I use FOP with:
  fop -xml myfile.xml -xsl docbook/fo/docbook.xsl -pdf myfile.pdf
  
  Compiler warnings:
file:/c:/Program%20Files/fop/docbook/fo/formal.xsl: line 433:
  Attribute 'border-left-style' outside of element.
file:/c:/Program%20Files/fop/docbook/fo/formal.xsl: line 434:
  Attribute 'border-right-style' outside of element.
file:/c:/Program%20Files/fop/docbook/fo/formal.xsl: line 435:
  Attribute 'border-top-style' outside of element.
file:/c:/Program%20Files/fop/docbook/fo/formal.xsl: line 436:
  Attribute 'border-bottom-style' outside of element.
  ERROR:  'Syntax error in '* or $generate.index != 0'.'
  FATAL ERROR:  'Could not compile stylesheet'
  Exception
  javax.xml.transform.TransformerConfigurationException: Could not compile
  stylesheet
  
  Problem is in the XSL file of DocBook XLS 1.69.1 sheets:
  docbook/fo/autotoc.xsl
 
 Sounds more like a problem in either the stylesheet itself or in Xalan
 which FOP calls for doing XSLT. Maybe I should finally install DocBook
 on my machine. :-)

It is indeed not really a FOP issue.

The docbook stylesheets seem to be a pain for most XSLT
processors. Restricting myself to Java XSLT processors, I
have only been successful with Saxon6. Xalan and the Xalan processor
built into Java 5 cannot compile the docbook/fo stylesheets.

This can be achieved by putting saxon.jar first in the classpath. It
must come before xalan.jar, in order to configure the Transformer
factory to use Saxon. Unfortunately, this is not possible with the
current fop shell script, because it puts the CLASSPATH variable at
the end of the class path. (Sometimes this is what you want, here
it is not.) The fop.bat batch file ignores the CLASSPATH variable
completely.

Another issue I have with FOP and Docbook is that FOP out of the box
does not use catalogs. I think we should do something about this. It
is unrealistic to expect Docbook users to write their own startup Java
file. They want something that works from the command line. But before
we try, it would be useful to hear how other people use FOP with
Docbook.

Simon

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



path of checkstyle.header

2005-12-09 Thread Simon Pepping
In checkstyle-4.0.xml I need to set

  property name=headerFile value=${samedir}/checkstyle.header/

instead of

  property name=headerFile value=checkstyle.header/

to get the Eclipse Checkstyle plugin to find the header. Do I do
something wrong, or can I safely commit this change?

Simon

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



Re: Hyphetation broken with last commits

2005-12-17 Thread Simon Pepping
On Sat, Dec 17, 2005 at 11:43:36AM +0800, Manuel Mall wrote:
 It is not a special situation at all. Simply having a nbsp; in your 
 text is enough to trigger this regression. And yes, it is an regression 
 caused by the fix for the disappearing empty line problem: 
 fo:block#160;/fo:block
 
 After some debugging it is obvious to me what is happening. However, it 
 is much less obvious how to fix it. In brief:
 
 The fix added a zero width Knuth box to the element list created for a 
 nbsp. This was done for two reasons:
 a) to avoid it being removed by the removeElementsForTrailingSpaces() 
 method. That method is wrong in the first place as it knowingly tries 
 to remove non breaking spaces which IMO should never be removed. 

In Knuth's situation spaces were always suppressed at a
linebreak. Therefore suppressing glues around a linebreak is built
into the algorithm. For FO, we need glues that are not suppressed
around a linebreak. Perhaps a boolean member 'suppress-at-line-break'
of KnuthGlue?

 b) However, changing that method to not remove nbsp would give us Knuth 
 paragraphs containing only Glue and Penalty elements. This then causes 
 our implementation of the Knuth algorithm to 'spit the dummy'. Luca, 
 why does our line breaking algorithm insist on having at least one Box 
 in a paragraph? Is that inherent in the Knuth algorithm, i.e. can't it 
 deal with empty paragraphs, that is paragraphs containing only Glue/Pen 
 elements?

The above proposed member would not solve this problem.

The case is contradictory in itself, and quite unique. A nbsp will
never occur at the end of a line by its very definition, except in
this case!

Simon

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



Re: Hyphetation broken with last commits

2005-12-17 Thread Simon Pepping
On Sat, Dec 17, 2005 at 05:46:42PM +0100, Andreas L Delmelle wrote:
 On Dec 17, 2005, at 16:29, Manuel Mall wrote:
 
 
 Hi,
 
 On Sat, 17 Dec 2005 11:07 pm, Simon Pepping wrote:
 On Sat, Dec 17, 2005 at 11:43:36AM +0800, Manuel Mall wrote:
 snip/
 The case is contradictory in itself, and quite unique. A nbsp will
 never occur at the end of a line by its very definition, except in
 this case!
 
 Simon,
 
 I don't quite get it what you are trying to say.
 
 fo:block#160;/fo:block
 
 is perfectly legal and sensible in both XSL-FO (and HTML) and doesn't
 that mean a nbsp does occur at the end (and beginning) of a line.
 
 I guess what Simon is referring to is that if the line-breaking  
 algorithm does its job adequately, there will be no line-break  
 preceding/following a non-breaking-space, except when it is the first/ 
 last character in a block. Other break-possibilities should, in  
 theory at least, always be considered more favorable than breaking  
 before/after the nbsp... Correct, Simon?

That is precisely what I tried to say.
 
 What is contradictory or unique about this?
 
 That indeed is a bit overstating the case. It's not contradictory,  
 but it is a rather special situation. Not taking into account the  
 number of times such a construct is used in practice... It is more of  
 an HTML/XSL-FO trick to make a block appear non-empty --used mainly  
 in the context of table-cells, to have their borders drawn despite  
 the fact that there is no visible content.

It is not a formal contradiction, but it feels like one: nbsp should
not have a linebreak around it, but here we have to solve the problem
how to deal with it when it does have a linebreak preceding or
following it.

Simon

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



Re: Hyphetation broken with last commits

2005-12-18 Thread Simon Pepping
On Sun, Dec 18, 2005 at 11:10:37AM +0100, Andreas L Delmelle wrote:
 On Dec 18, 2005, at 06:16, Manuel Mall wrote:
 Does it mean because the Knuth algorithm removes all glues after a
 linebreak (and we also remove all glues at the end of a paragraph) a
 nbsp should not be modelled not like this:
 
pen p=INF
glue w=...
 
 but like this:
 
box w=0 aux=true
pen p=INF
glue w=...
box w=0 aux=true
 
 with the leading box preventing removal at the beginning of a line,  
 the
 trailing box prevents removal at the end of a paragraph, and the
 penalty prevents a line break.
 
 As far as my understanding of the Knuth algorithm goes, that might be  
 a way to solve it. Even better would be to make the creation of the  
 auxiliary zero-width boxes conditional --depending on whether there  
 are already other boxes surrounding the nbsp (if at all possible).  
 It's really only in the cases where there are no preceding/following  
 boxes that we need special treatment, no? In case of surrounding non- 
 whitespace, the first model would seem to be sufficient.

That is indeed the way to solve it. 

The more I think about this, the more complicated it becomes.

Maybe the Knuth algorithm requires that when there are multiple
characters which are suppressed at linebreak, they are considered
together, much like we do in space resolution in page breaking. One
should avoid the situation glue - glue, if the first glue is to be
suppressed when the second glue is a chosen line break. It should be a
single glue, or a sequence like glue #1 - penalty - glue #2 - box -
PENALTY - glue #3 if glue #1 and glue #3, i.e. the glues that remain
around a line break, are not zero.

Simon

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



Eclipse and JUnit [was: Re: Font work (CLA needed)]

2005-12-21 Thread Simon Pepping
On Mon, Dec 19, 2005 at 08:52:59PM +0100, Jeremias Maerki wrote:
 
 On 19.12.2005 20:06:26 Vincent Hennebert wrote:
  Moreover my patched Fop still doesn't pass the unitary tests. I'm trying to 
  figure out what is going on but so far I've spent more time fighting 
  against 
  Eclipse to make the debugger work on the junit system than searching for 
  errors. 
  Not sure yet if I've won.
 
 Hmm, so far I've had no problems debugging inside Eclipse's JUnit
 environment.

I try to avoid it by running fop directly with the XSL stylesheet
test/layoutengine/testcase2fo.xsl, or I even generate the FO using
this stylesheet.

Maybe unnecessary, but if you are not so experienced with eclipse, you
can have a hard time to make it do what you want. Avoiding JUnit in
the debugging process helps me.

Simon

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



Re: [VOTE] Release FOP 0.91beta

2005-12-21 Thread Simon Pepping
On Tue, Dec 20, 2005 at 11:43:29AM +0100, Jeremias Maerki wrote:
 I'd like to call for a PMC vote to release FOP 0.91beta from this newly
 created branch. (Votes to [EMAIL PROTECTED], please)

+1 from me.

Simon

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



Re: Eclipse and JUnit

2005-12-21 Thread Simon Pepping
On Wed, Dec 21, 2005 at 09:48:52AM +0100, Jeremias Maerki wrote:
 That's very unfortunate. Can you guys explain to me what exactly the
 problems are? Maybe I can help. It is very helpful to simply run a
 single test under JUnit control directly from Eclipse. I simply have to
 specify the test case I want to run in the system properties and off I
 go.

Running a single test is always a problem, with ant and with
eclipse. The point is just that I do not do this often, and everytime
I have to look through the test suite code to dig up the exact system
property to set.

Eclipse is a bewildering huge beast when you start with it. I have
just spent some time learning how to use it properly, and now I feel
more comfortable with it. I suppose it is a matter of habit. At the
moment I happen to write scripts more easily than eclipse launch
configurations. So I tend to avoid complications and use the simplest
solution.

Simon

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



junit failures with revision

2005-12-21 Thread Simon Pepping
I get many junit errors with revision 358224. The all seem to be
related to the notation of colors in the area tree, e.g.:

[junit] Testcase: 
block-container_borders.xml(org.apache.fop.layoutengine.LayoutEngineTestSuite$1):
 Caused an ERROR
[junit] Expected XPath expression to evaluate to '(solid,#00,5000)', 
but got '(solid,[EMAIL PROTECTED],5000)' (XPath: 
/areaTree/pageSequence/pageViewport/page[1]/regionViewport/regionBody/mainReference/span/flow/block[1]/@border-start)
[junit] java.lang.RuntimeException: Expected XPath expression to evaluate 
to '(solid,#00,5000)', but got '(solid,[EMAIL PROTECTED],5000)' (XPath: 
/areaTree/pageSequence/pageViewport/page[1]/regionViewport/regionBody/mainReference/span/flow/block[1]/@border-start)

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



Re: Eclipse and JUnit

2005-12-21 Thread Simon Pepping
On Wed, Dec 21, 2005 at 11:03:59AM +0100, Jeremias Maerki wrote:
 Yes, digging up the right system properties is a nuisance, but you only
 have to do it once. Have a look at the attached screen shots that show
 how I set up the launch config for running the FOP test suite. You can
 see that I simply add an x somewhere to effectively disable the
 setting for a system property. Like this I'm can change the parameters to
 the test suite very quickly. Maybe that helps make things easier.

Thanks. The x is a nice trick.

It would be good to have a document describing the system properties
of the test suites. If you do not do it, I will write one.

I see you have a project 'FOP Temp', which probably is a copy of
project FOP. I have a problem making a copy of a project, when I make
a copy of the working directory for a specific task. Esp. one has to
duplicate the lauch configurations. I solve it by reusing the same
symlink on Unix. Is there an easier way to work with a changing set of
copies of the working directory?

Simon

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



Re: svn commit: r359189 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr: AbstractBreaker.java BlockKnuthSequence.java BreakingAlgorithm.java InlineKnuthSequence.java KnuthSequence.java P

2005-12-27 Thread Simon Pepping
On Tue, Dec 27, 2005 at 06:28:15PM +0800, Manuel Mall wrote:
 On Tue, 27 Dec 2005 04:40 pm, [EMAIL PROTECTED] wrote:
  Author: spepping
  Date: Tue Dec 27 00:40:09 2005
  New Revision: 359189
 
  URL: http://svn.apache.org/viewcvs?rev=359189view=rev
  Log:
  I generalized several casts from KnuthElement to ListElement. This
  removes a number of ClassCastExceptions in some files with inline
  block content.
 
 Simon,
 
 just curious - the patch didn't update any of the layout engine test 
 cases. Are those instances of ClassCastExceptions which are fixed by 
 this patch not documented in any test cases? If not could you add one?

Currently they are not documented in any test case. I came across the
problem while working on inline block layout. They will probably be
documented by test files that I will construct for that work. But I
will add one for this commit.

Simon

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



Re: DO NOT REPLY [Bug 38053] - FOP SVN TRUNK crashes at inline page manager and Knuth inline box.

2005-12-28 Thread Simon Pepping
On Wed, Dec 28, 2005 at 05:17:03AM +0100, [EMAIL PROTECTED] wrote:
 For the NPE fix see http://svn.apache.org/viewcvs?rev=359383view=rev
 
 I didn't manage to construct a small test case for the NPE. Any attempts to 
 cut 
 down the large param-tidy.fo to a reasonable size but still exhibiting the 
 problem failed. I must be missing something. Any help / suggestions 
 appreciated.

The test file linearea_nonempty_1.xml reproduces the NPE (without
Manuel's fix).

lastPos being null means that in InlineLM.addAreas, the iterator
parentIter passed to it did not contain any area-generating
positions. In this case, the paragraph is:

Object [0]= LineLayoutManager$Paragraph  (id=96)
Object [0]= KnuthGlue  (id=104)
Object [1]= KnuthPenalty  (id=108)
Object [2]= KnuthGlue  (id=110)
Object [3]= KnuthInlineBox  (id=111)
Object [4]= KnuthPenalty  (id=114)
Object [5]= KnuthGlue  (id=115)
Object [6]= KnuthPenalty  (id=116)

There are two lines: from 0 to 1, and from 2 to 6.

Line 1 is the problem. In LineLM.addInlineArea (a new method, which I
recently extracted from LineLM.addAreas) non-boxes are skipped, so
that iStartElement becomes 3, resulting in an empty iterator.

I do not understand how the line breaking algorithm can produce a line
consisting of only a glue and a penalty.

Regards, Simon

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



Re: svn commit: r360083 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/flow/ test/layoutengine/standard-testcases/

2005-12-30 Thread Simon Pepping
On Fri, Dec 30, 2005 at 11:50:21PM +0800, Manuel Mall wrote:
 On Fri, 30 Dec 2005 11:25 pm, Andreas L Delmelle wrote:
  On Dec 30, 2005, at 14:54, Manuel Mall wrote:
   On Fri, 30 Dec 2005 09:38 pm, Andreas L Delmelle wrote:
   I explicitly excluded fo:leaders from white-space handling,
   because for example:
  
   fo:leader leader-pattern=use-content   xxx   /fo:leader
  
   Collapsing the three spaces to one may produce unintended results.
  
   OTOH, if you have a nested inline in a leader, then the
   white-space for the inline will be treated...
  
   Is there an indication in the spec that whitespace around
   use-content leader patterns should be treated any different? If
   not, I would include it into the normal white space handling.
 
  This was more based on expectation than on anything I encountered in
  the specs, I guess. The white-space around the leader --physically
  outside of the fo:leader element-- is treated according to the type
  of parent it belongs to. The spaces inside the content of the
  fo:leader are left alone. Somehow, even with white-space-
  collapse=true, I'd much more expect the end result to mimic:
 
  fo:leader leader-pattern=use-content...xxx.../fo:leader
 
  than
 
  fo:leader leader-pattern=use-content xxx /fo:leader
 
 
 Actually I wouldn't (assuming default white space handling property 
 values). What do others think?

I agree with Manuel. The white-space-collapse value holds
everywhere. The user must provide a value of false if he wants a
leader pattern with multiple adjacent spaces.

Regards, Simon

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



Re: DO NOT REPLY [Bug 38087] - [patch] force-page-count property implementation

2006-01-04 Thread Simon Pepping
On Wed, Jan 04, 2006 at 02:08:56PM +0100, gerhard oettl wrote:
 --- Additional Comments From [EMAIL PROTECTED]  2006-01-03 22:23 ---
 I am not quite happy with the fact that checkForcePageCount is called
 by the next page sequence. This is an interaction between page
 sequences, and it is better dealt with by the controlling structure,
 in this case AreaTreeHandler. In other words, I go with your
 suggestion in the second *.
 
 I had better orderd the open questions - so think them numbered:
 - 1) 
 - 2)
   * 2a) 
   * 2b) 
   * 2c)
 
 ad 1) 
 If there is no precedence for one of the choices i will change
 previousPageSeqLM from public to private as proposed in the question.

Agreed.
 
 ad 2) 
 I think it is the second - what you call the second * ?
 Because i couldn't think it a good idea to preserve the 
 PageSequenceLayoutManger at layoutmanger level and call it from area 
 level, so i think i shall do the changes 2a, 2b and 2c alltogether.
 2c is a must anyway.

2b is the second *. I agree with your proposal to do all three changes
2a-c.

 There is a little error in the last page sequence but one in your demo
 file. It says that next is auto-even, which is not true.
 
 yes
 If of any importance i can add a corrected fo to show the possibility 
 of missing pagenumbers in case of force-page-count=no-force.
 Let me know.

It would be good if you could turn it into a test file for the
layoutengine tests, which highlights all relevant
combinations of force-page-count and initial-page-number. Otherwise I
will do it.

  .''`.   gerhard oettl   on   Debian/Gnu Linux
That's the best, as soon as I find out how to make my mike work. :-)

Regards, Simon

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



Re: [patch] allow some xsl-function calls with omitted args

2006-01-05 Thread Simon Pepping
On Thu, Jan 05, 2006 at 07:57:07PM +0100, Andreas L Delmelle wrote:
 On Jan 5, 2006, at 11:42, gerhard oettl wrote:
 
 Have you tried putting the properties in reverse-order:
 
 fo:table-cell column-number=3 display-align=from-table-column()
 
 If that works, then it's a combination of a) and b), in the sense  
 that it's the SAX parser that does a), and then passes the list as  
 such to the PropertyList, which does b).

Never rely on the order of the attributes. Usually they will be
delivered in the order of the XML file. But if a user uses a SAX
parser that delivers them in a different order, the code must still
work. From org.xml.sax.Attributes documentation:

The order of attributes in the list is unspecified, and will vary from
implementation to implementation.

Simon

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



Re: [patch] force-page-count property implementation

2006-01-05 Thread Simon Pepping
On Thu, Jan 05, 2006 at 12:19:26PM +0100, gerhard oettl wrote:
 
 It would be good if you could turn it into a test file for the
 layoutengine tests, which highlights all relevant
 combinations of force-page-count and initial-page-number. Otherwise I
 will do it.
 
 If have idea how which xslt paths to use for testing, but if you
 could lead me by sending me one (or two) examples with the first
 page-sequences of my current (not automated) testfile (may be via
 PM or so that i check it out with the next svn up and point me to
 the file) i'll do the rest.

I will send you some tests, tomorrow or over the weekend.

Simon

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



Re: table-column and number-columns-spanned (prepatch)

2006-01-12 Thread Simon Pepping
Gerhard,

Thanks for your continued patches. Would you consider submitting an
'Individual Contributor License Agreement (ICLA)'? That would allow us
to commit a larger amount of code from you. See
http://www.apache.org/licenses/.

You may in addition submit a 'Corporate Contributor License Agreement'
(CCLA), but that serves more to define your position w.r.t. your
employer, if he would have Intellectual Property rights to the code.

Regards, Simon

On Thu, Jan 12, 2006 at 07:30:58PM +0100, [EMAIL PROTECTED] wrote:
 http://issues.apache.org/bugzilla/show_bug.cgi?id=38244
 
Summary: table-column and number-columns-spanned (prepatch)
 ReportedBy: [EMAIL PROTECTED]
 
 
 Only to have a first sign to discuss.

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



Re: table-columns and number-columns-spanned

2006-01-12 Thread Simon Pepping
On Thu, Jan 12, 2006 at 09:55:57PM +0100, gerhard oettl wrote:
 fo:table-column number-columns-spanned=2 
 number-columns-repeated=2/ [ initial colnum = default = 1 ]
 would be expanded according to b) to:
 fo:table-column number-columns-spanned=2/ [ colnum = 1 ]
 fo:table-column number-columns-spanned=2/ [ colnum = 3 ]
 fo:table-column number-columns-spanned=2/ [ colnum = 5 ]

The above represents number-columns-repeated=3.

fo:table-column number-columns-spanned=2/ is equivalent to
fo:table-column number-columns-spanned=2
number-columns-repeated=1/ (initial value).

Simon

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



Re: svn commit: r368462

2006-01-13 Thread Simon Pepping
On Fri, Jan 13, 2006 at 07:34:40AM +0800, Manuel Mall wrote:
 On Fri, 13 Jan 2006 04:40 am, [EMAIL PROTECTED] wrote:
  Author: spepping
  Date: Thu Jan 12 12:40:08 2006
  New Revision: 368462
 
  xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/expr/FromParentFunct
 ion.java (original) +++
  xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/expr/FromParentFunct
 ion.java Thu Jan 12 12:40:08 2006 @@ -1,5 +1,5 @@
   /*
  - * Copyright 1999-2004 The Apache Software Foundation.
  + * Copyright 1999-2006 The Apache Software Foundation.
*
 I know this is very picky but shouldn't this be written as:
 
 Copyright 1999-2004, 2006 The Apache Software Foundation.
 
 Unless there was a change to the file in 2005 (see 
 http://www.apache.org/dev/apply-license.html)?

I thought of it when I made the change, but I did not know of any
pertinent rule.

At the page you link to, I suppose you aim at this phrase:

 Source files contributed to or developed as part of an ASF project
 should begin with a copyright notice like
 
Copyright 2004 The Apache Software Foundation.
 or
Copyright 1999-2004 The Apache Software Foundation.
 or
Copyright 2002,2004 The Apache Software Foundation.
 
 where the years given start with the first publication year of the
 file contents (the authored expression) and include a range of years
 for each year that new significant content (derivative work) is
 published within the file. Since the ASF publishes its code in public
 source code modules (CVS and Subversion), we generally want to include
 a range of years starting with the year of origin.

It is quite equivocal for me. On the one hand it speaks about new
significant content, which would mean: leave out 2005. On the other it
speaks about a range of years due to the public accessibility (meaning
continuous publication?), which would mean: 1999-2006.

Simon

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



Re: svn commit: r372916 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/rtf/RTFHandler.java

2006-01-27 Thread Simon Pepping
On Fri, Jan 27, 2006 at 06:56:21PM +0100, Andreas L Delmelle wrote:
 On Jan 27, 2006, at 18:28, Andreas L Delmelle wrote:
 
 
 Right now, it works, and it enhances our RTF output, so there's no  
 need to revert, but I'm wondering if there isn't an alternative  
 solution that would look/feel better.
 
 Since I started this...
 
 I'm thinking in the direction of using the PercentBaseContext  
 interface here, instead of the layoutmgr specific classes that  
 implement it. IOW: approach the percentage resolution as something  
 that is shared between structural and non-structural renderers,  
 instead of the non-structural renderer borrowing functionality from  
 the structural one.
 
 Does this make sense?

I share your objections against the mixing of packages.

Regards, Simon

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



Re: white-space-collapse not working in trunk?

2006-02-14 Thread Simon Pepping
On Tue, Feb 14, 2006 at 10:26:52AM +0100, Luca Furini wrote:
 
 In order to preserve all spaces, we could use the elements that are now 
 generated for a nbsp:
box  w=0
penalty inf
glue (elastic or not, according to the alignment)
 
 They are not suppressed and they do not allow a break, so I think they 
 should fit quite well this situation too, when white-space-treatment = 
 preserve and wrap-option=no-wrap.

If wrap-option=no-wrap, cannot we somehow avoid the whole linebreak
calculation? Each line is a Knuth paragraph and creates a single line.
 
 If wrap-option=wrap, however, we must add some penalties in order to 
 allow a break between spaces; we must be careful, as if there are 3 spaces 
 between two words, there are 4 possible breaks (ignoring, at the moment, 
 unicode breaking rules), so we just cannot add a penalty before or after 
 the other elements.

Isn't it so that in the case of white-space-treatment=preserve the
line breaks are between the spaces instead of on them? Then for a___b,
where an underscore indicates a space, I would construct

box(a) p box(0) p(inf) glue p box(0) p(inf) glue p box(0) p(inf) glue p box(b)

with possible line breaks at the p.
 
Simon

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



  1   2   3   4   5   >