Re: Failing tests

2005-11-14 Thread Jeremias Maerki
Same here. Christian, can you give us some details about your
environment? JDK version, OS, Ant Version...

On 14.11.2005 03:38:58 Manuel Mall wrote:
 On Mon, 14 Nov 2005 10:19 am, Christian Geisert wrote:
 snip/
 
 In BugZilla terminology: WORKSFORME
 
 
  And a dozen more with the same error.
 
 
  Christian
 
 Manuel



Jeremias Maerki



Re: Failing tests

2005-11-14 Thread Christian Geisert
Jeremias Maerki schrieb:
 Same here. Christian, can you give us some details about your
 environment? JDK version, OS, Ant Version...

I just tried it with a fresh checkout and it worked.
Sorry for the noise.

Christian


DO NOT REPLY [Bug 37330] - [PATCH] FOP Bridges not properly registered with Batik

2005-11-14 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=37330.
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=37330


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #16956|0   |1
is obsolete||




--- Additional Comments From [EMAIL PROTECTED]  2005-11-14 14:12 ---
Created an attachment (id=16962)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16962action=view)
Update to tweak.patch that works.

This fixes a stupid merge mistake.  Sorry for the confusion.

-- 
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: System.err

2005-11-14 Thread Jeremias Maerki
This is done now. Some printStackTrace() calls are left mainly in the
Graphics2D implementations. That will be looked at when we move them to
Commons.

We'll have quite a pile of work before us to improve the whole exception
handling. But that's not for today.

Thanks for reminding us about fixing the console output, Nils.

On 14.11.2005 11:43:57 Jeremias Maerki wrote:
 FYI, I'm working on that.
 
 The strategy is to remove stray System.out/err or
 Exception.printStackTrace() calls where possible, or pipe them to a logger
 instead. Some of those will need some additional work in the area of
 exception handling.
 
 On 13.11.2005 23:37:17 Nils Meier wrote:
  Hello
  
  just wanted to bring your attention to the fact that
  there's still quite a bit of System.err calls in
  FOP code.
  
  Is there a strategy for getting rid of those before
  the release?
  
  Thanks
  Nils
 
 
 
 Jeremias Maerki



Jeremias Maerki



DO NOT REPLY [Bug 37236] - [PATCH] Fix gradients and patterns

2005-11-14 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=37236.
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=37236





--- Additional Comments From [EMAIL PROTECTED]  2005-11-14 14:29 ---
(In reply to comment #11)
 Patch #10 applied. Thanks.

 I'm looking forward to moving the Transcoders out after the FOP release. :-)

   It will likely make this stuff easier to track.

 Is there anything outstanding concerning this bug or can we close it? 

   As I see it there are two outstanding issues:
  1) 'Complex' patterns on Text - While it is probably a 5% case it's 
 bad that things won't work.
  2) The overflow for pattern case being commented out.

   I would lean towards saying this is still broken enough to leave the
bug open, but it's not my bug DB (so to speak).  Having it open makes
it at least possible that someone will have an answer to their question.

 It starts to get confusing which patches are to be applied and 
 so on. 

   Yes, I strongly considered going to a single PDFTranscoder patch instead
of trying to track everything seperately.

 I assume you'll also help track the currently commented part that 
 we'll have to uncomment as soon as we can rely on a later Batik version.

   I'll try and make sure of it.  What do you think of a Batik 1.6.1
release?  There are a number of small but significant improvements
in Batik since 1.6.1.  The real hurdle would be straightening out
the XML lib lincensing (which really needs to be fixed anyways).


-- 
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 37330] - [PATCH] FOP Bridges not properly registered with Batik

2005-11-14 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=37330.
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=37330


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-11-14 17:03 ---
Got the little bugger. :-) No more clipped text when painted through the PDF
text painter:
http://svn.apache.org/viewcvs?rev=344148view=rev

-- 
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 37236] - [PATCH] Fix gradients and patterns

2005-11-14 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=37236.
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=37236





--- Additional Comments From [EMAIL PROTECTED]  2005-11-14 17:07 ---
(In reply to comment #12)
snip/
  Is there anything outstanding concerning this bug or can we close it? 
 
As I see it there are two outstanding issues:
   1) 'Complex' patterns on Text - While it is probably a 5% case it's 
  bad that things won't work.
   2) The overflow for pattern case being commented out.
 
I would lean towards saying this is still broken enough to leave the
 bug open, but it's not my bug DB (so to speak).  Having it open makes
 it at least possible that someone will have an answer to their question.

Ok.

snip/
  I assume you'll also help track the currently commented part that 
  we'll have to uncomment as soon as we can rely on a later Batik version.
 
I'll try and make sure of it.  What do you think of a Batik 1.6.1
 release?  There are a number of small but significant improvements
 in Batik since 1.6.1.  The real hurdle would be straightening out
 the XML lib lincensing (which really needs to be fixed anyways).

