Re: Storing the Locator instance in FONode.
[Glen] I see. I liked Locator because I can get away with passing in one parameter into the vCN() instead of three. (But I don't think we'll need to change that portion of the code because whenever vCN() is being called, the Locator *is* accurate--would you agree?) Yes. regards, finn
DO NOT REPLY [Bug 31502] New: - UTF-8
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=31502. 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=31502 UTF-8 Summary: UTF-8 Product: Fop Version: all Platform: PC OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED]
Re: cvs commit: xml-fop/src/java/org/apache/fop/render/rtf TableAttributesConverter.java
Finn, it seems to me that you probably forgot the check in all your changes. FOP doesn't compile ATM. The method makeBorder is missing. On 01.10.2004 11:46:36 bckfnn wrote: bckfnn 2004/10/01 02:46:36 Modified:src/java/org/apache/fop/render/rtf TableAttributesConverter.java Log: Simplified the handling of length attributes. Attempt at setting borders correctly. Revision ChangesPath 1.16 +49 -140 xml-fop/src/java/org/apache/fop/render/rtf/TableAttributesConverter.java Index: TableAttributesConverter.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/render/rtf/TableAttributesConverter.java,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- TableAttributesConverter.java 23 May 2004 17:00:00 - 1.15 +++ TableAttributesConverter.java 1 Oct 2004 09:46:36 - 1.16 snip/ +BorderAttributesConverter.makeBorder(propList, attrib, ITableAttributes.CELL_BORDER_TOP, +Constants.PR_BORDER_TOP_COLOR, +Constants.PR_BORDER_TOP_STYLE, +Constants.PR_BORDER_TOP_WIDTH); +BorderAttributesConverter.makeBorder(propList, attrib, ITableAttributes.CELL_BORDER_BOTTOM, +Constants.PR_BORDER_BOTTOM_COLOR, +Constants.PR_BORDER_BOTTOM_STYLE, +Constants.PR_BORDER_BOTTOM_WIDTH); +BorderAttributesConverter.makeBorder(propList, attrib, ITableAttributes.CELL_BORDER_LEFT, +Constants.PR_BORDER_LEFT_COLOR, +Constants.PR_BORDER_LEFT_STYLE, +Constants.PR_BORDER_LEFT_WIDTH); +BorderAttributesConverter.makeBorder(propList, attrib, ITableAttributes.CELL_BORDER_RIGHT, +Constants.PR_BORDER_RIGHT_COLOR, +Constants.PR_BORDER_RIGHT_STYLE, +Constants.PR_BORDER_RIGHT_WIDTH); Jeremias Maerki
Re: Remove image.JimiImage from HEAD?
Glen Mazza wrote: --- Jeremias Maerki [EMAIL PROTECTED] wrote: Why are you so keen on removing stuff? I'd be more concerned about adding the stuff that's missing for an initial release. Just cleaning up for the next release. Jimi works fine for some people. No reason to remove this. OK, so it does work for the Java 2 platform. We'll keep it then. I haven't been following the developments very closely, so this may sound like a stupid question: does that mean that FOP HEAD now works nicely with PNGs without JIMI? Has the code from Batik been merged in, or has another solution emerged? cheers, dalibor topic
Re: Remove image.JimiImage from HEAD?
Not a stupid question at all, but no, with FOP 0.20.5 you still need either JIMI or JAI for PNG support. But it may well be that the next FOP version will support PNG without an additional library. For now, you're stuck, though. On 01.10.2004 15:31:15 Dalibor Topic wrote: I haven't been following the developments very closely, so this may sound like a stupid question: does that mean that FOP HEAD now works nicely with PNGs without JIMI? Has the code from Batik been merged in, or has another solution emerged? Jeremias Maerki
Re: Remove image.JimiImage from HEAD?
Jeremias Maerki wrote: Not a stupid question at all, but no, with FOP 0.20.5 you still need either JIMI or JAI for PNG support. But it may well be that the next FOP version will support PNG without an additional library. For now, you're stuck, though. thanks for the quick responce, Jeremias. I'm going to be a bit involved with Fedora documentation project's attempt to build up their toolchain using FOP on GNU Classpath based runtimes[1], so I'm glad to hear that there is a chance of having PNG work out of the box in the next release. My initial experiments with Kaffe FOP a while ago have been encouraging. I am considering spending some time getting FOP to work on gcj, Kaffe and other runtimes, as I'd like to use it to generate man pages for kaffe using kaffe, among other things. I assume HEAD is the best place to start for an interested developer? cheers, dalibor topic [1] And with debian's efforts to get FOP into main.
Re: Remove image.JimiImage from HEAD?
If you got a long breath, yes. We're are still a few months from a release. The layout code is in the process of being completely rewritten, so many features available in 0.20.5 are still missing. On 01.10.2004 17:10:34 Dalibor Topic wrote: Jeremias Maerki wrote: Not a stupid question at all, but no, with FOP 0.20.5 you still need either JIMI or JAI for PNG support. But it may well be that the next FOP version will support PNG without an additional library. For now, you're stuck, though. thanks for the quick responce, Jeremias. I'm going to be a bit involved with Fedora documentation project's attempt to build up their toolchain using FOP on GNU Classpath based runtimes[1], so I'm glad to hear that there is a chance of having PNG work out of the box in the next release. My initial experiments with Kaffe FOP a while ago have been encouraging. I am considering spending some time getting FOP to work on gcj, Kaffe and other runtimes, as I'd like to use it to generate man pages for kaffe using kaffe, among other things. I assume HEAD is the best place to start for an interested developer? cheers, dalibor topic [1] And with debian's efforts to get FOP into main. Jeremias Maerki
Re: Remove image.JimiImage from HEAD?
On 01.10.2004 18:06:13 Clay Leeds wrote: Please clarify: As the Subject implies, Glen's original message indicated he wanted to remove Jimi (I understand that won't be the case now). He said nothing of removing JAI, and as far as I understand, FOP-1.0 will still need JAI for PNG support (please correct me if I'm wrong). Nobody talks about removing JAI support. Will JAI be required by FOP-1.0 for PNG and also be required for some subformats of TIFF[1]? Yes, except that we can use the ImageIO API from JDK 1.4 and later. But in the end ImageIO also uses JAI codecs to support the different formats. We could also have another look at open source codecs to support PNG and TIFF etc. Jeremias Maerki
Re: Remove image.JimiImage from HEAD?
On Oct 1, 2004, at 2:30 PM, Jeremias Maerki wrote: On 01.10.2004 18:06:13 Clay Leeds wrote: Please clarify: As the Subject implies, Glen's original message indicated he wanted to remove Jimi (I understand that won't be the case now). He said nothing of removing JAI, and as far as I understand, FOP-1.0 will still need JAI for PNG support (please correct me if I'm wrong). Nobody talks about removing JAI support. Just wanted to be sure... I saw the following and was confused: On Oct 1, 2004, at 6:39 AM, Jeremias Maerki wrote: Not a stupid question at all, but no, with FOP 0.20.5 you still need either JIMI or JAI for PNG support. But it may well be that the next FOP version will support PNG without an additional library. For now, you're stuck, though. But it may well be that the next FOP will support PNG without an additional library. Will JAI be required by FOP-1.0 for PNG and also be required for some subformats of TIFF[1]? Yes, except that we can use the ImageIO API from JDK 1.4 and later. But in the end ImageIO also uses JAI codecs to support the different formats. We could also have another look at open source codecs to support PNG and TIFF etc. Jeremias Maerki Maybe the idea of adding open source codecs is what you were referring to. Thanks for the response... Web Maestro Clay
Build broken?
I can't seem to compile HEAD--it may be related to Finn's latest changes. Javac is complaining about an unknown BorderAttributesConverter.makeBorder(...) in render.rtf.TableAttributesConverter. Thanks, Glen