Re: ant junit target fails
On 07.08.2005 20:41:42 Simon Pepping wrote: I have always commented this test out in my working copy. I do not like tests that actually (also) test the exact innards of certain Xerces and Xalan versions. They were not supposed to check the innards of certain Xerces and Xalan versions. The tests check the basic functionality of the FOP API. Given that most of the directy dependencies on the input source are now removed (only getDefaultHandler() remains) we can probably remove some of those methods, especially the DOM-related ones. Do you agree? I have got several copies of those two on my system, and I use them via the endorsed-dirs mechanism. Some scripts use a different copy than others, and for me FOP should just work with any recent parser and transformer. That's right, but there's simply the fact the there were a lot of little bugs in the TraX portion of Xalan WRT DOM. There's not much we can do about that in FOP. IMHO An upgrade of the jars in FOP does not solve the problem of this test file. Any additional ideas? Regards, Simon On Sun, Aug 07, 2005 at 06:46:17PM +0200, Jeremias Maerki wrote: There were a number of these issues in the past. Yes, it's definitely time to upgrade the Xerces and Xalan JARs, although it won't fix the problems for those people who don't know how to replace the default Xerces/Crimson and Xalan versions coming with the JDK. But that can't be helped. As a rule, I always use the latest Xerces and Xalan versions on my machine. I even have a customized Xalan ATM since the Xalan people haven't fixed a bug which causes a problem with Barcode4J and FOP for over a year now. On 07.08.2005 14:21:55 Manuel Mall wrote: On Sat, 6 Aug 2005 10:37 pm, you wrote: I am consistently getting the error below on the ant junit target. snip/ Further investigation showed that I can get rid of the error by upgrading the xerces/xalan combination. Here is a summary of what I found: xalan 2.4.1/xerces 2.2.1 as extracted from SVN doesn't work xalan 2.5.x/xerces 2.?.? doesn't work xalan 2.6.1/xerces from xalan 2.6.1 bundle does prevent the error below but I then get similar NAMESPACE_ERR errors from within the layout engine test suite xalan 2.7.0/xerces from xalan 2.7.0 bundle does work All this evaluated under RH Enterprise ES 3 with Sun Java 5.0 latest release. Time to upgrade the xalan/xerces jars in SVN? Manuel There was 1 error: 1) testFO2PDFWithDOM(org.apache.fop.BasicDriverTestCase)javax.xml.transf orm.TransformerException: org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces. at org.apache.xalan.transformer.TransformerIdentityImpl.transform(Transf ormerIdentityImpl.java:511) at org.apache.fop.BasicDriverTestCase.loadDocument(BasicDriverTestCase.j ava:62) at org.apache.fop.BasicDriverTestCase.testFO2PDFWithDOM(BasicDriverTestC ase.java:78) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.nl Jeremias Maerki
Re: ant junit target fails
On 08.08.2005 02:22:55 Manuel Mall wrote: On Mon, 8 Aug 2005 02:41 am, Simon Pepping wrote: snip/ IMHO An upgrade of the jars in FOP does not solve the problem of this test file. Simon, 1. do you actually understand what the problem is because I don't? The test file (test/xml/bugtests/block.fo) is trivial. It works from the fop command line, it works with the SAX test, its only when using the identity transformation to convert it into a DOM source that the error happens. It's a matter of version-constellation. Lots of little Xalan bugs in older versions plus the problem that Sun do their own release of Xerces and Xalan in their JDK (custom modifications). See also my reponse to Simon. 2. While I agree that fop as such should work with any JAXP compliant parser I don't have a problem if building/verifying fop requires a particular parser / transformer version. However, IMHO it would be desirable that fop builds / verifies out-of-the-box without the need to upgrade components delivered with it. It seems to me that we could achieve that by upgrading xerces/xalan in SVN. I do believe that the current xerces/xalan versions are still compatible with JDK 1.3 which is the oldest JDK version fop attempts to support. If there are arguments against upgrading xerces/xalan than we should do what you have done and disable the tests that fail in SVN so that fop builds/verifies correctly. I don't think Simon objects to upgrading Xerces and Xalan, merely that it doesn't fix the problem in his opinion and I think he's right. Upgrading Xerces and Xalan only helps for JDK 1.3 users, and for users with JDK = 1.4 it only helps if they place the three JARs in their lib/endorsed directory of the JDK/JRE installation or adjust fop.bat to specify an alternate location for the endorsed directory. Jeremias Maerki
DO NOT REPLY [Bug 36067] - [PATCH] Support for relative font sizes
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=36067. 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=36067 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #15944|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2005-08-08 13:16 --- Created an attachment (id=15951) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15951action=view) Replacement for FontSizePropertyMaker.java as per Finn's recommendations -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36067] - [PATCH] Support for relative font sizes
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=36067. 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=36067 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #15945|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2005-08-08 13:17 --- Created an attachment (id=15952) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15952action=view) Replacement for FontStretchPropertyMaker.java as per Finn's recommendations -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36082] New: - [PATCH] Relative URIs are not correctly resolved
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=36082. 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=36082 Summary: [PATCH] Relative URIs are not correctly resolved Product: Fop Version: 1.0dev Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xml.apache.org ReportedBy: [EMAIL PROTECTED] Jeremias wrote on fop-dev: Basically, I've stumbled upon a few anomalies with relative paths and resource access in general. Images were not properly loaded and I think there were differences in behaviour between FOP and Batik. The problem can be easily reproduced by running fop from a different directory as the fo/xml input file and the input file has a relative URI reference to an external image. The problem is caused by the FOUserAgent.getBaseURL() method always returning a URL even if it is not set and the InputHandler.render() method only setting the base URL in the FOUserAgent if getBaseURL() returns null which it never does. The attached patch fixes that by making getBaseURL() returning null if no baseURL is set. Doing this on its own would have lost the functionality of defaulting the baseURL to the current directory if not set. I therefore added a function getBaseURLasURL to FOUserAgent which returns the current baseURL as a java.net.URL and defaults that to a file: URL pointing to the current directory if baseURL is not set. It also ports some URL normalisation code for relative URLs from 0.20.5 FopImageFactory to ImageFactory. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36082] - [PATCH] Relative URIs are not correctly resolved
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=36082. 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=36082 --- Additional Comments From [EMAIL PROTECTED] 2005-08-08 15:36 --- Created an attachment (id=15955) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15955action=view) The patch file -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36004] - [PATCH] Block content in inline content
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=36004. 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=36004 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2005-08-08 16:36 --- Simon, thanks for your work on inlines and for setting up the branch. As you will have seen, I've hacked around a little bit in the branch and I think we're ready to merge the branch back into trunk. All necessary tests pass. Would you please review? My KnuthElement/KnuthSequence mixture might be subject to discussion but it allowed not adjusting some of the LMs and creates fewer objects that way. WDYT? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36014] - leader-pattern=rule doesn't work at all
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=36014. 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=36014 --- Additional Comments From [EMAIL PROTECTED] 2005-08-08 17:13 --- I think I found the problem: In LeaderLayoutManager the bpd is not set on the generated leader area for leader-pattern=rule. If I set the bpd equal to the rule thickness I do get the leaders produced. However, there then seem to be a problem with their vertical alignment. My understanding of all this is still too limited to submit a patch but hopefully this gives someone with better understanding of the layout an idea how to fix this. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36018] - leader-pattern=space doesn't appear to work
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=36018. 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=36018 --- Additional Comments From [EMAIL PROTECTED] 2005-08-08 17:16 --- Same possible resolution as for Bug #36014 - the bpd on the generated leader area is not set. If I set the bdp to something, e.g. font.getAscender() proper blank leader areas are generated. No patch as I am not sure what the correct bpd setting for a space filled leader area should be. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: ant junit target fails
On Mon, Aug 08, 2005 at 09:20:19AM +0200, Jeremias Maerki wrote: On 07.08.2005 20:41:42 Simon Pepping wrote: I have always commented this test out in my working copy. I do not like tests that actually (also) test the exact innards of certain Xerces and Xalan versions. They were not supposed to check the innards of certain Xerces and Xalan versions. The tests check the basic functionality of the FOP API. Given that most of the directy dependencies on the input source are now removed (only getDefaultHandler() remains) we can probably remove some of those methods, especially the DOM-related ones. Do you agree? That is right. Since FOP receives the data in all cases as a SAX content handler, the different tests do not make a difference for FOP anymore. I have got several copies of those two on my system, and I use them via the endorsed-dirs mechanism. Some scripts use a different copy than others, and for me FOP should just work with any recent parser and transformer. That's right, but there's simply the fact the there were a lot of little bugs in the TraX portion of Xalan WRT DOM. There's not much we can do about that in FOP. That could be. I have just worked around the annoyance that the test failed for reasons that I could not understand or change. But this means that people get exceptions when they do this kind of work with FOP and older versions of X + X. That is indeed a reason to upgrade them in FOP's distribution. IMHO An upgrade of the jars in FOP does not solve the problem of this test file. Any additional ideas? Not really, esp. if it is suspected that it is a bug in X + X. Regards, Simon On Sun, Aug 07, 2005 at 06:46:17PM +0200, Jeremias Maerki wrote: There were a number of these issues in the past. Yes, it's definitely time to upgrade the Xerces and Xalan JARs, although it won't fix the problems for those people who don't know how to replace the default Xerces/Crimson and Xalan versions coming with the JDK. But that can't be helped. As a rule, I always use the latest Xerces and Xalan versions on my machine. I even have a customized Xalan ATM since the Xalan people haven't fixed a bug which causes a problem with Barcode4J and FOP for over a year now. On 07.08.2005 14:21:55 Manuel Mall wrote: On Sat, 6 Aug 2005 10:37 pm, you wrote: I am consistently getting the error below on the ant junit target. snip/ Further investigation showed that I can get rid of the error by upgrading the xerces/xalan combination. Here is a summary of what I found: xalan 2.4.1/xerces 2.2.1 as extracted from SVN doesn't work xalan 2.5.x/xerces 2.?.? doesn't work xalan 2.6.1/xerces from xalan 2.6.1 bundle does prevent the error below but I then get similar NAMESPACE_ERR errors from within the layout engine test suite xalan 2.7.0/xerces from xalan 2.7.0 bundle does work All this evaluated under RH Enterprise ES 3 with Sun Java 5.0 latest release. Time to upgrade the xalan/xerces jars in SVN? Manuel There was 1 error: 1) testFO2PDFWithDOM(org.apache.fop.BasicDriverTestCase)javax.xml.transf orm.TransformerException: org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces. at org.apache.xalan.transformer.TransformerIdentityImpl.transform(Transf ormerIdentityImpl.java:511) at org.apache.fop.BasicDriverTestCase.loadDocument(BasicDriverTestCase.j ava:62) at org.apache.fop.BasicDriverTestCase.testFO2PDFWithDOM(BasicDriverTestC ase.java:78) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) Jeremias Maerki Simon Pepping Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.nl
Re: [Bug 36004] - [PATCH] Block content in inline content
On Mon, Aug 08, 2005 at 04:36:40PM +0200, [EMAIL PROTECTED] wrote: http://issues.apache.org/bugzilla/show_bug.cgi?id=36004 --- Additional Comments From [EMAIL PROTECTED] 2005-08-08 16:36 --- Simon, thanks for your work on inlines and for setting up the branch. As you will have seen, I've hacked around a little bit in the branch and I think we're ready to merge the branch back into trunk. All necessary tests pass. Would you please review? My KnuthElement/KnuthSequence mixture might be subject to discussion but it allowed not adjusting some of the LMs and creates fewer objects that way. WDYT? I do not have much time to look at it more closely until Friday or the weekend. From what I saw by scanning the svn commit logs, my first reaction is that it works, but it is not what I like. It makes the code less clean and more complicated by allowing and checking for two alternative allowed datastructures. My idea is that all InlineLevelLMs return a list of KnuthSequences for getNextKnuthElements. Of course you can move it back into the trunk. I can always work further on it when it is there. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: ant junit target fails
Ok then, I'll upgrade X + X and remove the unnecessary test methods. On 08.08.2005 21:44:56 Simon Pepping wrote: On Mon, Aug 08, 2005 at 09:20:19AM +0200, Jeremias Maerki wrote: On 07.08.2005 20:41:42 Simon Pepping wrote: I have always commented this test out in my working copy. I do not like tests that actually (also) test the exact innards of certain Xerces and Xalan versions. They were not supposed to check the innards of certain Xerces and Xalan versions. The tests check the basic functionality of the FOP API. Given that most of the directy dependencies on the input source are now removed (only getDefaultHandler() remains) we can probably remove some of those methods, especially the DOM-related ones. Do you agree? That is right. Since FOP receives the data in all cases as a SAX content handler, the different tests do not make a difference for FOP anymore. I have got several copies of those two on my system, and I use them via the endorsed-dirs mechanism. Some scripts use a different copy than others, and for me FOP should just work with any recent parser and transformer. That's right, but there's simply the fact the there were a lot of little bugs in the TraX portion of Xalan WRT DOM. There's not much we can do about that in FOP. That could be. I have just worked around the annoyance that the test failed for reasons that I could not understand or change. But this means that people get exceptions when they do this kind of work with FOP and older versions of X + X. That is indeed a reason to upgrade them in FOP's distribution. IMHO An upgrade of the jars in FOP does not solve the problem of this test file. Any additional ideas? Not really, esp. if it is suspected that it is a bug in X + X. Jeremias Maerki
