cvs commit: xml-fop/src/java/org/apache/fop/fo FONode.java
pbwest 2004/02/01 00:12:00
Modified:src/java/org/apache/fop/area/inline Tag:
FOP_0-20-0_Alt-Design InlineArea.java
InlineContainer.java
src/java/org/apache/fop/area Tag: FOP_0-20-0_Alt-Design
BlockContainer.java BlockArea.java Area.java
src/java/org/apache/fop/datastructs Tag:
FOP_0-20-0_Alt-Design Node.java TNode.java
src/java/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design
FONode.java
Added: src/java/org/apache/fop/datastructs Tag:
FOP_0-20-0_Alt-Design SyncedNode.java
Log:
Revision ChangesPath
No revision
No revision
1.2.2.3 +4 -4 xml-fop/src/java/org/apache/fop/area/inline/InlineArea.java
Index: InlineArea.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/area/inline/InlineArea.java,v
retrieving revision 1.2.2.2
retrieving revision 1.2.2.3
diff -u -r1.2.2.2 -r1.2.2.3
--- InlineArea.java 1 Feb 2004 05:47:38 - 1.2.2.2
+++ InlineArea.java 1 Feb 2004 08:12:00 - 1.2.2.3
@@ -33,9 +33,9 @@
* @param index
* @throws IndexOutOfBoundsException
*/
-public InlineArea(Node parent, int index)
+public InlineArea(Node parent, int index, Object areaSync)
throws IndexOutOfBoundsException {
-super(parent, index);
+super(parent, index, areaSync);
// TODO Auto-generated constructor stub
}
@@ -43,8 +43,8 @@
* @param parent
* @throws IndexOutOfBoundsException
*/
-public InlineArea(Node parent) throws IndexOutOfBoundsException {
-super(parent);
+public InlineArea(Node parent, Object areaSync) throws
IndexOutOfBoundsException {
+super(parent, areaSync);
// TODO Auto-generated constructor stub
}
1.1.2.3 +7 -6
xml-fop/src/java/org/apache/fop/area/inline/Attic/InlineContainer.java
Index: InlineContainer.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/area/inline/Attic/InlineContainer.java,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- InlineContainer.java 1 Feb 2004 05:47:38 - 1.1.2.2
+++ InlineContainer.java 1 Feb 2004 08:12:00 - 1.1.2.3
@@ -33,9 +33,9 @@
* @param index
* @throws IndexOutOfBoundsException
*/
-public InlineContainer(Node parent, int index)
+public InlineContainer(Node parent, int index, Object areaSync)
throws IndexOutOfBoundsException {
-super(parent, index);
+super(parent, index, areaSync);
// TODO Auto-generated constructor stub
}
@@ -43,8 +43,9 @@
* @param parent
* @throws IndexOutOfBoundsException
*/
-public InlineContainer(Node parent) throws IndexOutOfBoundsException {
-super(parent);
+public InlineContainer(Node parent, Object areaSync)
+throws IndexOutOfBoundsException {
+super(parent, areaSync);
// TODO Auto-generated constructor stub
}
No revision
No revision
1.1.2.3 +7 -6 xml-fop/src/java/org/apache/fop/area/Attic/BlockContainer.java
Index: BlockContainer.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/area/Attic/BlockContainer.java,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- BlockContainer.java 1 Feb 2004 05:47:38 - 1.1.2.2
+++ BlockContainer.java 1 Feb 2004 08:12:00 - 1.1.2.3
@@ -32,9 +32,9 @@
* @param index
* @throws IndexOutOfBoundsException
*/
-public BlockContainer(Node parent, int index)
+public BlockContainer(Node parent, int index, Object areaSync)
throws IndexOutOfBoundsException {
-super(parent, index);
+super(parent, index, areaSync);
// TODO Auto-generated constructor stub
}
@@ -42,8 +42,9 @@
* @param parent
* @throws IndexOutOfBoundsException
*/
-public BlockContainer(Node parent) throws IndexOutOfBoundsException {
-super(parent);
+public BlockContainer(Node parent, Object areaSync)
+throws IndexOutOfBoundsException {
+super(parent, areaSync);
// TODO Auto-generated constructor stub
}
1.1.2.3 +8 -6 xml-fop/src/java/org/apache/fop/area/Attic/BlockArea.java
Index: BlockArea.java
===
RCS
cvs commit: xml-fop/build/tmp version.property
pbwest 2004/02/01 02:02:07 Removed: build/tmp Tag: FOP_0-20-0_Alt-Design version.property Log: This file is always generated by a build. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nasty layout bug: maint vs. HEAD
On Sun, Feb 01, 2004 at 03:06:24AM +0100, Andreas L. Delmelle wrote: -Original Message- To clear that up a bit further: If you run a document structured like this, but with many more page-sequences, through HEAD, the whole document will be divided into chunks of about 60 pages ( +/- the number of lines in the table-body of the TOC ), and in between you will find the TOC pages themselves. I have seen this problem too. The PDF renderer is able to render out of order, but from this bug it seems that the mechanism is broken. Could it be that the page is inserted at the point when all its forward references are resolved? At that point it is rendered, but the PDF renderer should insert it at the proper position. That does not seem to happen. Regards, Simon Pepping -- Simon Pepping home page: http://www.leverkruid.nl
RE: Nasty layout bug: maint vs. HEAD
-Original Message- From: Simon Pepping [mailto:[EMAIL PROTECTED] On Sun, Feb 01, 2004 at 03:06:24AM +0100, Andreas L. Delmelle wrote: -Original Message- To clear that up a bit further: If you run a document structured like this, but with many more page-sequences, through HEAD, the whole document will be divided into chunks of about 60 pages ( +/- the number of lines in the table-body of the TOC ), and in between you will find the TOC pages themselves. I have seen this problem too. The PDF renderer is able to render out of order, but from this bug it seems that the mechanism is broken. Could it be that the page is inserted at the point when all its forward references are resolved? At that point it is rendered, but the PDF renderer should insert it at the proper position. That does not seem to happen. Yup, that's exactly what it seemed like to me: a miscommunication between layout and renderer. (Mainly because I added some primitive logging messages to the version in my sandbox, I could see it 'happening' after the relevant code in the LM was executed.) And indeed, the first page containing the links appears right after the last page for which it contains the link, so at the point where all its forward refs are resolved. Thanks for the pointer. I'll surely have a closer look at that. (If you have any more ideas on this, I'll be glad to read about them). Cheers, Andreas
RE: Nasty layout bug: maint vs. HEAD
BTW: I ran a further test on a more extended version of the document ( TOC of 6 pages + 338 detail pages ) without the basic-links. 0.20.5 had no problems, while HEAD threw an OOM Error (both running with a max heap of 128MB). IMHO this would indicate that somehow the page-sequences aren't released anymore (?) I ran the same test with only two page-sequences: one for the TOC, the other for all 338 detail-pages. Memory seems to get maxed out at +/- the same point in the process. -Original Message- From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] -Original Message- From: Simon Pepping [mailto:[EMAIL PROTECTED] On Sun, Feb 01, 2004 at 03:06:24AM +0100, Andreas L. Delmelle wrote: I have seen this problem too. The PDF renderer is able to render out of order, but from this bug it seems that the mechanism is broken. Could it be that the page is inserted at the point when all its forward references are resolved? At that point it is rendered, but the PDF renderer should insert it at the proper position. That does not seem to happen. Yup, that's exactly what it seemed like to me: a miscommunication between layout and renderer. (Mainly because I added some primitive logging messages to the version in my sandbox, I could see it 'happening' after the relevant code in the LM was executed.) And indeed, the first page containing the links appears right after the last page for which it contains the link, so at the point where all its forward refs are resolved. Thanks for the pointer. I'll surely have a closer look at that. (If you have any more ideas on this, I'll be glad to read about them). Cheers, Andreas
Bug report for Fop [2004/02/01]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 635|Opn|Nor|2001-02-18|Doesn't support id= attribute in fo:page-sequence | | 953|Opn|Nor|2001-03-12|Incorrect hyperlinks area rendering in justified t| | 1063|New|Nor|2001-03-21|fop does not handle large fo files| | 1180|New|Maj|2001-04-02|Problem with monospaced font | | 1859|Opn|Min|2001-05-22|org.apache.fop.apps.Driver.reset() doesn't fully r| | 1998|New|Nor|2001-06-05|linefeed-treatment not understood | | 2150|Ass|Maj|2001-06-13|New page with a table-header but without any tabl| | 2475|Ass|Nor|2001-07-06|Borders don't appear to work in fo:table-row| | 2740|New|Maj|2001-07-23|multi-page tables sometimes render badly | | 2909|New|Maj|2001-07-30|Gradient render error | | 2964|Ass|Nor|2001-08-02|problems with height of cells in tables | | 2988|New|Maj|2001-08-03|0.19: list-item-label does not stick to list-item-| | 3044|Ass|Maj|2001-08-08|keep-together not functioning | | 3280|New|Nor|2001-08-27|PCL Renderer doesn't work | | 3305|Opn|Nor|2001-08-28|list-block overlapping footnote body | | 3497|New|Maj|2001-09-07|id already exists error when using span=all attr| | 3824|New|Blk|2001-09-25|MIF option with tables| | 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S| | 4126|New|Nor|2001-10-12|FontState.width() returns pts instead of millipts | | 4226|New|Nor|2001-10-17|The orphans property doesn't seem to work | | 4388|New|Nor|2001-10-24|Nullpointer exception in the construction of new D| | 4415|New|Nor|2001-10-25|scaling=uniform does not work on images... | | 4510|New|Nor|2001-10-30|fo:inline common properties ignored? | | 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG | | 4767|New|Nor|2001-11-09|SVG text is distored in PDF output| | 5001|New|Nor|2001-11-21|content-width and content-height ignored? | | 5010|New|Enh|2001-11-21|Better error reporting needed | | 5047|Ass|Nor|2001-11-23|Dotted border style is not supported | | 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using | | 5335|Opn|Min|2001-12-10|Text with embedded CID fonts not retrievable from | | 5655|Ass|Nor|2002-01-02|text-decoration cannot take multiple values | | 6094|Opn|Maj|2002-01-29|0.20.3rc hangs in endless loop| | 6237|Opn|Nor|2002-02-05|#xFB01 (fi ligature) produces a sharp? | | 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output| | 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem| | 6437|New|Maj|2002-02-13|Tables without fo:table-column don't render | | 6483|New|Nor|2002-02-15|Table, Loop, footer could not fit on page, moving| | 6844|New|Nor|2002-03-04|No line breaks inserted in list-item-label| | 6918|New|Enh|2002-03-06|reference-orientation has no effect | | 6929|New|Nor|2002-03-06|Cells border hidden by cells background | | 6997|New|Nor|2002-03-09|[PATCH] Row-spanned row data breaks over a page wi| | 7140|New|Enh|2002-03-15|page-position attribute set to last on condition| | 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on| | 7283|New|Nor|2002-03-20|Table border misaligned when using margin-left in | | 7337|New|Nor|2002-03-21|border around external image leaves empty space | | 7487|New|Nor|2002-03-26|break-before=page for table inserts empty page | | 7496|New|Nor|2002-03-26|The table header borders are not adjusted to the b| | 7525|New|Cri|2002-03-27|table with spans inside a list-block | | 7919|New|Cri|2002-04-10|problem to use attribute linefeed-treatment and li| | 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images | | 8050|New|Nor|2002-04-13|Soft hyphen (shy;) is not handled properly | |
Re: [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.
[Glen Mazza] Another option, Finn, is to move all the Property subclasses to fo.properties (even if they're alongside the makers, nested or unnested), after thinking about it, I think that will be a little bit clearer than having them in the datatype package. Comments? I like it. How does this sound: - Unnest Property.Maker to PropertyMaker and put it in fo.properties. - Roll the datatypes classes into their property class and move the property class to fo.properties (but without unnesting their Maker class because the remaining nested Maker classes are really trivial). - Move the handcoded maker classes to fo.properties. regards, finn
