Bug report for Fop [2004/09/12]
+---+
| 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 |
| 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 |
| 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 |
| 8321|New|Nor|2002-04-19|from-parent('width') returns 0 for nested tables |
| 8463|New|Nor|2002-04-24|SVG clipping in external.fo example doc when rende|
|
DO NOT REPLY [Bug 31162] - [PATCH] Commandline logger
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31162. 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=31162 [PATCH] Commandline logger --- Additional Comments From [EMAIL PROTECTED] 2004-09-12 18:22 --- Q 2.) Having the constructor for CommandLineOptions take the args[] parameter again. I don't like the ability to create objects in an invalid state--in this case, having a CommandLineOptions object alive without having a command-line options string. So I tend to prefer constructors that require what is needed up-front--it saves validation code later. /Q Sure, but then we need some other way of logging the exceptions thrown during command argument parsing. Right now we get can get an exception during the CommandLineOptions ctor. As a result the options vrbl is null in Fop.main() and we are not able to output the exception to the logger which was created but lost during the exception. Try f.ex: fop -fo -pdf out to see that no information about the exception is printed. regards, finn
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java
A (farfetched) argument against ThreadLocals would be that they prevent one FOP processing run to occur recursively during another independent processing run. Like an extension element that itself will attempt to process another fo document. [Glen] I think that restriction is implicit in the XSL Recommendation, because fo:instream-foreign-object [1], has the requirement that its child be from a *non-XSL* namespace. If the rec intended FO documents to be processed recursively, they wouldn't have had a non-XSL namespace requirement (i.e., why bother to require users to have a finn:fodocument that would just wrap fo:root/, if you can just use the latter tag directly?) Indeed, this restriction could be an argument *for* using ThreadLocals. No, not really. ThreadLocals should be used for storing data that is local to each thread (thread singletons). They are not a way to introduce global variables which just so happens to work in tomcat. regards, finn
Re: Project offo distributes hyphenation pattern files for FOP
Moved from fop-user. Simon, Under which license have you set up the SourceForge project? Peter Simon Pepping wrote: Dear FOP users, In February 2004 a large number of hyphenation pattern files were removed from FOP's CVS repository due to licensing issues. These hyphenation patterns were contributed to FOP under licenses which allowed their free distribution, but under conditions which were felt to be in contradiction with the Apache license, under which FOP is distributed. Most files are licensed under the LaTeX Project Public License (http://www.latex-project.org/lppl/index.html), which requires that no modified version be published under the name of the original source file. For details see the FOP wiki page (http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAudits/March2003). I am please to announce that the hyphenation pattern files for FOP are now made available by the project `Objects for Formatting Objects' (offo) (http://offo.sourceforge.net/). They can be downloaded from offo's project page (http://sourceforge.net/projects/offo/). At this moment the homepage of the project is not yet ready. Therefore the overview of the hyphenation pattern files and their licenses is available from my web site, http://www.leverkruid.nl/FOP/hyphenation.html. It is also contained in the package file. Regards, Simon -- Peter B. West http://cv.pbw.id.au/
AFP Renderer Patch
I'm trying to generate the patch for the AFP renderer, something I've not done before! Can someone tell me what I need to do, following the notes on the web site I just get the following output to the winCVS console: cvs -q diff -wu xml-fop (in directory C:\xml-fop\) ? xml-fop/conf/afp-fonts.dtd ? xml-fop/conf/afp-fonts.xml ? xml-fop/src/org/apache/fop/render/afp * CVS exited normally with code 0 * If someone can let me know how to generate a patch file using winCVS I'll submit it. Many thanks, Pete.
Re: AFP Renderer Patch
I stay away from WinCVS and just use the command line: c:\cvs diff -u c:\mypatch.txt Thanks, Glen --- Pete Townsend [EMAIL PROTECTED] wrote: I'm trying to generate the patch for the AFP renderer, something I've not done before!
DO NOT REPLY [Bug 31162] - [PATCH] Commandline logger
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31162. 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=31162 [PATCH] Commandline logger --- Additional Comments From [EMAIL PROTECTED] 2004-09-13 03:22 --- OK, please fix it then. Xalan [1] doesn't bother with throwing exceptions during command line processing, they just System.err the message and then call System.exit(). I'd like us to move in that direction, it would also sharply reduce the number of FOPExceptions we have. WDYT? (Another pet project of mine, to reduce FOPException in favor of what the actual exception is. BTW, anyone would object to us eventually getting rid of FOPException entirely? I think it breeds bad coding habits, because the developer doesn't stop to think what the actual exception type is.) [1] http://cvs.apache.org/viewcvs.cgi/xml-xalan/java/src/org/apache/xalan/xslt/Process.java?rev=1.62view=auto Thanks, Glen
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java
I reverted it to the original recursive method, this appears to be the best compromise for everyone's wishes. Glen --- Finn Bock [EMAIL PROTECTED] wrote: A (farfetched) argument against ThreadLocals would be that they prevent one FOP processing run to occur recursively during another independent processing run. Like an extension element that itself will attempt to process another fo document. [Glen] I think that restriction is implicit in the XSL Recommendation, because fo:instream-foreign-object [1], has the requirement that its child be from a *non-XSL* namespace. If the rec intended FO documents to be processed recursively, they wouldn't have had a non-XSL namespace requirement (i.e., why bother to require users to have a finn:fodocument that would just wrap fo:root/, if you can just use the latter tag directly?) Indeed, this restriction could be an argument *for* using ThreadLocals. No, not really. ThreadLocals should be used for storing data that is local to each thread (thread singletons). They are not a way to introduce global variables which just so happens to work in tomcat. regards, finn
