DO NOT REPLY [Bug 41954] - AWT Renderer fails with heap memory error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41954





--- Additional Comments From [EMAIL PROTECTED]  2007-03-26 16:47 ---
Created an attachment (id=19809)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19809&action=view)
Complete test source code.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 41954] - AWT Renderer fails with heap memory error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41954





--- Additional Comments From [EMAIL PROTECTED]  2007-03-26 16:47 ---
Created an attachment (id=19808)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19808&action=view)
Image included in the test


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 41954] - AWT Renderer fails with heap memory error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41954





--- Additional Comments From [EMAIL PROTECTED]  2007-03-26 16:46 ---
Created an attachment (id=19807)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19807&action=view)
XML input data.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 41954] - AWT Renderer fails with heap memory error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41954





--- Additional Comments From [EMAIL PROTECTED]  2007-03-26 16:46 ---
Created an attachment (id=19806)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19806&action=view)
XSL-FO which formats the page.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 41954] - AWT Renderer fails with heap memory error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41954





--- Additional Comments From [EMAIL PROTECTED]  2007-03-26 16:45 ---
Created an attachment (id=19805)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19805&action=view)
Example PDF output produced from the code.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 41954] New: - AWT Renderer fails with heap memory error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41954

   Summary: AWT Renderer fails with heap memory error
   Product: Fop
   Version: 0.93
  Platform: PC
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: awt renderer
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


The attached code fails with the following trace on the AWT Renderer. All the
other pieces of code execute and produce the correct output (PDF etc). However,
the AWT Renderer displays the print preview window, with 'Generating' in the
status bar at the bottom, and then the following exception is reported.

27-Mar-2007 00:43:55 org.apache.fop.render.java2d.Java2DRenderer getPageImage
INFO: Rendering Page 1 (pageWidth 595, pageHeight 842)
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap 
space
at java.awt.image.DataBufferInt.(DataBufferInt.java:41)
at java.awt.image.Raster.createPackedRaster(Raster.java:458)
at
java.awt.image.DirectColorModel.createCompatibleWritableRaster(DirectColorModel.java:1015)
at java.awt.image.BufferedImage.(BufferedImage.java:321)
at
org.apache.fop.render.java2d.Java2DRenderer.getBufferedImage(Java2DRenderer.java:376)
at
org.apache.fop.render.java2d.Java2DRenderer.getPageImage(Java2DRenderer.java:317)
at
org.apache.fop.render.java2d.Java2DRenderer.getPageImage(Java2DRenderer.java:404)
at
org.apache.fop.render.awt.viewer.ImageProxyPanel.paintComponent(ImageProxyPanel.java:124)
at javax.swing.JComponent.paint(JComponent.java:1022)
at javax.swing.JComponent.paintChildren(JComponent.java:859)
at javax.swing.JComponent.paint(JComponent.java:1031)
at javax.swing.JComponent.paintChildren(JComponent.java:859)
at javax.swing.JComponent.paint(JComponent.java:1031)
at javax.swing.JViewport.paint(JViewport.java:747)
at javax.swing.JComponent.paintChildren(JComponent.java:859)
at javax.swing.JComponent.paint(JComponent.java:1031)
at javax.swing.JComponent.paintToOffscreen(JComponent.java:5104)
at
javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:285)
at javax.swing.RepaintManager.paint(RepaintManager.java:1132)
at javax.swing.JComponent._paintImmediately(JComponent.java:5052)
at javax.swing.JComponent.paintImmediately(JComponent.java:4862)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:727)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:683)
at 
javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:663)
at
javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:128)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
at 
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
java.lang.IllegalArgumentException: Printing cancelled by operator
at
org.apache.fop.render.print.PrintRenderer.initializePrinterJob(PrintRenderer.java:91)
at 
org.apache.fop.render.print.PrintRenderer.(PrintRenderer.java:63)
at
org.apache.fop.render.print.PrintRendererMaker.makeRenderer(PrintRendererMaker.java:37)
at 
org.apache.fop.render.RendererFactory.createRenderer(RendererFactory.java:186)
at org.apache.fop.area.RenderPagesModel.(RenderPagesModel.java:70)
at 
org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:146)
at org.apache.fop.area.AreaTreeHandler.(AreaTreeHandler.java:123)
at
org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:236)
at org.apache.fop.fo.FOTreeBuilder.(FOTreeBuilder.java:98)
at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:147)
at org.apache.fop.apps.Fop.(Fop.java:82)
at org.apache.fop.apps.FopFactory.newFop(FopFactory.java:227)
at TestFOP.FOPIt(TestFOP.java:123)
at TestFOP.main(TestFOP.java:78)
27-Mar-2007 00:44:09 org.apache.fop.render.java2d.Java2DRenderer getPageImage
INFO: Rendering Page 1 (pageWidth 595, pageHeight 842)
Exception in thread "AWT-EventQueue-0" java.la

