Bug report for Fop [2003/09/14]
+---+ | 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 | | 4614|New|Maj|2001-11-03|wrap property combined with Chinese | | 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|Row-spanned row data breaks over a page within a c| | 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 | |
Re: FOP updated to new Batik API
Glen Mazza wrote:
Patch applied! But please be careful to keep all
if-statements within braces--for the second patch, the
change at line 500 made the code look somewhat vague
as to your intentions (see below--I fixed it though).
Ahh yah, sorry for the confusion.
You say you 'fixed it', you should not
have moved the result stuff into the if.
(...previous { somewhere...)
if (alpha != 255)
hasMask = true;
result[count++] = (byte)((val 16) 0xFF);
result[count++] = (byte)((val 8) 0xFF);
result[count++] = (byte)((val) 0xFF);
}
--- Thomas DeWeese [EMAIL PROTECTED] wrote:
I've attached a
tiny
patch that fixes this for the PDFTextPainter.
I also have attached a patch for PDFGraphics2D.
The patch has two parts - the first is the more
important
of the two.
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: FOP updated to new Batik API
--- Thomas DeWeese [EMAIL PROTECTED] wrote: You say you 'fixed it', you should not have moved the result stuff into the if. No, I did not--it was *reformatted* correctly I meant! Glen __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
cvs commit: xml-fop/src/java/org/apache/fop/render AbstractRenderer.java
gmazza 2003/09/14 12:32:44
Modified:src/java/org/apache/fop/render AbstractRenderer.java
Log:
Change to have the fo:region-body display on top in cases of overlap with the
other fo:regions.
Revision ChangesPath
1.14 +6 -2 xml-fop/src/java/org/apache/fop/render/AbstractRenderer.java
Index: AbstractRenderer.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/render/AbstractRenderer.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- AbstractRenderer.java 10 Sep 2003 18:42:22 - 1.13
+++ AbstractRenderer.java 14 Sep 2003 19:32:44 - 1.14
@@ -276,16 +276,20 @@
* @param page The page whos page areas are to be rendered
*/
protected void renderPageAreas(Page page) {
+/* Spec does not appear to specify whether fo:region-body should
+appear above or below side regions in cases of overlap. FOP
+decision is to have fo:region-body on top, hence it is rendered
+last here. */
RegionViewport viewport;
viewport = page.getRegion(Region.BEFORE_CODE);
renderRegionViewport(viewport);
viewport = page.getRegion(Region.START_CODE);
renderRegionViewport(viewport);
-viewport = page.getRegion(Region.BODY_CODE);
-renderRegionViewport(viewport);
viewport = page.getRegion(Region.END_CODE);
renderRegionViewport(viewport);
viewport = page.getRegion(Region.AFTER_CODE);
+renderRegionViewport(viewport);
+viewport = page.getRegion(Region.BODY_CODE);
renderRegionViewport(viewport);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23166] - [PATCH] RTF: support for fo:table
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23166. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23166 [PATCH] RTF: support for fo:table --- Additional Comments From [EMAIL PROTECTED] 2003-09-14 22:07 --- Created an attachment (id=8214) RtfTable: method getHeaderAttribs added
DO NOT REPLY [Bug 23166] - [PATCH] RTF: support for fo:table
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23166. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23166 [PATCH] RTF: support for fo:table --- Additional Comments From [EMAIL PROTECTED] 2003-09-14 22:08 --- Created an attachment (id=8215) TableBody: call of startBody/endBody added
DO NOT REPLY [Bug 23166] - [PATCH] RTF: support for fo:table
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23166. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23166 [PATCH] RTF: support for fo:table --- Additional Comments From [EMAIL PROTECTED] 2003-09-14 22:09 --- Created an attachment (id=8216) BuilderContext: new module
DO NOT REPLY [Bug 23166] - [PATCH] RTF: support for fo:table
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23166. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23166 [PATCH] RTF: support for fo:table --- Additional Comments From [EMAIL PROTECTED] 2003-09-14 22:09 --- Created an attachment (id=8217) FoUnitsConverter: new module
DO NOT REPLY [Bug 23166] - [PATCH] RTF: support for fo:table
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23166. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23166 [PATCH] RTF: support for fo:table --- Additional Comments From [EMAIL PROTECTED] 2003-09-14 22:10 --- Created an attachment (id=8218) TableAttributesConverter: new module
DO NOT REPLY [Bug 23166] - [PATCH] RTF: support for fo:table
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23166. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23166 [PATCH] RTF: support for fo:table --- Additional Comments From [EMAIL PROTECTED] 2003-09-14 22:10 --- Created an attachment (id=8219) TableContext: new module
RE: (Jay) RE: RE: Batik Extension/FOP problem
-Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] I added in a new Batik extension element mapping in our main trunk code--this should help you. It is not Glen, I'm just being curious: did my remarks turn out to be helpful here? (I just want to check to what extent I'm beginning to understand the internals of the application...) Please test it out--wait 6 hours for a nightly snapshot to appear (see our Download link on the main Have done so. Well, not the Batik extension element mapping in particular, but I had been embedding the maintenance version up to now. Switched it to 1.0dev and basic functionality seems to be A-OK. I've run into a few cases though where the maintenance version did its work just fine, but 1.0dev seems to be 'unfinished' - as mostly happens with nightly builds, I guess. I'm not sure which of these problems are already being worked on, and as I most certainly do not want to end up 'spamming' fop-dev with a bunch of pseudo-bugs, I'll just name a few here. If there's little insects crawling around in here you think I'd better report to Bugzilla, just let me know : 1. links ( internal external ) don't work: neither in my own documents, nor in the newlinktest.fo example that comes with FOP 2. background-color [? this might be working fine: I defined a bg-c for a table-body - now seems to disappear; works if I add them to table-cell instead of table-body - so could be that it now actually is working correctly by 'covering' the background of body with that of the cell... I still need to check the spec run a few tests to see whether this behaviour is compliant: CSS seems to silently presuppose that if no bg-c is explicitly defined, table-cell would inherit the value of its parent - in this case table-row, but as none was specified there either, one would expect it to be the color of table-body... ] 3. break-before -after seem to have no effect Read you later. Greetz, Andreas
RE: (Jay) RE: RE: Batik Extension/FOP problem
--- Andreas L. Delmelle [EMAIL PROTECTED] wrote: I'm just being curious: did my remarks turn out to be helpful here? (I just want to check to what extent I'm beginning to understand the internals of the application...) I was happy to see you going through the source code. Also welcome to the FOP-DEV list. Main issue is that we could not just switch from SVGDOMImplementation to ExtendedSVGDOMImplementation as Thomas (I believe) had thought. The latter is not really a superclass of the former--they're different sets of elements with different namespaces. (To that end, the superclass-subclass relationship of these two classes in the Batik code does not seem correct to me.) So I just added in one more ElementMapping subclass in the fo.extensions.svg package for the Batik Extension elements. I'm not sure which of these problems are already being worked on, and as I most certainly do not want to end up 'spamming' fop-dev with a bunch of pseudo-bugs Don't kill yourself here--the majority of 1.0 is still unimplemented. I was strictly more concerned about the Batik extensions working for this particular point. (For sanity retention, I try to narrow my concerns to one or two topics for each week.) CSS seems to silently presuppose that if no bg-c is explicitly defined, table-cell would inherit the value of its parent - in this case table-row, but as none was specified there either, one would expect it to be the color of table-body... ] Well, not everything is inherited in the XSL FO standard--http://www.w3.org/TR/xsl/slice7.html#background-color says bg-c is not inherited (but evidently can be if inherit is chosen as a value, so I'm not sure how FOP should handle this.) Glen __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
