headers
Thomas DeWeese | 1 Sep 2005 01:36
Picon
Favicon

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

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
> DecimalFormat?

    Double.toString(double d),

    I just took a look, whats with the PDFNumber.doubleOut function????
It rounds numbers n+0.05 > x > n-0.05 to n (where n is an integer)?
That seems really hacky ;)

    Also I can almost assure you that NumberFormat will be _much_
faster than the current code.

> On 31.08.2005 14:32:01 Thomas DeWeese wrote:
> 
>>>I did a few things on PDFGraphics2D to improve the situation:
>>>http://svn.apache.org/viewcvs?rev=240344&view=rev
>>
>>    BTW Batik saw a significant performance increase when we went
>>to using a DecimalFormat object to write our strings.
> 
> 
> 
> 
> Jeremias Maerki
>
Permalink | Reply | 1 comment |
headers
Manuel Mall | 1 Sep 2005 03:01
Picon

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

I am getting a compile error:

compile-java:
    [javac] Compiling 426 source files to /home/mm/fop-ref/build/classes

[javac] /home/mm/fop-ref/src/java/org/apache/fop/fo/extensions/svg/SVGElement.java:89: 
cannot find symbol
    [javac] symbol  : method setDocumentURI(java.lang.String)
    [javac] location: class org.apache.batik.dom.svg.SVGOMDocument
    [javac]                 svgdoc.setDocumentURI(baseURL.toString());
    [javac]                       ^
    [javac] 1 error

Do we need a newer Batik version in the lib directory for this to work?

Manuel

On Thu, 1 Sep 2005 04:34 am, jeremias <at> apache.org wrote:
> Author: jeremias
> Date: Wed Aug 31 13:34:14 2005
> New Revision: 265578
>
> URL: http://svn.apache.org/viewcvs?rev=265578&view=rev
> Log:
> Set not only the base URL for the SVG Document but also the URI.
> Otherwise, relatively referenced documents or images inside an SVG
> defined in a fo:instream-foreign-object don't get resolved. This
> fixes certain problems with examples/fo/svg/external.fo.
>
> Modified:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Manuel Mall | 1 Sep 2005 03:02
Picon

Re: svn commit: r265577 [1/5] - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/area/ src/java/org/apache/fop/datatypes/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/expr/ src/java/org/apache/fop/fo/flow/ src/java/org/apache/fop/fo/pagination/...

Sorry, that was my mistake - need to configure NetBeans to  put the 
Apache license into new files generated by the IDE.

Manuel

On Thu, 1 Sep 2005 04:42 am, Jeremias Maerki wrote:
> Oops.
>
> On 31.08.2005 22:30:49 bckfnn wrote:
> > Author: bckfnn
> > Date: Wed Aug 31 13:29:33 2005
> > New Revision: 265577
> >
> > URL: http://svn.apache.org/viewcvs?rev=265577&view=rev
> > Log:
> > Bugzilla #36379:
> > Revised percentage resolution system.
> > Submitted by: Manuel Mall <mm.at.arcus.com.au>
> >
> > Slightly modified to avoid early evaluation of getValue().
>
> <snip/>
>
> > Added:
> > xmlgraphics/fop/trunk/src/java/org/apache/fop/datatypes/SimplePerce
> >ntBaseContext.java URL:
> > http://svn.apache.org/viewcvs/xmlgraphics/fop/trunk/src/java/org/ap
> >ache/fop/datatypes/SimplePercentBaseContext.java?rev=265577&view=aut
> >o
> > ===================================================================
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla | 1 Sep 2005 03:05
Picon
Favicon

DO NOT REPLY [Bug 36379] - [PATCH] Revised percentage resolution system

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=36379>.
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=36379

------- Additional Comments From mm <at> arcus.com.au  2005-09-01 03:05 -------
Finn, Thank you! 

--

-- 
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.
Permalink | Reply | 0 comments |
headers
Manuel Mall | 1 Sep 2005 03:18
Picon

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

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 which I believe has overwritten the version 
committed by Jeremias.

Manuel

On Wed, 31 Aug 2005 10:33 pm, jeremias <at> apache.org wrote:
> Author: jeremias
> Date: Wed Aug 31 07:32:59 2005
> New Revision: 265051
>
> URL: http://svn.apache.org/viewcvs?rev=265051&view=rev
> Log:
> Test case for squeezing an oversized image into a page. Currently
> fails because min/opt/max mechanisms currently ignored by the EGLM.
>
> Added:
>    
> xmlgraphics/fop/trunk/test/layoutengine/testcases/external-graphic4.x
>ml   (with props)
> xmlgraphics/fop/trunk/test/resources/images/big-image.png   (with
> props) Modified:
>     xmlgraphics/fop/trunk/test/layoutengine/disabled-testcases.txt
>
> Modified:
> xmlgraphics/fop/trunk/test/layoutengine/disabled-testcases.txt URL:
> http://svn.apache.org/viewcvs/xmlgraphics/fop/trunk/test/layoutengine
>/disabled-testcases.txt?rev=265051&r1=265050&r2=265051&view=diff
> =====================================================================
(Continue reading)