DO NOT REPLY [Bug 41831] - [PATCH] Refactored configuration, font detection and caching, url resolution

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41831





--- Additional Comments From [EMAIL PROTECTED]  2007-03-26 16:09 ---
Hi Andreas,

Many thanks for reviewing and taking care of commiting my patch.  I realise you
guys are very busy and I really appreciate you finding the time to thoroughly
review my large patch and provide me with feedback :-).  I don't think I will be
making any more minor tweaks to this patch at this time as I am busy working on
resolving some issues with the postscript renderer.

Of course if anything crops up after the commit I will be more than happy to
look at it.  I very much look forward to seeing the new features I've added
being part of the FOP trunk :-).

All the best,

Adrian Cumiskey.

(In reply to comment #15)
> Adrian,
> 
> Just to keep you up to date: I'm almost done here. Apart from the nits
mentioned earlier, everything looks 
> A-OK to me. I'll wrap things up later this week, and will then first attach a
slightly revised patch here. If it 
> meets with your approval, then it will most likely get committed by the 
> weekend.
> 
> Thanks again for this fine contribution!
> 
> Andreas

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 41952] - Extents not rendered at specified sizing.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41952





--- Additional Comments From [EMAIL PROTECTED]  2007-03-26 15:13 ---
Created an attachment (id=19804)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19804&action=view)
The image used in the test.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 41952] - Extents not rendered at specified sizing.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41952





--- Additional Comments From [EMAIL PROTECTED]  2007-03-26 15:13 ---
Created an attachment (id=19803)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19803&action=view)
The rendered output in PDF.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 41952] - Extents not rendered at specified sizing.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41952





--- Additional Comments From [EMAIL PROTECTED]  2007-03-26 15:12 ---
Created an attachment (id=19802)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19802&action=view)
The XSL-FO used to create the page.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 41952] New: - Extents not rendered at specified sizing.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41952

   Summary: Extents not rendered at specified sizing.
   Product: Fop
   Version: 0.93
  Platform: PC
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: general
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


In the fo example given the before extent is given at 32mm, and the body-region
has a margin top of 32mm.

As I understand it the extent of the before region should be 32mm. Inside the
border (0.25mm) the image should have been scaled, and therefore the top and
bottom of the image border should be snug up against the border for the region.

The top border of the body region should be snug up to (but not overlapping) the
before region.

As can be seen it renders incorrectly in postscript and PDF.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 41951] - External graphic doesnt size properly with height set at 100%

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41951





--- Additional Comments From [EMAIL PROTECTED]  2007-03-26 15:02 ---
Created an attachment (id=19801)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19801&action=view)
The image used in the test.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 41951] - External graphic doesnt size properly with height set at 100%

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41951





--- Additional Comments From [EMAIL PROTECTED]  2007-03-26 15:02 ---
Created an attachment (id=19800)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19800&action=view)
The rendered output in PDF.

Both PDF and PS render the same.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 41951] New: - External graphic doesnt size properly with height set at 100%

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41951

   Summary: External graphic doesnt size properly with height set at
100%
   Product: Fop
   Version: 0.93
  Platform: PC
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: general
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


