Re-organising layout engine testcases?

2005-09-01 Thread Manuel Mall
We now have over 200 layout engine test cases in the repository which is great. However, with this ever growing number I wonder if we should put some more structure to it. There is a real chance that we get more and more duplication just because people wouldn't know which tests are doing what

Re: svn commit: r265051 - in /xmlgraphics/fop/trunk/test: layoutengine/disabled-testcases.txt layoutengine/testcases/external-graphic4.xml resources/images/big-image.png

2005-09-01 Thread Jeremias Maerki
I've already seen it and intend to fix it this morning (CEST). Thanks for the hint nonetheless. On 01.09.2005 03:18:33 Manuel Mall wrote: We may have a case of the lost update problem here. My percentage resolution patch which Finn kindly applied provided a testcase external-graphic4.xml

Re: DO NOT REPLY [Bug 35918] - [PATCH] Shapes are slightly shifted with respect to lines on larger graphics

2005-09-01 Thread Jeremias Maerki
Thanks. I'm convinced now that I should rewrite PDFNumber.doubleOut(). On 01.09.2005 01:36:12 Thomas DeWeese wrote: Jeremias Maerki wrote: Thanks for the hint. Sounds like rewriting PDFNumber.doubleOut using DecimalFormat makes sense. May I ask what you used before switching to

Re: Re-organising layout engine testcases?

2005-09-01 Thread Jeremias Maerki
On 01.09.2005 06:04:45 Manuel Mall wrote: We now have over 200 layout engine test cases in the repository which is great. Wow! I just hope nobody holds a grudge against me for introducing that facility and pushing people to use it. ;-) However, with this ever growing number I wonder if we

Re: Re-organising layout engine testcases?

2005-09-01 Thread Jeremias Maerki
That's certainly a good idea. On 01.09.2005 08:49:02 Manuel Mall wrote: snip/ OK, what about me making up a big rename script like: svn move padding1.xml character-padding-relative.xml svn move padding2.xml basic-link-padding.xml and a committer can apply that? Jeremias Maerki

Re: svn commit: r265578 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/extensions/svg/SVGElement.java

2005-09-01 Thread Jeremias Maerki
Note to self: If doing a change that involves a dependency, always run the command-line build prior to a commit if you have the latest trunk set up in the IDE. Sorry, guys. I've reverted the change and I'm going to investigate further what to do about the problem. AbstractDocument.setDocumentURI

DO NOT REPLY [Bug 36455] - [PATCH] Backwards compatibility fix for SVGOMElement.getCascadedXMLBase()

2005-09-01 Thread bugzilla
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=36455. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

FYI: Bugzilla updates ordered

2005-09-01 Thread Jeremias Maerki
http://issues.apache.org/jira/browse/INFRA-537 Jeremias Maerki

Re: FYI: Bugzilla updates ordered

2005-09-01 Thread Christian Geisert
Jeremias Maerki schrieb: http://issues.apache.org/jira/browse/INFRA-537 Uh, no need to bother infrastructure. As I have some admin rights for bugzilla I'll have a look at it later today. (Just tried to assign this issue to myself but it seems I don't have permission) -- Christian

Re: FYI: Bugzilla updates ordered

2005-09-01 Thread Jeremias Maerki
D'oh. Didn't know that. Thanks for handing that. On 01.09.2005 11:41:02 Christian Geisert wrote: Jeremias Maerki schrieb: http://issues.apache.org/jira/browse/INFRA-537 Uh, no need to bother infrastructure. As I have some admin rights for bugzilla I'll have a look at it later today. (Just

DO NOT REPLY [Bug 36455] - [PATCH] Backwards compatibility fix for SVGOMElement.getCascadedXMLBase()

2005-09-01 Thread bugzilla
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=36455. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

DO NOT REPLY [Bug 36460] New: - [PATCH] Renaming of testcases

2005-09-01 Thread bugzilla
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=36460. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

DO NOT REPLY [Bug 36460] - [PATCH] Renaming of testcases

2005-09-01 Thread bugzilla
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=36460. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

DO NOT REPLY [Bug 36460] - [PATCH] Renaming of testcases

2005-09-01 Thread bugzilla
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=36460. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

DO NOT REPLY [Bug 36455] - [PATCH] Backwards compatibility fix for SVGOMElement.getCascadedXMLBase()

2005-09-01 Thread bugzilla
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=36455. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

DO NOT REPLY [Bug 36460] - [PATCH] Renaming of testcases

2005-09-01 Thread bugzilla
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=36460. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

DO NOT REPLY [Bug 36460] - [PATCH] Renaming of testcases

2005-09-01 Thread bugzilla
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=36460. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

Re: SVG Image cropping/positioning

2005-09-01 Thread Jeremias Maerki
Richard, is there a problem left to be looked at? I'm not sure from reading your posts. On 31.08.2005 15:43:21 richardw wrote: Jeremias Maerki writes: Weird. This test case works for me and it is not disabled (see disabled-testcases.txt). What does the Area Tree XML look like (found

