Static methods
Finn, I noticed that you extracted numeric function methods as statics into a class of their own. Was this for aesthetic or performance reasons? Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: AW: rtf-external-graphics
They are in the org.apache.fop.image package. Start by looking at ImageFactory. They're not in XML Graphics Commons, yet, but will go there eventually. On 28.09.2005 23:58:11 Peter Herweg wrote: Jeremias Maerki wrote: I'll look into it tomorrow. Peter's last change for external-graphics in RTF made me wonder if we shouldn't actually change the whole code there and use the image library wrappers the normal renderers use. Like this we could use the image cache, more image formats and URI resolution the same way as for the other output formats. I have played around with JAI to support other file formats (e.g. GIF, BMP). This works good but it's quite slow. I did not know that there are image library wrappers. Can you point me to them? Are they contained in XML Graphics Commons? Regards, Peter Herweg Jeremias Maerki
Re: Funny side-effects from space-resolution
On Wed, Sep 28, 2005 at 10:48:11PM +0800, Manuel Mall wrote: Jeremias, looks OK to me although a bit strange but hey...that's the spec. On Wed, 28 Sep 2005 10:00 pm, Jeremias Maerki wrote: I've just stumbled over the testcase block_margin_inherit while fixing problems revealed by the test suite after having space-resolution work on blocks. Here's how it looks like: fo:flow flow-name=xsl-region-body fo:block margin=5% background-color=yellow fo:block margin=inherit background-color=blue margin=inherit - should have the same margin as the enclosing block /fo:block /fo:block fo:blockYellow block has margin=5% - 18pt margin based on 5in page width/fo:block /fo:flow The 5% in this case evaluate to 18000mpt. margin, as a short-hand, results in space-before and space-after of 18000mpt each, and that for both blocks. In terms of 4.3.1 Space-resolution Rules, we have two sequences of space-specifiers due to stacking constraints. On the before edge, we have case 1 (under 4.2.5 Stacking Constraints), and on the after edge, we have case 2. Agree All space-specifiers are not conditional, because of 5.3.2 (last sentence in first paragraph). So, rule 1 in 4.3.1 does not suppress any space-specifiers. Rule 2 doesn't apply, either, since no space-specifier is forcing. Going on to rule 3 we have to collapse the two space-specifiers to one. Agree What's the effect? The test now fails because the space-resolution wasn't taken into account. Furthermore, the result looks funny due to the background colors. Both times it's the last space-specifier that survives (rule 3, second part) and I'm strictly taking the last by looking at the block-progression-direction here. Agree I agree with your arguments. If I understand you correctly then this implies that the resulting space-start is 18000mpt, blue, and the space-end is 18000mpt, yellow. But I do not see that in the attached pdf file, in which the space-start is yellow and the space-end is blank. Simon So this may be a somewhat unexpected result but I think it's correct. If anyone could verify that, I'd be grateful. Agree I'm attaching the PDF output of my local code. Jeremias Maerki Manuel -- Simon Pepping home page: http://www.leverkruid.nl
Re: Static methods
[Peter] I noticed that you extracted numeric function methods as statics into a class of their own. Was this for aesthetic or performance reasons? The methods in NumericOp? They are called from multiple places which does not have anything in common. So I put the methods in NumericOp to avoid duplication of the few lines in each method. There was no performance reasons behind that decision. regards, finn
Re: Funny side-effects from space-resolution
On Thu, 29 Sep 2005 04:53 pm, Simon Pepping wrote: On Wed, Sep 28, 2005 at 10:48:11PM +0800, Manuel Mall wrote: Jeremias, looks OK to me although a bit strange but hey...that's the spec. On Wed, 28 Sep 2005 10:00 pm, Jeremias Maerki wrote: I've just stumbled over the testcase block_margin_inherit while fixing problems revealed by the test suite after having space-resolution work on blocks. Here's how it looks like: fo:flow flow-name=xsl-region-body fo:block margin=5% background-color=yellow fo:block margin=inherit background-color=blue margin=inherit - should have the same margin as the enclosing block /fo:block /fo:block fo:blockYellow block has margin=5% - 18pt margin based on 5in page width/fo:block /fo:flow The 5% in this case evaluate to 18000mpt. margin, as a short-hand, results in space-before and space-after of 18000mpt each, and that for both blocks. In terms of 4.3.1 Space-resolution Rules, we have two sequences of space-specifiers due to stacking constraints. On the before edge, we have case 1 (under 4.2.5 Stacking Constraints), and on the after edge, we have case 2. Agree All space-specifiers are not conditional, because of 5.3.2 (last sentence in first paragraph). So, rule 1 in 4.3.1 does not suppress any space-specifiers. Rule 2 doesn't apply, either, since no space-specifier is forcing. Going on to rule 3 we have to collapse the two space-specifiers to one. Agree What's the effect? The test now fails because the space-resolution wasn't taken into account. Furthermore, the result looks funny due to the background colors. Both times it's the last space-specifier that survives (rule 3, second part) and I'm strictly taking the last by looking at the block-progression-direction here. Agree I agree with your arguments. If I understand you correctly then this implies that the resulting space-start is 18000mpt, blue, and the space-end is 18000mpt, yellow. But I do not see that in the attached pdf file, in which the space-start is yellow and the space-end is blank. Simon, I don't think padding is suppose to extend into the space-before/after areas. So we have an 18pt space-start that is blank for the outer block which is repeated as space-after as well. The yellow background defined on the outer block covers the space-before/after of the inner block (= padding rectangle of the outer block). The blue background covers only the padding rectangle of the inner block. Simon Manuel So this may be a somewhat unexpected result but I think it's correct. If anyone could verify that, I'd be grateful. Agree I'm attaching the PDF output of my local code. Jeremias Maerki Manuel
Re: Static methods
Finn Bock wrote: [Peter] I noticed that you extracted numeric function methods as statics into a class of their own. Was this for aesthetic or performance reasons? The methods in NumericOp? They are called from multiple places which does not have anything in common. So I put the methods in NumericOp to avoid duplication of the few lines in each method. There was no performance reasons behind that decision. regards, finn Thanks Finn. I thought it might have been something you had learned about JVMs while working on Jython. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Cut off from my life line
If you don't see any replies from me at the moment, this is because it looks like a router in San Francisco is blocking my IP traffic to the Apache servers located in the US. That means I've got no SVN access and it also seems to affect the mails from the mailing lists which I currently don't get. Some time ago, the same router started to block clients from the German T-Online (as reported on infrastructure). Looks like my ISP is now affected, too. I bet this must have something to do with homeland security. *bg* Anyway, I will answer all the mails as soon as the blocking is lifted but I'll be in Paris during the weekend without internet connectivity, so you'll likely hear from me again next week. BTW, I'm in the fine-tuning phase for space resolution and conditional length handling. I'll upload my changes into a temporary branch for review as soon as I have SVN access again. Jeremias Maerki
Maintainability
Fopsters, I've always been somewhat sceptical of the new approach to page breaking, although I was prepared to concede that it would be a great achievement if you pulled it off. However, the closer the development has come to fruition, the more some of my original concerns have been reinforced. Think about the enormous amount of intellectual effort that has gone into mapping the problem into Knuthian. That effort is still under way. How is this going to be maintained? Where are the Knuthian speakers who are going to do that job over the next few years? I'm surprised, in fact, that some of the old hands have not raised this question already. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Maintainability
Peter B. West [EMAIL PROTECTED] wrote: Simon Pepping wrote: Maintaining FOP means maintaining a digital typesetting system means maintaining some of the best digital typography algorithms. I plan to resume my documenting activities in the coming months. I look forward to the challenge to document Knuth's algorithms and FOP's implementation of them in a clear and widely understandable fashion. That's a good thing, Simon, and your documentation is very comprehensive. However, I think the question still deserves serious consideration. You seem to be saying that inferior algorithms should be used for the sake of developers who don't have time to read the internals documentation. That doesn't seem like a worthwhile trade-off to me. -Peter-
DO NOT REPLY [Bug 36871] New: - Null Pointer exception in xsl mode
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=36871. 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=36871 Summary: Null Pointer exception in xsl mode Product: Fop Version: 0.20.5 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] When your XSL file contains a condition that isn't met, so that you don't have a fo:root to do anything with you get a null pointer execption. The xsl document looks like: xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:fo=http://www.w3.org/1999/XSL/Format; version=1.0 xsl:template match=VWSEARCHRESULTS fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; - The xml document looks like ?xml version=1.0 encoding=utf-8 ? VWSEARCHRESULT STATUS=success XMLNS=https://test.valuewizard.com/webServices; FAILUREDETAILS / WARNINGDETAILS / The problem is in the match= line in the template. That match= statement fails because there is a trailing S at the end of the word. Rather than reporting there is nothing to do, you get a Null pointer exception. -- 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 36871] - Null Pointer exception in xsl mode
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=36871. 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=36871 --- Additional Comments From [EMAIL PROTECTED] 2005-09-30 02:04 --- Created an attachment (id=16558) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16558action=view) XML file that causes the problem Note that the root element is VWSEARCHRESULT, NOT VWSEARCHRESULTS as the XSL file has said. -- 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.
