Re: cvs commit: xml-fop/src/java/org/apache/fop/render/awt/viewer/resources Viewer_de.properties Viewer_fr.properties Viewer.properties
[EMAIL PROTECTED] writes: jeremias2005/06/15 05:24:01 Modified:src/java/org/apache/fop/render/awt AWTRenderer.java src/java/org/apache/fop/render/java2d Java2DRenderer.java src/java/org/apache/fop/render/print PrintRenderer.java src/java/org/apache/fop/render/awt/viewer Command.java PreviewDialog.java src/java/org/apache/fop/render/awt/viewer/resources Viewer_de.properties Viewer_fr.properties Viewer.properties Added: src/java/org/apache/fop/render/awt/viewer package.html PreviewPanel.java ImageProxyPanel.java Log: Bugzilla: #35358 Improvements on Viewer application: There's now an additional patch which fixes some minor bugs in this. Please see the original bug report: http://issues.apache.org/bugzilla/show_bug.cgi?id=35358 Regards, Richard
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java
Glen,
this was quite interesting. Right after your change here, my local
changes started to fail. Obviously, my changes for changing BPD between
pages was the first use case for getTopLevelLM() to fetch the PSLM. But
you are likely to remove the LayoutManager interface from PSLM I took a
different route and made the PageViewportProvider available differently.
I hope that was acceptable and still as clean as possible. I was also
thinking about promoting the PageViewportProvider in PSLM to a full
class. But I left it out for now.
On 14.06.2005 04:54:09 gmazza wrote:
gmazza 2005/06/13 19:54:09
Modified:src/java/org/apache/fop/layoutmgr
PageSequenceLayoutManager.java
Log:
Switched to null for PageBreaker.getTopLevelLM().
Not being used by the page-breaking process.
Revision ChangesPath
1.67 +2 -2
xml-fop/src/java/org/apache/fop/layoutmgr/PageSequenceLayoutManager.java
Index: PageSequenceLayoutManager.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/layoutmgr/PageSequenceLayoutManager.java,v
retrieving revision 1.66
retrieving revision 1.67
diff -u -r1.66 -r1.67
--- PageSequenceLayoutManager.java 9 Jun 2005 02:39:55 - 1.66
+++ PageSequenceLayoutManager.java 14 Jun 2005 02:54:09 - 1.67
@@ -157,7 +157,7 @@
}
protected LayoutManager getTopLevelLM() {
-return pslm;
+return null; // unneeded for PSLM
}
protected LinkedList getNextKnuthElements(LayoutContext context,
int alignment) {
Jeremias Maerki
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr StaticContentLayoutmanager.java LineLayoutManager.java AbstractLayoutManager.java TextLayoutManager.java LayoutManagerMapping.java ContentLayo
Glen Mazza wrote: Are you sure here? We had two versions of addALetterSpaceTo() -- the version in ILLM which takes a List (I didn't touch that one), and a old (?) version from AbstractLayoutManager that takes a KnuthElement. It is that latter version that I removed--it wasn't being called anywhere--not the former. Oops, sorry, you are completely right. So, it seems that the new version of addALetterSpaceTo(), the one taking a List, has not replaced all the occurences of the old one: I'm going to fix this as soon as possible. Regards Luca
Re: cvs commit: xml-fop/src/java/org/apache/fop/render RendererFactory.java
Bonjour Jeremias Maerki wrote: You're right. I didn't check them when reviewing the patch. I tried again but I don't get valid images. Renaud, would you please post the two images separately? Thank you. Humhum/ 1) I can't find the pictures anymore (changed computer, and failed to copy those ressources :( ). 2) fopLogo.gif was a logo that appeared on the viewer itself [1] and logo_big.jpg was for the menu helpabout [2]. 3) Anyway, those pictures were a quick fix for me (low quality), just to make the viewer more attractive. Sorry, Renaud [1] PreviewDialog.java line 141 [2] PreviewDialogAboutBox.java line 68 On 09.06.2005 16:33:59 richardw wrote: [EMAIL PROTECTED] writes: jeremias2005/06/09 01:49:27 Modified: src/java/org/apache/fop/render/awt/viewer/images fopLogo.gif logo_big.jpg Submitted by:Renaud Richardet renaud.richardet.at.gmail.com Both of these files appear to be corrupt. Can you please confirm this and either upload the correct versions or point me to them, Richard Jeremias Maerki
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr StaticContentLayoutManager.java LineLayoutManager.java AbstractLayoutManager.java TextLayoutManager.java LayoutManagerMapping.java ContentLayo
Thanks for your optimization work, Glen. Just a note: the method addALetterSpaceTo() is defined in the interface InlineLevelLayoutManager and is still used. It is called by LineLM.collectInlineKnuthElements(), if the last element returned by a child LM and the first returned by the next child LM are both boxes. So, the CharacterLM and LeaderLM (extending LeafNodeLM, that implements InlineLevelLM) should really implement it. For example, if we have fo:blocka fo:character character=w/ord/fo:block we must tell the CharacterLM that the w is followed by a letter space, as it is not a whole word. Regards Luca
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr StaticContentLayoutManager.java LineLayoutManager.java AbstractLayoutManager.java TextLayoutManager.java LayoutManagerMapping.java ContentLayo
Luca, Are you sure here? We had two versions of addALetterSpaceTo() -- the version in ILLM which takes a List (I didn't touch that one), and a old (?) version from AbstractLayoutManager that takes a KnuthElement. It is that latter version that I removed--it wasn't being called anywhere--not the former. Glen - Original Message - From: Luca Furini [EMAIL PROTECTED] To: fop-dev@xmlgraphics.apache.org Sent: Friday, June 10, 2005 2:19 PM Subject: Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr StaticContentLayoutManager.java LineLayoutManager.java AbstractLayoutManager.java TextLayoutManager.java LayoutManagerMapping.java ContentLayoutManager.java LeaderLayoutManager.java LayoutManager.java CharacterLayoutManager.java BlockLayoutManager.java FlowLayoutManager.java Thanks for your optimization work, Glen. Just a note: the method addALetterSpaceTo() is defined in the interface InlineLevelLayoutManager and is still used. It is called by LineLM.collectInlineKnuthElements(), if the last element returned by a child LM and the first returned by the next child LM are both boxes. So, the CharacterLM and LeaderLM (extending LeafNodeLM, that implements InlineLevelLM) should really implement it. For example, if we have fo:blocka fo:character character=w/ord/fo:block we must tell the CharacterLM that the w is followed by a letter space, as it is not a whole word. Regards Luca
Re: cvs commit: xml-fop/src/java/org/apache/fop/render RendererFactory.java
You're right. I didn't check them when reviewing the patch. I tried again but I don't get valid images. Renaud, would you please post the two images separately? Thank you. On 09.06.2005 16:33:59 richardw wrote: [EMAIL PROTECTED] writes: jeremias2005/06/09 01:49:27 Modified: src/java/org/apache/fop/render/awt/viewer/images fopLogo.gif logo_big.jpg Submitted by:Renaud Richardet renaud.richardet.at.gmail.com Both of these files appear to be corrupt. Can you please confirm this and either upload the correct versions or point me to them, Richard Jeremias Maerki
RE: More collapsing borders... (RE: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr/table TableContentLayoutManager.java)
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Hi, (OK, apologies for my alias turning up... Completely unintended. here's the remainder of the response. Other comments, much longer than the previous one...) On 17.05.2005 23:24:55 Andreas L. Delmelle wrote: snip / The current fact that there's an explicit reference to the border-*styles* in an essentially layout-related class... Well, somehow it does not sit completely right with me --could be a matter of taste, but IMO, layout needs to concern itself only with sizes... That was a natural outcome since there are certain specialities in the collapse model. If you look closely there's a little special case where the collapsed border between two cells has the same style and width but potentially different colors. If you follow through the rules 1 to 5 you end up in rule 5 solid 0.5pt red specified in one cell, solid 0.5pt green in the neighbouring cell. See table-border-collapse1.xml in testcases for an example. There's no rule that says how to decide which of the two wins. Very good point! Still, I would argue in that case that the layout engine only needs to know that the border is going to be 0.5pt wide in case of no breaks/spans. It is, strictly speaking, only when rendering the borders that the implementation has to know for sure which colour to use. If we are at liberty to determine that rule ourselves, I would obviously feel much for an approach like 'before/start cell wins' or 'after/end cell loses', and this as early in the process as possible. That would be very convenient. Another idea is to use the color value to decide, or if you really want a nasty solution that is bound to turn up in a bug report: XOR the color values. A bug?? Shame on you for having no sense of humour! Read the CSS Spec and study your table-border source very closely. It's *all* in there! :-) Furthermore, looking at those rules again, you will see that the style is used to determine winners, styles having implicit precedence values. Yes, but this could also be done when creating the FObjs --the styles map to a numeric constant anyway. If we place them in the right precedence-order in the Constants interface(*), we might not even need to assign precedence values in a separate step. We'd directly use the integer value they map to...? That's why you need them aside from having to pipe such information through to the addAreas() stage where the traits are set. So, I would seem to disagree? Up until the 'aside from': the _latter_ part is obviously necessary... If you're talking about the border resolution you can't avoid looking at the style, too. After that, in the table stepper, only the widths are relevant. Getting hotter, I feel it! :-) snip / I still think you're not quite where I am. Take the following methods: - TableContentLayoutManager.resolveNormalBeforeAfterBordersForRowGroup() - TableRowIterator.resolveStartEndBorders() These are the two isolated places where the border resolution for non-break cases are done. After that, the table stepper simply fetches the table widths from the grid units to do the right calculations. ... and a large part of what happens in the above two methods --in the background-- would already be dealt with in the FOTree, so the *only* parts of the code remaining there would be dealing with the break-cases and the span-cases. Very layout-specific stuff indeed! Quite simply put: if a GridUnit corresponds with exactly one TableCell, in a collapsing model, the *only* border-widths you'd really need to take into account would be those of its TableCell. The rest I see as ruled out at that point, *unless* in the following three cases - after-border = still need to compare that to the Cell/GridUnit immediately below - row/column-spans = check the appropriate TableRow/TableColumn for start- or end-borders - page-breaks = check the TableBody/-Header/-Footer for the before- or after-borders The part where I gave up for now was how exactly to handle the border resolution for break situations and how to bring the values into the overall calculation. Resolution to be done by layout in the break-situations would come down to: * First, compare after-border with GridUnit below. This step is always taken (see above) and yields the after-border in no-break situation. The dominant border is used in the following step. * Then, only before- or after-borders matter here, so either the current GridUnits' TableCell (possibly corrected through the first step) or the TableBody/-Header/-Footer will yield the right border-width. Resolution between TableCell and TableRow would already have been handled in the FOTree. Same goes for the resolution between TableColumn and TableBody/-Header/-Footer. If the order of fo:table-header, -footer and -body is enforced by the Rec --so, header and footer *have* to appear before body in the FO source--, then the same could be
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr/table TableContentLayoutManager.java
done. On 18.05.2005 00:58:46 Glen Mazza wrote: I believe you had also commented out some Maker classes in layoutmgr.LayoutManagerMapping for unused table LMs. Can we get rid of those now as well? Thanks, Glen [EMAIL PROTECTED] wrote: jeremias2005/05/17 02:10:40 Modified:src/java/org/apache/fop/layoutmgr/table TableContentLayoutManager.java Log: Bugfix: Removal of last penalty is fixed now. Cleanup, style improvements and javadocs. Jeremias Maerki
Re: More collapsing borders... (RE: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr/table TableContentLayoutManager.java)
Hi Andreas On 17.05.2005 23:24:55 Andreas L. Delmelle wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Hi Jeremias and others interested in table-borders, (Sorry for the --again-- long post, but...) The following comment in the code (TCLM) got me wondering... //Create empty grid units to hold resolved borders of neighbouring cells //TODO maybe this needs to be done differently (and sooner) ... if we're on the same frequency here --and to avoid re-inventing the wheel ;-) Have you also considered --even if only partly-- normalizing table borders during the FOTree-building? (Or do you only mean 'sooner' in the layout process?) I meant sooner in the layout process, i.e. in the TableRowIterator. I added that in in a sort of ad-hoc fashion when I needed to fix the problem of grid units not being present. This is something I'm still pondering over, as, for instance the following fragment (supposing a collapsing model, easy case: no borders specified higher up): fo:table-row border=solid 4pt fo:table-cell border=solid 2pt !-- block content -- /fo:table-cell !-- more cells -- /fo:table-row fo:table-row fo:table-cell border=solid 3pt !-- block content -- /fo:table-cell !-- more cells -- /fo:table-row AFAICT could be expanded in one go into: (I'm not completely sure, but aren't the shorthands expanded internally? If so, can we use that to our advantage?) AFAIK, they are expanded while setting up the CommonBorderPaddingBackground instances in the FO nodes. This class is already mutable so you could, in theory, manipulate the instances held by the FO nodes. A bigger problem, one I'm working around by working on the grid unit list, is the addition of cells to the FO tree if that's necessary. I experimented with this in another place and dropped it because of the property expansion mechanism. fo:table-row border-before=solid 4pt border-after=solid 4pt border-start=solid 4pt border-end=solid 4pt fo:table-cell border-before=solid 4pt border-after=solid 4pt border-start=solid 4pt border-end=... !-- block content -- /fo:table-cell !-- more cells -- /fo:table-row fo:table-row border-before=solid 4pt border-start=solid 3pt fo:table-cell border-before=solid 4pt border-after=solid 3pt border-start=solid 3pt border-end=... !-- block content -- /fo:table-cell !-- more cells -- /fo:table-row Well, apart from a few liberties I may have taken here, I think the idea is clear enough that, *if* this could be pulled off, this may greatly simplify the related portions in the layout code... Greatly simplified or simply done elsewhere? I keep coming back to handling break cases. Two places in which borders are resolved remain, nonetheless (break vs. non-break). Evidently, at that point we would only be able to compare with cells that were previously read --events already occured--, so at first sight it only solves part of the problem, but anyway... In the simplest cases --i.e. no breaks and no spans-- the right border-widths need only be _read_ by the LM from the FObjs, and the LM only needs to decide whether to add (separated borders) or take into account the one with the highest precedence (collapsing borders). Further motivation: in principle, only the widths of the borders should be relevant to the layout code. That's true, if by layout code you mean only the table stepper, i.e. the generation of the combined element list. The current fact that there's an explicit reference to the border-*styles* in an essentially layout-related class... Well, somehow it does not sit completely right with me --could be a matter of taste, but IMO, layout needs to concern itself only with sizes... That was a natural outcome since there are certain specialities in the collapse model. If you look closely there's a little special case where the collapsed border between two cells has the same style and width but potentially different colors. If you follow through the rules 1 to 5 you end up in rule 5 solid 0.5pt red specified in one cell, solid 0.5pt green in the neighbouring cell. See table-border-collapse1.xml in testcases for an example. There's no rule that says how to decide which of the two wins. Furthermore, looking at those rules again, you will see that the style is used to determine winners, styles having implicit precedence values. That's why you need them aside from having to pipe such information through to the addAreas() stage where the traits are set. If you're talking about the border resolution you can't avoid looking at the style, too. After that, in the table stepper, only the widths are relevant. The only real hard work in layout would be limited to the two difficult cases --breaks/spans--, but
More collapsing borders... (RE: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr/table TableContentLayoutManager.java)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Hi Jeremias and others interested in table-borders, (Sorry for the --again-- long post, but...) The following comment in the code (TCLM) got me wondering... //Create empty grid units to hold resolved borders of neighbouring cells //TODO maybe this needs to be done differently (and sooner) ... if we're on the same frequency here --and to avoid re-inventing the wheel ;-) Have you also considered --even if only partly-- normalizing table borders during the FOTree-building? (Or do you only mean 'sooner' in the layout process?) This is something I'm still pondering over, as, for instance the following fragment (supposing a collapsing model, easy case: no borders specified higher up): fo:table-row border=solid 4pt fo:table-cell border=solid 2pt !-- block content -- /fo:table-cell !-- more cells -- /fo:table-row fo:table-row fo:table-cell border=solid 3pt !-- block content -- /fo:table-cell !-- more cells -- /fo:table-row AFAICT could be expanded in one go into: (I'm not completely sure, but aren't the shorthands expanded internally? If so, can we use that to our advantage?) fo:table-row border-before=solid 4pt border-after=solid 4pt border-start=solid 4pt border-end=solid 4pt fo:table-cell border-before=solid 4pt border-after=solid 4pt border-start=solid 4pt border-end=... !-- block content -- /fo:table-cell !-- more cells -- /fo:table-row fo:table-row border-before=solid 4pt border-start=solid 3pt fo:table-cell border-before=solid 4pt border-after=solid 3pt border-start=solid 3pt border-end=... !-- block content -- /fo:table-cell !-- more cells -- /fo:table-row Well, apart from a few liberties I may have taken here, I think the idea is clear enough that, *if* this could be pulled off, this may greatly simplify the related portions in the layout code... Evidently, at that point we would only be able to compare with cells that were previously read --events already occured--, so at first sight it only solves part of the problem, but anyway... In the simplest cases --i.e. no breaks and no spans-- the right border-widths need only be _read_ by the LM from the FObjs, and the LM only needs to decide whether to add (separated borders) or take into account the one with the highest precedence (collapsing borders). Further motivation: in principle, only the widths of the borders should be relevant to the layout code. The current fact that there's an explicit reference to the border-*styles* in an essentially layout-related class... Well, somehow it does not sit completely right with me --could be a matter of taste, but IMO, layout needs to concern itself only with sizes... The only real hard work in layout would be limited to the two difficult cases --breaks/spans--, but exactly because only these two would need to be handled during layout, they would become clearly outlined in the code --and because the lion's share of the decisions are already made before the LMs kick off, even this 'hard work' could turn out to be quite straightforward. What would it mean for layout if large parts of the 'determineWinner()' functionality would actually shift somewhere to the Property subsystem and the FOTree (? where they are ultimately still accessible to Layout if needed?) Anyway, the more I read the parts in the XSL-FO and CSS Rec about borders, the more I get the impression that the collapsing model works: - partly on the level of the bare properties/FOTree the question: which borders are dominant in the general cases? - and partly on the level of layout the question: what is the size of the space assigned to the applicable borders in this case? ATM it's only a thought. Just checking to see if, in anyone's opinion, it would be worth digging deeper into... if treating the above two questions separately helps to avoid (or even merely alleviate) certain headaches, all the better. Cheers, Andreas
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr/table TableStepper.java TableContentLayoutManager.java EffRow.java
Message received and understood, code improved. I'll pay more attention
next time. Looks like peer review really works around here. Thanks, Glen.
On 13.05.2005 01:38:24 Glen Mazza wrote:
[EMAIL PROTECTED] wrote:
jeremias2005/05/12 07:13:45
Modified:src/java/org/apache/fop/layoutmgr/table Tag:
Temp_KnuthStylePageBreaking TableStepper.java
TableContentLayoutManager.java EffRow.java
Log:
Fix for ArrayIndexOutOfBoundsException when empty grid units are involved.
Jeremias, I don't see this as a fix--you seem to be converting a
RunTimeException into a logical error (system runs but you get bad
output.) The latter is many more times harder and more stressful to fix
because with an LE we have no idea where the problem is--FOTree, Layout,
Renderers, PDF Library, user version of JDK/Adobe Acrobat, etc., etc.
Converting RTE's into LE's IMO does not really create rigorous, robust,
low-maintenance coding.
+public GridUnit getGridUnit(int index) {
+if (index = 0 index gridUnits.size()) {
+return (GridUnit)gridUnits.get(index);
+} else {
+return null;
+}
+}
If the caller is so incompetent to be requesting grid unit #42 for a
system with only 10 grid units--shouldn't we have FOP to halt with the
Array Index RTE so we can get that bug quickly identified and fixed?
(Or, if we can't fix it immediately, put a Band-Aid fix in the caller
instead of the callee?) The quiet returning of null thwarts that, and
when users start complaining about bad output due to the LE, we won't
know where the problem is to fix it. In addition to wearing out
committers wading through the renderers and the PDF library when an RTE
would have told them to quickly look at the FO package, we'll also have
to ask the users a bunch of irrelevant questions such as their versions
of Adobe Acrobat, etc. I don't see how an LE helps us here.
I mentioned this to you earlier because of a odd change you made (line
98 of [1]) to the Span class to create an LE instead of an RTE should
PSLM ask for an invalid column. I don't understand your rationale--if
PSLM is asking for the wrong columns, the output will be messed up
anyway. Best then to choose the solution--i.e., the RTE--that allows us
to quickly zero in on the problem.
I converted your change back[2, line 94/85] to explicitly return an
IllegalStateException, and it was good I did so--I later had an error in
the PSLM coding, asked for an invalid column, and quickly was informed
by the RTE what the problem was so I could immediately fix it.
Thanks,
Glen
[1]
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/area/Span.java?r1=1.6r2=1.6.2.1diff_format=h
[2]
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/area/Span.java?r1=1.6.2.1r2=1.6.2.2diff_format=h
Jeremias Maerki
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr/table TableStepper.java TableContentLayoutManager.java EffRow.java
[EMAIL PROTECTED] wrote:
jeremias2005/05/12 07:13:45
Modified:src/java/org/apache/fop/layoutmgr/table Tag:
Temp_KnuthStylePageBreaking TableStepper.java
TableContentLayoutManager.java EffRow.java
Log:
Fix for ArrayIndexOutOfBoundsException when empty grid units are involved.
Jeremias, I don't see this as a fix--you seem to be converting a
RunTimeException into a logical error (system runs but you get bad
output.) The latter is many more times harder and more stressful to fix
because with an LE we have no idea where the problem is--FOTree, Layout,
Renderers, PDF Library, user version of JDK/Adobe Acrobat, etc., etc.
Converting RTE's into LE's IMO does not really create rigorous, robust,
low-maintenance coding.
+public GridUnit getGridUnit(int index) {
+if (index = 0 index gridUnits.size()) {
+return (GridUnit)gridUnits.get(index);
+} else {
+return null;
+}
+}
If the caller is so incompetent to be requesting grid unit #42 for a
system with only 10 grid units--shouldn't we have FOP to halt with the
Array Index RTE so we can get that bug quickly identified and fixed?
(Or, if we can't fix it immediately, put a Band-Aid fix in the caller
instead of the callee?) The quiet returning of null thwarts that, and
when users start complaining about bad output due to the LE, we won't
know where the problem is to fix it. In addition to wearing out
committers wading through the renderers and the PDF library when an RTE
would have told them to quickly look at the FO package, we'll also have
to ask the users a bunch of irrelevant questions such as their versions
of Adobe Acrobat, etc. I don't see how an LE helps us here.
I mentioned this to you earlier because of a odd change you made (line
98 of [1]) to the Span class to create an LE instead of an RTE should
PSLM ask for an invalid column. I don't understand your rationale--if
PSLM is asking for the wrong columns, the output will be messed up
anyway. Best then to choose the solution--i.e., the RTE--that allows us
to quickly zero in on the problem.
I converted your change back[2, line 94/85] to explicitly return an
IllegalStateException, and it was good I did so--I later had an error in
the PSLM coding, asked for an invalid column, and quickly was informed
by the RTE what the problem was so I could immediately fix it.
Thanks,
Glen
[1]
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/area/Span.java?r1=1.6r2=1.6.2.1diff_format=h
[2]
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/area/Span.java?r1=1.6.2.1r2=1.6.2.2diff_format=h
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java
[EMAIL PROTECTED] schrieb: gmazza 2005/05/12 17:54:14 Modified:src/java/org/apache/fop/layoutmgr Tag: Temp_KnuthStylePageBreaking PageSequenceLayoutManager.java Log: Copied the logic over incorrectly--fixed (even though IIRC RetrieveMarkers work currently anyway.) Correction: *don't* work.
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java
Glen Mazza wrote: Jeremias Maerki wrote: Glen, I'd like you to revert that one and take a different approach if any. Kein Problem. Bald werde ich dass machen, aber nicht dieser Nacht, weil ich ziemlich muede bin. handleBreak does really handle break-before AND break-after, so the name was ok. Ja, Sie haben Recht. Leider habe ich nur die ehemalige PSLM.prepareNormalFlowArea() gelesen, und von da irrtumlich gelernen, dass break-before die einzel Benutzung war. What can be is that there is some left-over code from the previous approach. Ja, jetzt sollen wir das alterer Kodierung (pNFA() usw.) entfernen. Letztes Januar war PSLM ungefaehr 930 LVK, aber bald wird es vielleicht nur 560 LVK sein! Jeremias/Glen: could you translate this for me? Sorry but I dont speak German! Chris Danke, Glen
RE: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java
-Original Message- From: Chris Bowditch [mailto:[EMAIL PROTECTED] Hi Chris, Let me have a go... Glen Mazza wrote: Kein Problem. Bald werde ich dass machen, aber nicht dieser Nacht, weil ich ziemlich muede bin. No prob. I'll do it soon, but not tonight, because I'm quite tired. Ja, Sie haben Recht. Leider habe ich nur die ehemalige PSLM.prepareNormalFlowArea() gelesen, und von da irrtumlich gelernen, dass break-before die einzel Benutzung war. (I think it should be 'gelernt' here... but ok, Glen was tired :-) ) Yes, you're right. Unfortunately, I've only read the former PSLM.prepareNormalFlowArea(), and inferred from there that break-before was the only use. Ja, jetzt sollen wir das alterer Kodierung (pNFA() usw.) entfernen. Letztes Januar war PSLM ungefaehr 930 LVK, aber bald wird es vielleicht nur 560 LVK sein! Yes, and now we will remove the older code (pNFA() etc.). Last January, PSLM was about 930 LOC, but soon there will be only 560 LOC left! Cheers, Andreas
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java
Jeremias/Glen: could you translate this for me? Sorry but I dont speak German! Here you are: On 06.05.2005 09:47:33 Chris Bowditch wrote: Glen Mazza wrote: Jeremias Maerki wrote: Glen, I'd like you to revert that one and take a different approach if any. Kein Problem. Bald werde ich dass machen, aber nicht dieser Nacht, weil ich ziemlich muede bin. English: No problem. I'll do that soon, but not tonight because I'm rather tired. handleBreak does really handle break-before AND break-after, so the name was ok. Ja, Sie haben Recht. Leider habe ich nur die ehemalige PSLM.prepareNormalFlowArea() gelesen, und von da irrtumlich gelernen, dass break-before die einzel Benutzung war. English: Yes, you're right. I'm afraid I've read but the former PSLM.prepareNormalFlowArea(), and erroneously assumed that only break-before was used. What can be is that there is some left-over code from the previous approach. Ja, jetzt sollen wir das alterer Kodierung (pNFA() usw.) entfernen. Letztes Januar war PSLM ungefaehr 930 LVK, aber bald wird es vielleicht nur 560 LVK sein! English: Yes, we should remove the old code now. Last January, PSLM was about 930 lines of code, but soon it'll be but 560! Jeremias Maerki
RE: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Glen: Ja, jetzt sollen wir das alterer Kodierung (pNFA() usw.) entfernen. ... English: Yes, we should remove the old code now. Of course 'should', got my modal verbs mixed up again :-) Greetz, Andreas
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java
Andreas L. Delmelle wrote: -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Glen: Ja, jetzt sollen wir das alterer Kodierung (pNFA() usw.) entfernen. ... English: Yes, we should remove the old code now. Of course 'should', got my modal verbs mixed up again :-) Thanks for the translation. Am I the only non-german speaking committer on the FOP project?!? Chris
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java
On May 6, 2005, at 2:56 AM, Chris Bowditch wrote: Andreas L. Delmelle wrote: -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Glen: Ja, jetzt sollen wir das alterer Kodierung (pNFA() usw.) entfernen. ... English: Yes, we should remove the old code now. Of course 'should', got my modal verbs mixed up again :-) Thanks for the translation. Am I the only non-german speaking committer on the FOP project?!? Chris No... and you're quite right, that 'official' FOP business should be in English. But niceties tend to go back and forth in this group, and I don't mind. It adds a bit of spice IMHO. In any case, I tend to use Babelfish or Google's Language Tools when I come across something I don't completely understand... In addition, I wrote it off as not really being important, as it was written in German. I don't say that to be particularly snobbish... but if it were important, I figured it would've been in English. Regards, Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java
Jeremias Maerki wrote: Glen, I'd like you to revert that one and take a different approach if any. Kein Problem. Bald werde ich dass machen, aber nicht dieser Nacht, weil ich ziemlich muede bin. handleBreak does really handle break-before AND break-after, so the name was ok. Ja, Sie haben Recht. Leider habe ich nur die ehemalige PSLM.prepareNormalFlowArea() gelesen, und von da irrtumlich gelernen, dass break-before die einzel Benutzung war. What can be is that there is some left-over code from the previous approach. Ja, jetzt sollen wir das alterer Kodierung (pNFA() usw.) entfernen. Letztes Januar war PSLM ungefaehr 930 LVK, aber bald wird es vielleicht nur 560 LVK sein! Danke, Glen
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java
Glen, I'd like you to revert that one and take a different approach if any. handleBreak does really handle break-before AND break-after, so the name was ok. What can be is that there is some left-over code from the previous approach. I'm not sure but I think we don't even need the break-* traits anymore because this is already handled during the creation of element lists. Break-before and break-after are normalized to the startOn value held by BlockSequence. On 05.05.2005 06:54:08 gmazza wrote: gmazza 2005/05/04 21:54:08 Modified:src/java/org/apache/fop/layoutmgr Tag: Temp_KnuthStylePageBreaking PageSequenceLayoutManager.java Log: More clarifications to PSLM. Revision ChangesPath No revision No revision 1.50.2.22 +33 -34 xml-fop/src/java/org/apache/fop/layoutmgr/PageSequenceLayoutManager.java Index: PageSequenceLayoutManager.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/layoutmgr/PageSequenceLayoutManager.java,v snip/ -// otherwise, we simply need a new page -handleBreak(bIsFirstPage ? list.getStartOn() : Constants.EN_PAGE); +// otherwise, we may simply need a new page +handleBreakBefore(bIsFirstPage ? list.getStartOn() : Constants.EN_PAGE); snip/ Jeremias Maerki
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr AbstractBreaker.java PageSequenceLayoutManager.java
Looks good!
Glen
[EMAIL PROTECTED] wrote:
lfurini 2005/04/27 08:59:59
Modified:src/java/org/apache/fop/layoutmgr Tag:
Temp_KnuthStylePageBreaking AbstractBreaker.java
PageSequenceLayoutManager.java
Log:
Using a more clear boolean instead of an int, as suggested by Glen and Andreas
Revision ChangesPath
No revision
No revision
1.1.2.6 +3 -3 xml-fop/src/java/org/apache/fop/layoutmgr/Attic/AbstractBreaker.java
Index: AbstractBreaker.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/layoutmgr/Attic/AbstractBreaker.java,v
retrieving revision 1.1.2.5
retrieving revision 1.1.2.6
diff -u -r1.1.2.5 -r1.1.2.6
--- AbstractBreaker.java 26 Apr 2005 16:39:12 - 1.1.2.5
+++ AbstractBreaker.java 27 Apr 2005 15:59:59 - 1.1.2.6
@@ -96,7 +96,7 @@
return (blockLists.size() == 0);
}
-protected void startPart(BlockSequence list, int localPageNumber) {
+protected void startPart(BlockSequence list, boolean bIsFirstPage) {
//nop
}
@@ -202,7 +202,7 @@
System.out.println(PLM part: + (p + 1)
+ , break at position + endElementIndex);
-startPart(effectiveList, p+1);
+startPart(effectiveList, (p == 0));
int displayAlign = getCurrentDisplayAlign();
1.50.2.18 +8 -12 xml-fop/src/java/org/apache/fop/layoutmgr/PageSequenceLayoutManager.java
Index: PageSequenceLayoutManager.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/layoutmgr/PageSequenceLayoutManager.java,v
retrieving revision 1.50.2.17
retrieving revision 1.50.2.18
diff -u -r1.50.2.17 -r1.50.2.18
--- PageSequenceLayoutManager.java 26 Apr 2005 16:39:12 - 1.50.2.17
+++ PageSequenceLayoutManager.java 27 Apr 2005 15:59:59 - 1.50.2.18
@@ -193,7 +193,7 @@
addAreas(alg, partCount, originalList, effectiveList);
}
-protected void startPart(BlockSequence list, int localPageNumber) {
+protected void startPart(BlockSequence list, boolean bIsFirstPage) {
if (curPage == null) {
throw new IllegalStateException(curPage must not be null);
} else {
@@ -203,16 +203,12 @@
if (!firstPart) {
if (curFlowIdx curPage.getCurrentSpan().getColumnCount()-1) {
curFlowIdx++;
-} else if (localPageNumber == 1) {
-// this is the first page that will be created by
-// the current BlockSequence: it could have a break
-// condition that must be satisfied
-handleBreak(list.getStartOn());
-} else {
-// this is NOT the first page that will be created by
-// the current BlockSequence: we simply need a new
-// page
-handleBreak(Constants.EN_PAGE);
+} else {
+// if this is the first page that will be created by
+// the current BlockSequence, it could have a break
+// condition that must be satisfied;
+// otherwise, we simply need a new page
+handleBreak(bIsFirstPage ? list.getStartOn() : Constants.EN_PAGE);
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr AbstractBreaker.java PageSequenceLayoutManager.java
Oops...
--- Glen Mazza [EMAIL PROTECTED] wrote:
--- [EMAIL PROTECTED] wrote:
-protected void startPart(BlockSequence
list)
{
+protected void startPart(BlockSequence
list,
int localPageNumber) {
boolean isFirstPageByBlock is probably better.
The meaning of localPageNumber to indicate the
first
page created by a particular block I think will
cause
confusion,
will cause confusion I think...
Glen
RE: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr AbstractBreaker.java PageSequenceLayoutManager.java
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
--- [EMAIL PROTECTED] wrote:
-protected void startPart(BlockSequence list)
{
+protected void startPart(BlockSequence list,
int localPageNumber) {
boolean isFirstPageByBlock is probably better.
The meaning of localPageNumber to indicate the first
page created by a particular block I think will cause
confusion, especially when read within PSLM. Also,
since the logic only cares about whether or not the
page is the *first* page being rendered by the block,
a boolean would appear to better capture the usage of
this variable.
I agree with this reasoning, and can't seem to come up with situations where
the actual page-count for a given BlockSequence *would* be needed... (could
be that I'm overlooking something)
Along these same lines, the modifications to the code in PSLM would yield
the more compact:
...
} else {
// (comment on the following line of code)
handleBreak(isFirstByBlock ? list.getStartOn() : Constants.EN_PAGE);
}
...
Cheers,
Andreas
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr/list ListItemLayoutManager.java
I wrote:
Creating a combined list for label and body
I forgot to mention that this work is mainly based on Jeremias' code for
tables.
There is only a significant difference while computing the first step:
+if (backupHeights[0] == 0 backupHeights[1] == 0) {
+// this is the first step: choose the maximum increase, so that
+// the smallest area in the first page will contain at least
+// a label area and a body area
+step = Math.max((end[0] = start[0] ? partialHeights[0] :
Integer.MIN_VALUE),
+(end[1] = start[1] ? partialHeights[1] :
Integer.MIN_VALUE));
+} else {
+// this is not the first step: choose the minimum increase
+step = Math.min((end[0] = start[0] ? partialHeights[0] :
Integer.MAX_VALUE),
+(end[1] = start[1] ? partialHeights[1] :
Integer.MAX_VALUE));
+}
I'm not sure whether it's explicitly stated somewhere in the
recommendation or not, but it would seem very strange to me if a page
break could separate the label from the body.
Do you agree?
Regards
Luca
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr FlowLayoutManager.java
Glen Mazza wrote: Hi Luca, 1.) Can the corresponding setting of these values on fo:root (642-643 of [1]) in PSLM now be removed? (I think so...because what is set on fo:flow will be used instead of fo:root.) I agree with you. The method LengthBase.getBaseLength() (which is called by PercentLength.getNumericValue(), called by NumericOp methods, called for examply by LabelEndFunction.eval()) searches the nearest FObj ancestor, and fo:flow will always be nearer than fo:root. 2.) Also, does your change below need to be added to StaticContentLayoutManager as well? I think so, even if I see that before the branch the StaticContentLM did not have these lines (while FlowLM had them). I did not try and look what happens setting layout dimensions in the StaticContentLM, as at the moment I still have some things to do concerning lists; but I could add this to my to-do list. Regards Luca
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr FlowLayoutManager.java
Hi Luca, 1.) Can the corresponding setting of these values on fo:root (642-643 of [1]) in PSLM now be removed? (I think so...because what is set on fo:flow will be used instead of fo:root.) 2.) Also, does your change below need to be added to StaticContentLayoutManager as well? Many thanks, Glen [1] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/layoutmgr/PageSequenceLayoutManager.java?view=annotate#642 --- [EMAIL PROTECTED] wrote: +// set layout dimensions + fobj.setLayoutDimension(PercentBase.BLOCK_IPD, context.getRefIPD()); + fobj.setLayoutDimension(PercentBase.BLOCK_BPD, context.getStackLimit().opt); +
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr BlockLayoutManager.java BlockStackingLayoutManager.java BlockContainerLayoutManager.java
Luca, I'd prefer if we wouldn't have to have this many casts to Block and BlockContainer all over the LM. Couldn't we just add methods like getBlockFO() and getBlockContainerFO() which do the cast? I can do this but I don't want to interfere with anything you might do in those LMs right now. BTW, would you do me a favor and add a more verbose explanation of LayoutManager.getChangedKnuthElements(). That is one method I still don't fully understand. What does changed mean in this context? Is getChangedKnuthElements() really the best method name for it? Thanks a lot! On 07.04.2005 18:13:54 lfurini wrote: lfurini 2005/04/07 09:13:54 Modified:src/java/org/apache/fop/layoutmgr Tag: Temp_KnuthStylePageBreaking BlockLayoutManager.java BlockStackingLayoutManager.java BlockContainerLayoutManager.java Log: Moved methods from BlockLM to BlockStackingLM, modified parameters; these methods will be used by other subclasses of BlockStackingLM. Jeremias Maerki
Re: cvs commit: xml-fop/src/java/org....
Jeremias,
I do not fully understand the business logic for
tables--so what I am saying here may not be relevant.
But if cell should *never* be null (i.e., the caller
of this method is very sloppily written), please let
the methods NPE, raise IndexOutOfBoundsError,
InvalidStateException, etc., so we can immediately be
informed of the caller's incompetence at the point of
error and work on that right away.
Make sure we don't quietly return null so that the
problem will resurface several classes further
downstream where it presumably would be much harder to
track. If we have to put a temporary band-aid in,
best to put it with caller (i.e., have it not call the
method if cell is null), not the callee.
Thanks,
Glen
--- [EMAIL PROTECTED] wrote:
+public BorderInfo
getOriginalBorderInfoForCell(int side) {
+if (cell != null) {
+return
cell.getCommonBorderPaddingBackground().getBorderInfo(side);
+} else {
+return null;
+}
+}
Should empty table-cells throw NPE? (was Re: cvs commit: xml-fop/src/java/org....)
As I stated in a previous post, I'm not convinced that throwing an NPE
is the best choice. At the very least (IMO) this should be configurable
(and again IMO, it should default to WARN instead of ERROR).
Web Maestro Clay
On Apr 7, 2005, at 9:07 AM, Glen Mazza wrote:
Jeremias,
I do not fully understand the business logic for
tables--so what I am saying here may not be relevant.
But if cell should *never* be null (i.e., the caller
of this method is very sloppily written), please let
the methods NPE, raise IndexOutOfBoundsError,
InvalidStateException, etc., so we can immediately be
informed of the caller's incompetence at the point of
error and work on that right away.
Make sure we don't quietly return null so that the
problem will resurface several classes further
downstream where it presumably would be much harder to
track. If we have to put a temporary band-aid in,
best to put it with caller (i.e., have it not call the
method if cell is null), not the callee.
Thanks,
Glen
--- [EMAIL PROTECTED] wrote:
+public BorderInfo
getOriginalBorderInfoForCell(int side) {
+if (cell != null) {
+return
cell.getCommonBorderPaddingBackground().getBorderInfo(side);
+} else {
+return null;
+}
+}
Web Maestro Clay
--
[EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java
Not an objection but a concern: I get the impression that more an more logic wanders off into the area package which should IMO only be a data structure plus serialization/deserialization and reference resolution. And I believe that column balancing is clearly the LMs responsibility. Especially with the Knuth approach this can't even be done otherwise. I don't know what the others think. On 30.03.2005 02:49:08 Glen Mazza wrote: Team, I'd like to recommend next that we move the initialization (*not* population) of the page-reference-areas, region-viewport-areas, and region-reference-areas from PSLM to area.PageViewport (and possibly some in area.RegionViewport). IOW, everything from line 685 to the end of the file gone[1], with the remaining few lines of createPageAreas() moved to makeNewPage(). This is all boilerplate routine setup--predefined margin widths, etc-- independent of layout mechanisms, and I suspect this work can be more cleanly and orderly implemented in area.PageViewport anyway. Replacing this logic in PSLM eventually will be more flow-mapping logic, both of the future fo:flow-map and even our current 1.0 requirements to be able to place fo:flow data into any of the region areas. (Perhaps the column balancing as well, if the Span object cannot handle it by itself.) This is more of PSLM's responsibilities, and it will be quite large enough in accomplishing all of them. But PSLM should more or less be able to just call curPage = new PageViewport(), and get a PageViewport with already initialized child region areas. The coding to create this IMHO will be a distraction if kept in PSLM. Any objections? Thanks, Glen [1] http://tinyurl.com/4qca3 --- [EMAIL PROTECTED] wrote: gmazza 2005/03/29 16:06:30 Modified:src/java/org/apache/fop/area Tag: Temp_KnuthStylePageBreaking PageViewport.java src/java/org/apache/fop/layoutmgr Tag: Temp_KnuthStylePageBreaking PageSequenceLayoutManager.java Log: Removed the curSpan instance variable -- now obtainable via curPage. Jeremias Maerki
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java StaticContentLayoutManager.java
Sorry, but I don't get it. Please do the changes you propose, probably I
will understand then. Are there any layoutengine tests that you could
write to illustrate this?
On 19.03.2005 08:24:15 Glen Mazza wrote:
This is old code, but it should really be
layoutSideRegion()/RegionOuter(), correct? The
purpose of this method is for regions that don't have
columns, i.e., any region except fo:region-body.
fo:static-content can be directed anywhere, including
fo:region-body. (Although PSLM currently raises an
exception if the fo:page-sequence's fo:flow is not
directed to the fo:region-body, but actually I don't
think there is anything wrong with that.) I can make
the change IIC here.
Thanks,
Glen
--- [EMAIL PROTECTED] wrote:
private void layoutStaticContent(int
regionID) {
-Region reg =
currentSimplePageMaster.getRegion(regionID);
+RegionOuter reg =
(RegionOuter)currentSimplePageMaster.getRegion(regionID);
Jeremias Maerki
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