The following XSL-FO causes a complaint about the graphics being out of limits
and DOES NOT render at the scaled size. The specification states that a height
of 100% should cause the area to be set at the same size of the parent (which
should be the size of extent in this case.


http://www.w3.org/1999/XSL/Format";>

















LOGO CHECK







-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: Percentages in CommonAbsolutePosition?

[Andreas L Delmelle]

On Mar 26, 2007, at 11:47, [EMAIL PROTECTED] wrote:

If I understand you correctly, what you're saying is that if the  
fixed
positioned block's nearest ref-area is not initially visible, then  
the
top/left/etc. properties should be taken WRT the region-viewport- 
area?


Almost... What I'm saying is that if the fixed-positioned block's  
nearest ancestor reference area is not visible, then the viewport- 
area will also not be visible. I've been searching around, but  
could not immediately find an example of a situation where a  
reference-area is established without an accompanying viewport- 
area. Regular fo:blocks generate normal block areas, which are not  
reference-areas...


Diving into the viewport/reference-area relation some more, I think  
what I could as well have said from the beginning was:
If the nearest ancestor reference area is the region-reference-area,  
then the position of a fixed-positioned area in the viewport is  
initially identical to that of an absolute-positioned area.


By means of an example, if you have:


  
  ...
  
  ...

  Rest of block


Then the areas corresponding to the block-containers will be  
positioned at the resolved coördinates in the nearest ancestor  
reference area, whatever that is. In this case, the same top,  
slightly different left.
My point: Even if the rest of the block's content gets clipped or  
even if the content gets clipped somewhere way above the block, both  
block-containers should still be rendered at the specified  
coördinates in the reference-area and so, initially also in the  
viewport-area.
Those coördinates specify an absolute position in the reference-area  
for absolute-position="absolute" and a fixed position in the  
accompanying viewport-area for absolute-position="fixed".


See the light? I don't think it overcomplicates the situation, quite  
on the contrary. To the renderers, maybe, since many of them need to  
process that "relative-absolute" position into one that maps to  
absolute positions on the page...



Cheers,

Andreas

DO NOT REPLY [Bug 41831] - [PATCH] Refactored configuration, font detection and caching, url resolution

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41831





--- Additional Comments From [EMAIL PROTECTED]  2007-03-26 14:09 ---
Adrian,

Just to keep you up to date: I'm almost done here. Apart from the nits 
mentioned earlier, everything looks 
A-OK to me. I'll wrap things up later this week, and will then first attach a 
slightly revised patch here. If it 
meets with your approval, then it will most likely get committed by the weekend.

Thanks again for this fine contribution!

Andreas

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: More on border and padding conditionalities

[Andreas L Delmelle]

On Mar 26, 2007, at 16:48, Vincent Hennebert wrote:

Hi Vincent,


I'm having a lot of fun playing with border and padding
conditionalities...


I think the padding should actually not be discarded on the second  
page.

It would if the corresponding edge were a leading edge in the
region-body's reference area. However, it is not because there is no
stacking constraint between the inner block's area and the (region
body's) ref-area. Because the retained border on that inner block
creates a fence which prevents rule 3.b (XSL 1.1, 4.2.5) to apply.


Just a sanity check: aren't you confusing padding-* with space-* here?

Comparing FO to PDF, my common sense jumps up and says:
"Why do you expect the padding to be retained at page-breaks, when  
specifying .conditionality='discard'?"



Cheers,

Andreas

Re: Border conditionalities and collapsing-border model, breaks on header/footer

[Andreas L Delmelle]

On Mar 26, 2007, at 11:31, Vincent Hennebert wrote:



And there is a remaining question raised by Andreas:


[me:]

If the table is broken across several pages and the header shall be
replicated, do
border-before for table and table-column play again in border- 
resolution

for the second and following headers?

[Andreas:]

YES! Not only border-before even, I think, but that is open for
interpretation. The column's border-before *and* after need to be
considered for each body, header/footer that appears on a given page.

One could also argue that the column's span the entire table for each
page, so the column's border-after does not need to be considered for
the header's last row, for instance.


Interesting point of vue. I think it can be summarized by the attached
picture. Jeremias' position corresponds to 1., and I suspect this  
is the

more common understanding. Andreas' is 2., but I'm afraid you'll be
alone ;-) Mine's tends to be 3., although I'm ok with 1.