It's on my list to help you with the XML libs as soon as the FOP release is off
my desk. Anyway, I think a Batik 1.6.1 is a good idea. A lot of things have been
done since the last release.



-- 
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: Preparing for the first release

2005-11-14 Thread Christian Geisert
Manuel Mall schrieb:

[..]

IMHO there should be a changes document (as part of the
distribution), at least starting after the 1.0 release.
 
 Yes there should - but for now: Just remove CHANGES and update README?

I'd say yes.

-- 
Christian


DO NOT REPLY [Bug 36480] - [PATCH] Space support in RTF rendering

2005-11-14 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=36480.
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=36480


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-11-14 19:28 ---
Sergey, thank you very much for another wonderful patch and for providing the
test cases. That was a good fix. You could almost win a price for code beauty.
:-) Not a single Checkstyle warning. Sorry for the delay applying the patch.

Just too bad, RTF is not as expressive as XSL-FO, so it's impossible to map
space conditionality and space resolution to RTF. But then, this is probably
good enough. Few people will create one single FO for output on PDF and RTF
simultaneously and expect the same output.

Revision: http://svn.apache.org/viewcvs?rev=344172view=rev

-- 
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: Preparing for the first release - Examples

2005-11-14 Thread Jeremias Maerki

On 13.11.2005 19:53:32 Andreas L Delmelle wrote:
 On Nov 13, 2005, at 18:00, Andreas L Delmelle wrote:
 
  On Nov 13, 2005, at 17:36, Jeremias Maerki wrote:
 
  snip /
  The other question is:
  What's the box? The containing area?
 
  Yep. I think this is answered in the definition of absolute- 
  position=absolute:
 
  First, for the value of absolute
  The area's position (and possibly size) is specified with the  
  'left', 'right', 'top', and 'bottom' properties. These properties  
  specify offsets with respect to the area's containing area.
 
 In XSL-FO 1.1, the wording is slightly different BTW:
 These properties specify offsets with respect to the area's nearest  
 ancestor reference area.
 
 Does this make it simpler or more difficult? Wouldn't this mean that  
 I wasn't confused at all?

And me, neither. My checks wouldn't be so wrong. But it means that the
spec changed in a backwards-incompatible way. And we will have to change
the meaning/implementation of the top property. Right now it offsets
the b-c relative to the top of the containing box, AFAICS. Well, I'll
leave this for after the release. Thanks for digging into the 1.1 draft!


Jeremias Maerki



Re: Preparing for the first release

2005-11-14 Thread Vincent Hennebert

Manuel Mall a écrit :
As the project hasn't done a release for a long time and especially no 
release of the new codebase we should test probably a bit more 
extensively than usual that the distribution builds actually are 
working and don't contain any 'cheap' errors.


To that effect I have build binary and source distributions from the 
current svn and made them available for download from 
http://people.apache.org/~manuel/fop/disttest. In the top level 
directory are the source and the java 1.4+ binary distributions. In the 
java1.3.1 directory are only binary distributions. 


I'm on a Debian GNU/Linux environment with both java 1.4.2 and java 1.5. I have 
encountered no particular problem by running the binary version on a few sample 
fo files. The source distribution also seems to build and run fine.


My 2 cents...
Vincent



Re: Preparing for the first release

2005-11-14 Thread Jeremias Maerki
I agree with you two. Therefore, I've resurrected status.xml, added it
to our website again and prepared it so we can start using it after the
release.

BTW, I think I'm through with all the things I wanted to do. What's left
now:
- write the README/release notes
- Create a copy of the xdocs/trunk directory to xdocs/0.90alpha1.
- do the (PMC) vote on the release.
- tag and release

If it's possible I'd like to start the vote tomorrow and do the release
around Thursday/Friday. That reasonable?

On 14.11.2005 18:12:22 Christian Geisert wrote:
 Manuel Mall schrieb:
 
 [..]
 
 IMHO there should be a changes document (as part of the
 distribution), at least starting after the 1.0 release.
  
  Yes there should - but for now: Just remove CHANGES and update README?
 
 I'd say yes.
 
 -- 
 Christian



Jeremias Maerki



fo:marker and white space

2005-11-14 Thread Manuel Mall
I was looking at clipping warnings generated by 
examples/fo/markers/hide.fo when I noticed that white space around 
fo:marker seems significant with respect to the output generated when 
the marker is retrieved, e.g.:

fo:marker
   fo:block
 some text
   /fo:block
/fo:marker

when retrieved produces:

empty line
some text
empty line

while:

fo:markerfo:blocksome text/fo:block/fo:marker

just generates:

some text

I am suspicious that this is wrong and both inputs should produce the 
same output.

For a test case and its output see:
http://people.apache.org/~manuel/fop/marker_test.xml
http://people.apache.org/~manuel/fop/marker_test.pdf

Manuel