Re: cvs commit: xml-fop/test/layoutengine/testcases indent2.xml
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
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
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
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?
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
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
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
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
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!
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?
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
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
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
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)
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
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)
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)
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)
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
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
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
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
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
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
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
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))
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
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
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
+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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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/
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
+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
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
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
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]
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
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
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
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
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
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
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)
(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
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
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
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
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)]
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
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
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
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
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
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.
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/
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
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
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
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)
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
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
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
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?
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