If there is no other comment I'll go with 1.


1. is also fine with me. As I said, it's open for interpretation, and  
I would agree that option 1. is what the largest part of our audience  
will expect.


In a way, in the majority of use-cases option 2. /almost/ gives the  
same result as 1.
It would only give slightly different results if the column's after- 
border is different from the before-border. I think you'll have to  
look hard for cases where people specify different border-specs for  
the two opposite sides, but as you say: nothing prevents people from  
achieving weird effects. :-)



Cheers,

Andreas

More on border and padding conditionalities

[Vincent Hennebert]

Hi all,

I'm having a lot of fun playing with border and padding
conditionalities... What do you think of the attached fo file (resulting
pdf also attached)?

I think the padding should actually not be discarded on the second page.
It would if the corresponding edge were a leading edge in the
region-body's reference area. However, it is not because there is no
stacking constraint between the inner block's area and the (region
body's) ref-area. Because the retained border on that inner block
creates a fence which prevents rule 3.b (XSL 1.1, 4.2.5) to apply.

The funny thing is that if there were no outer block, then there /would/
be a stacking constraint (rule 1 this time), and we would end up with an
area with border-before but no padding-before. I can expect many
headaches from users about that...

WDYT?
Vincent

http://www.w3.org/1999/XSL/Format";>
  

  

  
  

  Some text. Some text. Some text. Some text. Some text. Some text.
Some text. Some text. Some text. Some text. Some text. Some text. Some
  text. Some text. Some text. Some text. Some text. Some text. Some text. Some text. Some text. Some text. Some
  text. Some text.

  

  



border-padding_conditionality.pdf
Description: Adobe PDF document

Re: Footnotes in the float branch

[Luca Furini]

On Mon, 26 Mar 2007, Luca Furini wrote:


I'm attaching a diff file showing the changes 


Well, *now* I'm attaching bla bla :-)

Regards
LucaIndex: src/java/org/apache/fop/layoutmgr/breaking/FootnotesRecord.java
===
--- src/java/org/apache/fop/layoutmgr/breaking/FootnotesRecord.java 
(revision 521755)
+++ src/java/org/apache/fop/layoutmgr/breaking/FootnotesRecord.java 
(working copy)
@@ -91,6 +91,21 @@
 addSeparator();
 }
 }
