http://permalink.gmane.org/gmane.text.xml.fop.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.text.xml.fop.devel/21853 https://issues.apache.org/bugzilla/show_bug.cgi?id=45759 --- Comment #7 from Johannes Neubauer <johannes.neubauer< at >cs.tu-dortmund.de> 2008-10-06 23:08:29 PST --- Please ignore the new attatchement. Wrong bug. bugzilla< at >apache.org 2008-10-07T06:08:30 http://permalink.gmane.org/gmane.text.xml.fop.devel/21852 https://issues.apache.org/bugzilla/show_bug.cgi?id=45759 --- Comment #6 from Johannes Neubauer <johannes.neubauer< at >cs.tu-dortmund.de> 2008-10-06 23:07:28 PST --- Created an attachment (id=22676) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22676) The cut text is highlighted with a red sphere bugzilla< at >apache.org 2008-10-07T06:07:28 http://permalink.gmane.org/gmane.text.xml.fop.devel/21851 https://issues.apache.org/bugzilla/show_bug.cgi?id=45956 Summary: leader-pattern="rule" not rendered in pcl Product: Fop Version: 0.95 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: pcl AssignedTo: fop-dev< at >xmlgraphics.apache.org ReportedBy: dgerdt< at >bju.edu Created an attachment (id=22675) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22675) simple leader with leader-pattern="rule" I use leaders in some places as horizontal rules to separate sections of a document. I recently realized that they are not getting drawn in my PCL output. They appear correctly in PDFs, but not in PCL. The space for the leader is consumed, but the line is not drawn. Attached is a file that demonstrates the problem. Problem appears in 0.95 and trunk (rev 699739). bugzilla< at >apache.org 2008-10-06T18:11:41 http://permalink.gmane.org/gmane.text.xml.fop.devel/21850 https://issues.apache.org/bugzilla/show_bug.cgi?id=45927 Vincent Hennebert <vhennebert< at >gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #1 from Vincent Hennebert <vhennebert< at >gmail.com> 2008-10-06 07:41:54 PST --- See the following discussion on the fop-users mailing list: http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/200810.mbox/<19779752.post< at >talk.nabble.com> The new behaviour is correct and actually preferable to the old one. bugzilla< at >apache.org 2008-10-06T14:41:55 http://permalink.gmane.org/gmane.text.xml.fop.devel/21849 https://issues.apache.org/bugzilla/show_bug.cgi?id=45954 Vincent Hennebert <vhennebert< at >gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Vincent Hennebert <vhennebert< at >gmail.com> 2008-10-06 07:37:44 PST --- While the XSL-FO Recommendation does refer to the CSS2 one on that matter, it amends it by stating that this is the content rectangle of the area that must be positioned; see the description of the “left” property: http://www.w3.org/TR/xsl11/#left That applies to all four properties. So FOP does comply with the XSL-FO Recommendation here (albeit not to the CSS2 Rec —but it doesn't matter!). FWIW, references to CSS2 have always brought a lot of confusion... Vincent bugzilla< at >apache.org 2008-10-06T14:37:45 http://permalink.gmane.org/gmane.text.xml.fop.devel/21848 https://issues.apache.org/bugzilla/show_bug.cgi?id=45954 Summary: The properties 'top', 'right', 'bottom', and 'left', incorrectly refer to offsets with respect to a box's content edge Product: Fop Version: 0.95 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: page-master/layout AssignedTo: fop-dev< at >xmlgraphics.apache.org ReportedBy: bo< at >kase.se CC: bo< at >kase.se The example code below produces output that seems not to comply with the updated definition att http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html#x12 This behaviour has changed since 0.94 for "top", but not for "left". <fo:flow flow-name="xsl-region-body"> <fo:block-container border="solid black 1pt"> <fo:block-container top="60mm" left="60mm" absolute-position="absolute" border="solid red 50mm"> <fo:block> <fo:inline>TEST</fo:inline> </f bugzilla< at >apache.org 2008-10-06T12:40:16 http://permalink.gmane.org/gmane.text.xml.fop.devel/21847 +---------------------------------------------------------------------------+ | Bugzilla Bug ID | | +---------------------------------------------------------------------+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned | | | OPN=Reopened VER=Verified (Skipped Closed/Resolved) | | | +-----------------------------------------------------------------+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement TRV=Trivial | | | | +-------------------------------------------------------------+ | | | | Date Posted | | | | | +--------------------------------------------------+ | | | | | Description | | | | | | | | 1063|Ne bugzilla< at >apache.org 2008-10-06T06:08:12 http://permalink.gmane.org/gmane.text.xml.fop.devel/21846 https://issues.apache.org/bugzilla/show_bug.cgi?id=40798 --- Comment #14 from Dave Gerdt <dgerdt< at >bju.edu> 2008-10-03 11:48:13 PST --- (In reply to comment #13) Thanks for this work, Andreas! This means I can now use an unmodified version of FOP. Very helpful. bugzilla< at >apache.org 2008-10-03T18:48:13 http://permalink.gmane.org/gmane.text.xml.fop.devel/21845 Dear Sean, I was misinformed - the javadoc and source jars are actually built, so at this time the only problem we have is that they are not voted releases. I'd therefore suggest that we try to include the maven bundle in the release and voting process for future releases. Max Max Berger schrieb: Max Berger 2008-10-03T08:28:16 http://permalink.gmane.org/gmane.text.xml.fop.devel/21844 https://issues.apache.org/bugzilla/show_bug.cgi?id=45938 --- Comment #1 from Chris Bowditch <bowditch_chris< at >hotmail.com> 2008-10-03 00:55:11 PST --- In addition to what Vincent said I have also noticed that the message you do get when FOP can't add a background image is sent to the Logger and not to the Event Listener. bugzilla< at >apache.org 2008-10-03T07:55:11 http://permalink.gmane.org/gmane.text.xml.fop.devel/21843 In my e-mail to fop-users (see <http://www.mail-archive.com/fop-users%40xmlgraphics.apache.org/msg11324.html>) I complained about a couple of minor issues: 1. Running 'fop' with no arguments throws an exception after printing a usage statement. 2. Running 'fop -v' throws an exception after printing the version. 3. Another issue, not complained about in the cited message, is that the current usage and help messages refer to 'Fop' while the user executes 'fop'. The attached patch was generated by running 'svn diff' at the top of the working directory of a checked-out fop trunk at revision 698670. It affects the following files: src/java/org/apache/fop/cli/CommandLineOptions.java src/java/org/apache/fop/cli/Main.java It corrects all three issues listed above. Thanks for your attention. Regards. -Tom Tom Browder 2008-10-03T02:55:46 http://permalink.gmane.org/gmane.text.xml.fop.devel/21842 https://issues.apache.org/bugzilla/show_bug.cgi?id=45938 Summary: Better feedback needed for unknown image formats Product: Fop Version: 1.0dev Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: general AssignedTo: fop-dev< at >xmlgraphics.apache.org ReportedBy: vincent.hennebert< at >anyware-tech.com If an image in an unknown format is specified as a background-image, FOP gives a misleading error message: <fo:block background-image="unknown.xyz">Block</fo:block> org.apache.fop.fo.properties.CommonBorderPaddingBackground getInstance SEVERE: Background image not available: unknown.xyz When the same image is specified as an external-graphic, the error message is hardly better: <fo:external-graphic src="unknown.xyz"/> org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not available. URI: unknown.xyz. Reason: org.apache.xmlgraphics.image.loader.Imag bugzilla< at >apache.org 2008-10-02T16:05:33 http://permalink.gmane.org/gmane.text.xml.fop.devel/21841 Max Berger 2008-10-01T19:21:04 http://permalink.gmane.org/gmane.text.xml.fop.devel/21840 https://issues.apache.org/bugzilla/show_bug.cgi?id=37505 --- Comment #1 from M.H. <mhilpert< at >gmx.de> 2008-10-01 08:53:11 PST --- *push* This still occurs with FOP 0.95. Errors like ------ ... The URI "file:/c:/temp/reports/C_V10276_PropRegion_Overview_S.svg" on element <image> can't be opened because: ... ------ should throw an exception to the FOP caller. Silently logging is not very helpful. bugzilla< at >apache.org 2008-10-01T15:53:11 http://permalink.gmane.org/gmane.text.xml.fop.devel/21839 https://issues.apache.org/bugzilla/show_bug.cgi?id=45927 Summary: Text is not vertically centered anymore. Product: Fop Version: 0.95 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev< at >xmlgraphics.apache.org ReportedBy: mhilpert< at >gmx.de Created an attachment (id=22659) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22659) Example showing the different vertical centers. I migrate our Java FOP application from FOP 0.20.5 to FOP 0.95. I got everything running and most problems from our old 0.20.5 XSL are cleaned up. One of the remaining two problem is, that all text (in table cells) is now "moved up". By comparing the 0.20.5 PDF output with 0.95 PDF output, I've noticed, that FOP 0.20.5 centered text vertically by capital letters. FOP 0.95 is centering text by small letters: FOP 0.20.5 (capital letters are exactly centered bugzilla< at >apache.org 2008-10-01T15:45:56 http://permalink.gmane.org/gmane.text.xml.fop.devel/21838 https://issues.apache.org/bugzilla/show_bug.cgi?id=45924 Summary: Improve border painting in collapsing border model Product: Fop Version: 1.0dev Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: general AssignedTo: fop-dev< at >xmlgraphics.apache.org ReportedBy: vincent.hennebert< at >anyware-tech.com Created an attachment (id=22658) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22658) File demonstrating the problem See attached file: the corners adjacent to the cell without borders aren't fully painted, which makes the result not very nice. It would be a nice to have if the borders were fully painted, like in the separate border model (second table). bugzilla< at >apache.org 2008-10-01T09:56:25 http://permalink.gmane.org/gmane.text.xml.fop.devel/21837 Worked like a charm. Thanks! Any thoughts of publishing the source and javadoc JARs with the binary? I notice this isn't done across the board for some other apache jars I looked at, like xmlgraphics-commons and batik, but it can make debugging issues considerably easier. From: Max Berger [mailto:berger.max< at >gmail.com] On Behalf Of Max Berger Sent: Saturday, September 27, 2008 4:39 PM To: fop-dev< at >xmlgraphics.apache.org Subject: Re: FOP 0.95 and Maven2 Dear Sean, should be uploaded now, and sync with the main repository within 24 hours. Please let me know if you encounter any problems. Max Am 26.09.2008 um 20:20 schrieb Griffin,Sean: Developers, Are there any plans to push the new FOP 0.95 release to the central Maven repo? Sean Griffin | Clinical Reporting Architect | Cerner Corporation | 816.201.1599 | sgriffin< at >cerner.com <mailto:sgriffin< at >cerner.com> | www.cerner.com <http://www.cerner.com> ________________________________ CONFIDENTIALITY NOTICE This message and any inclu Griffin,Sean 2008-09-30T14:34:16 http://permalink.gmane.org/gmane.text.xml.fop.devel/21836 Christian Geisert 2008-09-29T12:13:09 http://permalink.gmane.org/gmane.text.xml.fop.devel/21835 +---------------------------------------------------------------------------+ | Bugzilla Bug ID | | +---------------------------------------------------------------------+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned | | | OPN=Reopened VER=Verified (Skipped Closed/Resolved) | | | +-----------------------------------------------------------------+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement TRV=Trivial | | | | +-------------------------------------------------------------+ | | | | Date Posted | | | | | +--------------------------------------------------+ | | | | | Description | | | | | | | | 1063|Ne bugzilla< at >apache.org 2008-09-29T06:08:11 http://permalink.gmane.org/gmane.text.xml.fop.devel/21834 https://issues.apache.org/bugzilla/show_bug.cgi?id=45862 --- Comment #3 from Andreas L. Delmelle <adelmelle< at >apache.org> 2008-09-28 04:47:37 PST --- (In reply to comment #2) Depends on what the concrete logging framework is that is used in your environment. FOP uses Jakarta Commons Logging, which by default uses standard JDK Logging (where you can definitely set the log-level on a per-package basis, i.e. level = INFO for everything in org.apache.fop and descendants) see: http://xmlgraphics.apache.org/fop/0.95/embedding.html#basic-logging bugzilla< at >apache.org 2008-09-28T11:47:38 http://permalink.gmane.org/gmane.text.xml.fop.devel/21833 https://issues.apache.org/bugzilla/show_bug.cgi?id=45862 --- Comment #2 from Lucio Asnaghi <kunitoki< at >gmail.com> 2008-09-28 04:12:07 PST --- how can i disable FOP debug output only without affecting the other libraries or the containers (for which i need the debug output) ? and anyway, disabling debug is sure meant in a production environment, but i usually work in development environment... bugzilla< at >apache.org 2008-09-28T11:12:07 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.text.xml.fop.devel