Permalink | Reply | 1 comment |
headers
Patrick Paul | 1 Sep 2005 04:47
Picon
Favicon

Re: FOP website, release preparations: refactoring necessary

Just an update to let you know I should have something ready to show you 
this week-end.

Patrick Paul

Jeremias Maerki wrote:

>Ok, so let's try to come up with a list. I see:
>
>The whole "Using FOP section"
>- compiling.xml
>- configuration.xml
>- running.xml
>- embedding.xml
>- servlets.xml
>- anttask.xml
>
>then most of "Features":
>- output.xml
>- pdfencryption.xml
>- graphics.xml
>- fonts.xml
>- hyphenation.xml
>- extensions.xml
>
>The only item left out is this last section was compliance.xml which
>contains information for both versions. I'm not sure what to do with it.
>
>On 29.08.2005 00:10:31 Patrick Paul wrote:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Manuel Mall | 1 Sep 2005 06:04
Picon

Re-organising layout engine testcases?

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 so one starts writing new ones which may already be covered.

I don't want to suggest some complex system with the associated 
management,  setup and on-going compliance overhead. But what about 
some simple naming system along the following lines: 

Most current tests (not all) cover a particular feature and can be 
described by the fo they target, the property they exercise and the 
particular aspect of that combination they test. Therefore giving each 
test file a name constructed like <fo name>[-<property name>]?
[-<feature>]?[<serial number>]?.xml., e.g.

table-padding-relative.xml will test relative padding values on a 
fo:table element.

Yes, this will give us some longer names but will make looking for a 
particular test much easier as simple directory search/sort/filter 
operations will do. It will also reduce the number of tests which are 
identified just by a different non descript number, that is things like 
padding1.xml, padding2.xml will be replaced by something more 
meaningful. And yes, it will not cover every case especially once we 
get into tests which deal with the interaction of multiple fos and 
properties.

If agreement is found on this I am not sure what the best way to 
actually do it with svn is. One way would be for someone (probably
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jeremias Maerki | 1 Sep 2005 08:14
Picon
Favicon

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

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 which I believe has overwritten the version 
> committed by Jeremias.
> 
> Manuel
> 
> On Wed, 31 Aug 2005 10:33 pm, jeremias <at> apache.org wrote:
> > Author: jeremias
> > Date: Wed Aug 31 07:32:59 2005
> > New Revision: 265051
> >
> > URL: http://svn.apache.org/viewcvs?rev=265051&view=rev
> > Log:
> > Test case for squeezing an oversized image into a page. Currently
> > fails because min/opt/max mechanisms currently ignored by the EGLM.
> >
> > Added:
> >    
> > xmlgraphics/fop/trunk/test/layoutengine/testcases/external-graphic4.x
> >ml   (with props)
> > xmlgraphics/fop/trunk/test/resources/images/big-image.png   (with
> > props) Modified:
> >     xmlgraphics/fop/trunk/test/layoutengine/disabled-testcases.txt
> >
> > Modified:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeremias Maerki | 1 Sep 2005 08:17
Picon
Favicon

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

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
> > DecimalFormat?
> 
>     Double.toString(double d),
> 
>     I just took a look, whats with the PDFNumber.doubleOut function????
> It rounds numbers n+0.05 > x > n-0.05 to n (where n is an integer)?
> That seems really hacky ;)
> 
>     Also I can almost assure you that NumberFormat will be _much_
> faster than the current code.
> 
> > On 31.08.2005 14:32:01 Thomas DeWeese wrote:
> > 
> >>>I did a few things on PDFGraphics2D to improve the situation:
> >>>http://svn.apache.org/viewcvs?rev=240344&view=rev
> >>
> >>    BTW Batik saw a significant performance increase when we went
> >>to using a DecimalFormat object to write our strings.
> > 
> > 
> > 
> > 
> > Jeremias Maerki
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeremias Maerki | 1 Sep 2005 08:39
Picon
Favicon

Re: Re-organising layout engine testcases?


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 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 so one starts writing new ones which may already be covered.

I agree.

> I don't want to suggest some complex system with the associated 
> management,  setup and on-going compliance overhead. But what about 
> some simple naming system along the following lines: 
> 
> Most current tests (not all) cover a particular feature and can be 
> described by the fo they target, the property they exercise and the 
> particular aspect of that combination they test. Therefore giving each 
> test file a name constructed like <fo name>[-<property name>]?
> [-<feature>]?[<serial number>]?.xml., e.g.
> 
> table-padding-relative.xml will test relative padding values on a 
> fo:table element.
> 
> Yes, this will give us some longer names but will make looking for a 
> particular test much easier as simple directory search/sort/filter
(Continue reading)

Permalink | Reply | 2 comments |

Gmane