+
+/**
+ * 
+ */
+public void handleDeferredFootnotes(int requestedLastIndex) {
+   boolean separatorAlreadyAdded = (alreadyInserted.getLength() > 
0);
+   // check if we must add more footnotes
+   while (lastInsertedIndex < requestedLastIndex) {
+   next();
+   }
+   // if needed, add the separator
+   if (!separatorAlreadyAdded && alreadyInserted.getLength() > 0) {
+   addSeparator();
+   }
+}
 
 /**
  * If the current page is a float-only page, handles the splitting of 
the last
Index: src/java/org/apache/fop/layoutmgr/BreakingAlgorithm.java
===
--- src/java/org/apache/fop/layoutmgr/BreakingAlgorithm.java(revision 
521755)
+++ src/java/org/apache/fop/layoutmgr/BreakingAlgorithm.java(working copy)
@@ -545,6 +545,17 @@
 log.debug("Could not find a set of breaking points " + 
threshold);
 return 0;
 }
+// lastDeactivated was a "good" break, while lastTooShort and 
lastTooLong 
+// were "bad" breaks since the beginning;
+// if it is not the node we just restarted from, 
lastDeactivated can 
+// replace either lastTooShort or lastTooLong
+if (lastDeactivated != null && lastDeactivated != lastForced) {
+if (lastDeactivated.adjustRatio > 0) {
+lastTooShort = lastDeactivated;
+} else {
+lastTooLong = lastDeactivated;
+}
+}
 if (lastTooShort == null || lastForced.position == 
lastTooShort.position) {
 if (isPartOverflowRecoveryActivated()) {
 if (this.lastRecovered == null) {
Index: src/java/org/apache/fop/layoutmgr/inline/TextLayoutManager.java
===
--- src/java/org/apache/fop/layoutmgr/inline/TextLayoutManager.java 
(revision 521755)
+++ src/java/org/apache/fop/layoutmgr/inline/TextLayoutManager.java 
(working copy)
@@ -1285,7 +1285,12 @@
 (new KnuthGlue(lineStartBAP, 0, 0,
new LeafPosition(this, -1), false));
 } else {
+// the first penalty is necessary in order to avoid the glue 
to be a feasible break
+// while we are ignoring hyphenated breaks
 hyphenElements.add
+(new KnuthPenalty(0, KnuthElement.INFINITE, false,
+new LeafPosition(this, -1), false));
+hyphenElements.add
 (new KnuthGlue(0, 3 * 
LineLayoutManager.DEFAULT_SPACE_WIDTH, 0,
 new LeafPosition(this, -1), false));
 hyphenElements.add
Index: src/java/org/apache/fop/layoutmgr/PageBreakingAlgorithm.java
===
--- src/java/org/apache/fop/layoutmgr/PageBreakingAlgorithm.java
(revision 521755)
+++ src/java/org/apache/fop/layoutmgr/PageBreakingAlgorithm.java
(working copy)
@@ -77,7 +77,7 @@
 /**
  * Are footnotes-only pages allowed?
  */