Re: Exceptions

2005-09-01 Thread Jeremias Maerki
No surprise, actually. The tables all use the collapsing border model. But tell me, have they updated the NIST test suite for XSL Rec 1.0? I remember that at a stand-still in working-draft stage (master-name instead of master-reference). On 01.09.2005 14:45:30 Finn Bock wrote: Hi Running the

Re: Exceptions

2005-09-01 Thread Finn Bock
[Jeremias] No surprise, actually. The tables all use the collapsing border model. But tell me, have they updated the NIST test suite for XSL Rec 1.0? I remember that at a stand-still in working-draft stage (master-name instead of master-reference). Years back, when we last talked about the

e-g with padding and borders

2005-09-01 Thread Manuel Mall
I think the area tree viewport generated by the current version for an e-g with padding and borders is wrong. Here is the fo snippet (from external-graphic_border_padding.xml): fo:external-graphic src=../../resources/images/bgimg300dpi.jpg border=solid 5pt padding=5pt

Re: e-g with padding and borders

2005-09-01 Thread Jeremias Maerki
This is definitely wrong, you're right. I know how that got through the tests: The checks are insufficient. The stuff that is checked is definitely ok. But bpd/ipd are not checked. That's the problem. On 01.09.2005 15:53:46 Manuel Mall wrote: I think the area tree viewport generated by the

Re: e-g with padding and borders

2005-09-01 Thread Manuel Mall
On Thu, 1 Sep 2005 10:13 pm, Jeremias Maerki wrote: This is definitely wrong, you're right. I know how that got through the tests: The checks are insufficient. The stuff that is checked is definitely ok. But bpd/ipd are not checked. That's the problem. Thanks - I'll fix the problem and the

Re: SVG Image cropping/positioning

2005-09-01 Thread richardw
Jeremias Maerki writes: Richard, is there a problem left to be looked at? I'm not sure from reading your posts. Yes. The external svg handling is broken. I'll get some new testcases together at some point to demonstrate the effect. In the meantime just get two or three large svg images and

Re: FYI: Bugzilla updates ordered

2005-09-01 Thread Jeremias Maerki
On 01.09.2005 16:46:17 Christian Geisert wrote: Christian Geisert schrieb: Jeremias Maerki schrieb: http://issues.apache.org/jira/browse/INFRA-537 Uh, no need to bother infrastructure. As I have some admin rights for bugzilla I'll have a look at it later today. Ok, I've added 1.6

Re: e-g with padding and borders

2005-09-01 Thread Jeremias Maerki
Indeed, the normal allocation rectangle of an inline area is different than the one of a block area. See 4.3.2. Geometric Definitions in the 1.0 spec. Border and padding for an inline area seem to be outside the allocation rectangle in before and after directions. Interesting. On 01.09.2005

Re: FYI: Bugzilla updates ordered

2005-09-01 Thread Christian Geisert
Jeremias Maerki schrieb: On 01.09.2005 16:46:17 Christian Geisert wrote: [..] As we already have a 'pdf renderer' and 'awt renderer' component, is the new 'renderers' component meant for 'General Renderer issues'? Should we also add 'ps renderer', 'pcl renderer' and 'rtf' components? I

Re: e-g with padding and borders

2005-09-01 Thread Vincent Hennebert
I'm not sure here. The fo:external-graphic uses the large-allocation-rectangle (§ 6.6.5), that comprises padding and border. This makes me say that in Manuel's example the fo:block's bpd should be calculated with the second formula. The fo:block's content forms a line whose

Re: FOP extension to output custom PostScript instructions

2005-09-01 Thread Jeremias Maerki
You got me thinking about extensions, Finn. I've written down my thoughts in the Wiki [1]. I don't have time to implement the full extent of my ideas right now, but I think I'll try to implement the PS extensions in the way I outlined them on that page. If anyone wants more information I can add

Re: e-g with padding and borders

2005-09-01 Thread Jeremias Maerki
Oh right. Again someone caught me shooting too fast from the hip. Damn. I will probably never manage to get that right. :-( It's good to have people around to pay attention. I wondered about the large-allocation-rectangle while reading through 6.3.2 but obviously forgot to check the docs for e-g

Re: SVG Image cropping/positioning

2005-09-01 Thread Jeremias Maerki
I haven't found anything odd, yet. Looking forward to your test cases. On 01.09.2005 16:21:43 richardw wrote: Jeremias Maerki writes: Richard, is there a problem left to be looked at? I'm not sure from reading your posts. Yes. The external svg handling is broken. I'll get some new

Re: e-g with padding and borders

2005-09-01 Thread Manuel Mall
Vincent, Jeremias, thanks for the clarification. After looking just a little bit more into it it appears the current fop version is dealing pretty badly with inline borders and padding. There seem to be no testcases for it either. I'll attach 2 files. A simple test case. The pdf output