-public static final boolean FOOTNOTES_ONLY_PAGES_ALLOWED = true;
+public static final boolean FOOTNOTES_ONLY_PAGES_ALLOWED = false;
 
 /**
  * Additional demerits for an underfull page, which however has an 
acceptable fill ratio.
@@ -115,6 +115,14 @@
 private BeforeFloatsRecord beforeFloatsRecord;
 private FootnotesRecord.FootnotesProgress footnotesProgress;
 private BeforeFloatsRecord.BeforeFloatsProgress beforeFloatsProgress;
+// number of new footnotes met since the last feasible break
+private int newFootnotesCount = 0;
+// the method noBreakBetween(int, int) uses these variables 
+// to store parameters and result of the last call, in order
+// to reuse them and take less time
+private int storedPrevBreakIndex = -1;
+private int storedBreakIndex = -1;
+private boolean storedValue = false;
 
 private ActiveNodeRecorder activeNodeRecorder = new ActiveNodeRecorder();
 
@@ -682,6 +690,7 @@
 if (box instanceof KnuthBlockBox
 

Footnotes in the float branch

[Luca Furini]

Hi all

I recently had the time (and the pleasure) to look at before-float 
implementation branch, and I played a bit with it.


I focused on the handling of footnotes, as I noticed that sometimes they 
were placed on a page following their citations without a real necessity 
to do it; as I wrote some time ago (and I rememeber there was some 
consesuns on this) this behaviour is acceptable for before floats, but is 
probably not what a user would expect for footnotes.


I have tried to fix this in the PageBreakingAlgorithm, computing a 
"minimum required index" for footnotes, so that no page break will be 
considered that unnecessarily defers some old footnotes to the next page.


I'm attaching a diff file showing the changes (or maybe should I just 
apply it?); after applying the patch, there are 4 more passing testcases 
(foonote_footnote-separator, footnote_large, footnote_positioning_{4,5}) 
and no regressions. Testcases footnote_positioning_{2,3} still generate 
some run-time exception, and in the next days I'm going to see what's 
wrong with them.


I add just a few comments about the new classes: I must admit that it took 
me a while to see and understand the interaction between the 
PageBreakingAlgorithm and the Footnotes / BeforeFloats Record, together 
with their inner Footnotes / BeforeFloats Progress.


In particular, at the beginning I thought the *Progress classes were just 
convenience classes to get "pieces" of footnotes and floats without 
directly fiddling with element lists, and I found only later that their 
methods can actually create new active nodes.


Another thing that I find a bit strange is that the PageBreakingAlgorithm 
does not directly interact with the before floats, as the calls to 
BeforeFloatsProgress.consider() are "hidden" in the FootnotesProgress 
class.


So, I was wondering whether it wouldn't be more "clear" to have the 
PageBreakingAlgorit control all the node creation logic, after having 
accessed information about footnotes and floats that could be placed in 
the page via the helper classes.


WDYT?

Regards
Luca

Re: Percentages in CommonAbsolutePosition?

[a_l . delmelle]

>- Oorspronkelijk bericht -
>Van: Vincent Hennebert [mailto:[EMAIL PROTECTED]

Hi Vincent,


>> OK, take the region-body as an example, with overflowing content and a
>> fixed-positioned block-container that is a descendant of a block that
>> initially falls outside the region-viewport, and thus is not immediately
>> visible. Same as an absolute-positioned block-container, it will appear
>> at a certain position in the region-viewport-area (regardless of where
>> it was specified, or whether the containing block is visible or not).
>
>If I understand you correctly, what you're saying is that if the fixed
>positioned block's nearest ref-area is not initially visible, then the
>top/left/etc. properties should be taken WRT the region-viewport-area?

Almost... What I'm saying is that if the fixed-positioned block's nearest 
ancestor reference area is not visible, then the viewport-area will also not be 
visible. I've been searching around, but could not immediately find an example 
of a situation where a reference-area is established without an accompanying 
viewport-area. Regular fo:blocks generate normal block areas, which are not 
reference-areas...

>I would really not agree with that. Besides the fact that that would
>complicate the implementation, I think that if the fixed area turns out
>to not be visible, then it will never be. Anyway if you give arbitrarily
>great values to top/left/etc. you /will/ get an area that lies outside
>the viewport-area, regardless of the value of the overflow property.

Indeed, that was a situation I conveniently left out of scope for now, but this 
is also possible and legitimate.

Cheers,

Andreas

Re: Border conditionalities and collapsing-border model, breaks on header/footer

[Vincent Hennebert]

Hi,

Thanks for your inputs, Andreas and Jeremias.

The whole thing suddenly makes sense when you think in terms of area
tree instead of fo tree...
Still, I think it's not obvious by reading the spec and I'll probably
ask for clarification on [EMAIL PROTECTED]

And there is a remaining question raised by Andreas:


[me:]
>> If the table is broken across several pages and the header shall be
>> replicated, do
>> border-before for table and table-column play again in border-resolution
>> for the second and following headers?
[Andreas:]
> YES! Not only border-before even, I think, but that is open for
> interpretation. The column's border-before *and* after need to be
> considered for each body, header/footer that appears on a given page.
> 
> One could also argue that the column's span the entire table for each
> page, so the column's border-after does not need to be considered for
> the header's last row, for instance.

Interesting point of vue. I think it can be summarized by the attached
picture. Jeremias' position corresponds to 1., and I suspect this is the
more common understanding. Andreas' is 2., but I'm afraid you'll be
alone ;-) Mine's tends to be 3., although I'm ok with 1.

If there is no other comment I'll go with 1.


> Apart from that, there is the tiny note, of course, that we're talking
> about hypothetical situations, in which border-conditionality is
> overridden for all table-elements.
> The default value being "discard" makes the interplay between
> border-collapse and border-conditionality actually much simpler than it
> seems at first...
> 
>> 
 - when we break at a grid line, should the two rows meeting a the line
   count in border resolution? Or only the row before for the
   border-after at the end of the page, and the row after for the
   border-before at the beginning of the following page?
   I would go with that latter.
>>>
>>> That's right.
>>
>> Fine (that means that the border may potentially be different at the
>> bottom of the previous page and at the top of the next page).
> 
> Only if you have no header/footer. If there is a repeated header/footer,
> then the border will neatly be the same for all pages. If you have no
> header or footer, then overriding border-*-width.conditionality on the
> table or table-body is enough to prevent weird effects.

Still, nothing prevents users from trying to achieve those weird effects ;-)


 - when we break at a grid line, should the entire border appear on each
   page, or the higher half at the bottom of the first page, and the
   lower half at the top of the following page?
   I would also go with that latter.
>>>
>>> No, the entire border has to be painted. This is
>>> BorderProps.COLLAPSE_OUTER/COLLAPSE_INNER as used by the renderers. See
>>> the BorderProps class.
>>
>> So the grid line at the page break would have two borders, one at the
>> bottom of the page, one at the top of the next page?
>> That's fine for me, but again I think it's specified nowhere.
> 
> Hmm... not exactly. Think of the part of the table on one page as an
> independent subgrid, that has nothing to do anymore with the preceding
> or following subgrid. It is the gridline which is split in two, and each
> of the new gridlines will have one fully resolved border. In a sense the
> border is duplicated, yes... :/

I'm ok with that now :-)


Thanks,
Vincent

Re: Percentages in CommonAbsolutePosition?

[Vincent Hennebert]

Hi Andreas,

Andreas L Delmelle a écrit :
> On Mar 23, 2007, at 11:22, Vincent Hennebert wrote:
> 
>> Thanks for your perseverance ;-)
> 
> You're welcome. :o)

I'm sure we will manage!


>>> 
>>> If the nearest ancestor ref-area is not immediately visible, then I
>>> think this implies that the fixed-area's position is definitely not
>>> relative to the viewport you refer to, but to another nested viewport.
>>
>> Then which one? If there is no block-container in the flow, then the
>> only viewport area is the region-body. And my question remains...
> 
> OK, take the region-body as an example, with overflowing content and a
> fixed-positioned block-container that is a descendant of a block that
> initially falls outside the region-viewport, and thus is not immediately
> visible. Same as an absolute-positioned block-container, it will appear
> at a certain position in the region-viewport-area (regardless of where
> it was specified, or whether the containing block is visible or not).

If I understand you correctly, what you're saying is that if the fixed
positioned block's nearest ref-area is not initially visible, then the
top/left/etc. properties should be taken WRT the region-viewport-area?
I would really not agree with that. Besides the fact that that would
complicate the implementation, I think that if the fixed area turns out
to not be visible, then it will never be. Anyway if you give arbitrarily
great values to top/left/etc. you /will/ get an area that lies outside
the viewport-area, regardless of the value of the overflow property.


> For our current output-targets, the story ends here, because there is no
> scrolling. Note that an absolute-positioned block-container will always
> appear, even if the containing block ends up on a part that is clipped
> (never visible).
> 
> OTOH, if the fixed-positioned block-container is enclosed by a regular
> one, then its initial visibility depends on the initial visibility of
> the regular block-container, precisely because the regular
> block-container establishes a new viewport/reference-area pair. The
> fixed-positioned one will appear as a static part in that new viewport
> once it becomes visible.

Now I'm starting to see what you mean. While it makes perfectly sense to
me, I'm almost sure this wasn't the intent of the authors when they
wrote the description of "fixed". Moreover there would then be little
difference with "absolute".


>>> 
 As the idea is probably to mimic the "absolute" and "fixed" value for
 "position" in CSS2, I think the description of "fixed" should not refer
 to the one of "absolute" for placing areas. They should have written
 something like "These properties specify offsets with respect to the
 page's viewport area".
>>>
>>> The term "page" seems too narrow here. Your suggestion would only cover
>>> the case of absolute- or fixed-positioned areas whose nearest ancestor
>>> ref-area is the page-area.
>>
>> No, what I was saying is that the position would be computed WRT to the
>> ancestor page-area (more precisely, the region-reference-area) instead
>> of the nearest ancestor ref-area, whatever it is.
> 
> Why? I think that would actually make it more difficult than it is now,
> since a nested block-container would then also need to get at the
> containing page, whereas now it is enough to stop at the first
> block-container that establishes the reference area.

Well, yes. Although I'm not sure which one would actually be more
complicated to implement. Also, the following sentence in the
description of "fixed": "In the case of paged media, the area is fixed
with respect to the page" seems to go in that direction.

Cheers,
Vincent