Re: JPdfUnit

[Manuel Mall]

On Tue, 20 Sep 2005 02:34 pm, Jeremias Maerki wrote:

>
> But the underlying PDF library looks quite interesting (PDFBox). Has
> anyone had any experiences with it? If yes, we should add it to our
> PDF post-processors list on the website, if just because it has a
> better license than iText.

I am using it in a project which provides on-line searchable PDF files 
(Government Acts and Regulations) indexed using Lucene and in that 
context it works fine, that is as a backend activity PDFBox extracts 
the text components from the PDF for Lucene to index and as an on-line 
activity once matching documents are found the PDF is searched again 
using PDFBox to find the search terms in the PDF file so an Acrobat 
highlight XML file can be constructed.


>
> Jeremias Maerki

Manuel

Re: JPdfUnit

[Jeremias Maerki]

Theoretically, yes, but I currently don't see any real added value
compared to layoutengine+visual tests. And after all, someone would have
to write them. :-)

If we had something like that for RTF it would be preferred. :-) I'd
prefer anything to remote controlling Word.

But the underlying PDF library looks quite interesting (PDFBox). Has
anyone had any experiences with it? If yes, we should add it to our PDF
post-processors list on the website, if just because it has a better
license than iText.

On 19.09.2005 21:52:22 J.Pietschmann wrote:
> Hi all,
> fresh on freshmeat:
>   http://freshmeat.net/releases/207188/
> 
> Can this be used to provide tests for the PDF renderer?
> 
> J.Pietschmann



Jeremias Maerki

Re: rtf ignoring TableBody et al

[Jeremias Maerki]

I added the warning because I found a case where a block-container
wasn't handled as it should have been:
http://svn.apache.org/viewcvs?rev=278720&view=rev

The warning is an indicator that there are still a few things in RTF
support that need fixing.

On 20.09.2005 00:28:56 Matthew L Daniel wrote:
> I am using trunk code and with an input FO that produces excellent PDF
> output, I am seeing the following messages about lots of ignored
> instances.
> 
> After checking RTFHandler.java, it seems they are omitted from the very
> large instance-switch in "invokeDeferredEvent".
> 
> My question is if this is "in progress" code or if RTFHandler has been
> broken like this for a while?
> 
> I tried to be clever and hack support for them back in, but it went very
> poorly.
> 
>   Thanks for your time,
>   -- /v\atthew
> 
> > Ignored deferred event for [EMAIL PROTECTED]
> > Ignored deferred event for [EMAIL PROTECTED]
> > Ignored deferred event for [EMAIL PROTECTED]
> > Ignored deferred event for [EMAIL PROTECTED]
> > Ignored deferred event for [EMAIL PROTECTED]
> > Ignored deferred event for [EMAIL PROTECTED]
> > Ignored deferred event for [EMAIL PROTECTED]
> > Ignored deferred event for [EMAIL PROTECTED]
> > Ignored deferred event for [EMAIL PROTECTED]
> > Ignored deferred event for [EMAIL PROTECTED]
> > Ignored deferred event for [EMAIL PROTECTED]
> > Ignored deferred event for [EMAIL PROTECTED]
> > Ignored deferred event for [EMAIL PROTECTED]
> > ... this continues for quite a while ...



Jeremias Maerki

Re: svn commit: r289865 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/ fo/flow/ fo/properties/ layoutmgr/table/

[Jeremias Maerki]

On 19.09.2005 23:19:46 Andreas L Delmelle wrote:
> On Sep 19, 2005, at 18:03, Andreas L Delmelle wrote:
> 
> > On Sep 19, 2005, at 11:08, Jeremias Maerki wrote:
> >
> >> Looks ok on first glance, though I've got a request: Would you please
> >> consider installing a checkstyle plug-in into your IDE and configuring
> >> the rules file for FOP? Thanks!
> >
> > Dammit! And I thought I had all bases covered... :-(
> >
> > My apologies for this. I hope it didn't cause too much inconvenience.
> 
> Ok, corrected most of my violations.

Thanks!

> BTW: is it necessary for the FOTree tests to have an Apache header as 
> well? Let me know, and I'll add them too...

Yes. http://www.apache.org/dev/apply-license.html says:

"The license is applied to each source file (code and documentation, but
excluding the LICENSE and NOTICE files) by including a short copyright
notice at the top, as demonstrated by the boilerplate notice provided in
the appendix."

In theory, all our files should have a license header where the format
allows it (i.e. it's obviously difficult for bitmap etc.).

Jeremias Maerki

Re: svn commit: r289865...

[Andreas L Delmelle]

On Sep 19, 2005, at 23:19, Andreas L Delmelle wrote:



Ok, corrected most of my violations.


'Most', I said... :-S
There's still a few left, but bug 36720 came up, so the others will be 
committed together with the bugfix. Seems I've been quite sloppy in a 
few places... put too much focus on the difficult cases --hey, that 
rhymes :-)



Cheers,

Andreas

Re: rtf ignoring TableBody et al

[Andreas L Delmelle]

On Sep 20, 2005, at 00:28, Matthew L Daniel wrote:


I am using trunk code and with an input FO that produces excellent PDF
output, I am seeing the following messages about lots of ignored
instances.

After checking RTFHandler.java, it seems they are omitted from the very
large instance-switch in "invokeDeferredEvent".

My question is if this is "in progress" code or if RTFHandler has been
broken like this for a while?


Seems like it's broken. At least, there's a few node-types missing, 
amongst which precisely TableBody, TableHeader, TableFooter, 
InstreamForeignObject, SVGElement, ExternalGraphic...


I'm going to leave this for now, since I don't know too much about the 
RTF Rendering code --maybe those node-types were left out for a good 
reason, I'm not sure.


At first glance, the whole structure:

if( fo instanceof PageSequence ) {
  //do something
} else if( fo instanceof Flow ) {
  //do something
} ...

would probably better be replaced by one

switch( fo.getNameId() ) {
case Constants.FO_PAGE_SEQUENCE:
  //do something
  break;
case Constants.FO_FLOW:
  //do something
  break;
  ...
}

The least this would do is avoid a number of unnecessary calls to 
instanceof.


Note to Peter Herweg: I think I see now what you meant by the many 
'if-then-else-if's. I hope you can put the above comment to good use...



Cheers,

Andreas

DO NOT REPLY [Bug 36720] - erroneous cell overlap code

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=36720


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|normal  |major
 Status|NEW |ASSIGNED




--- Additional Comments From [EMAIL PROTECTED]  2005-09-20 00:57 ---
Sorry, I'll have a look ASAP. Is caused by my implementation for default 
column-numbers.
Such a simple example, and yet...?

Will get back on this tomorrow.



-- 
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 36720] - erroneous cell overlap code

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=36720





--- Additional Comments From [EMAIL PROTECTED]  2005-09-20 00:50 ---
Created an attachment (id=16452)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16452&action=view)
Testcase showing my error


-- 
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 36720] New: - erroneous cell overlap code

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=36720

   Summary: erroneous cell overlap code
   Product: Fop
   Version: 1.0dev
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: fo tree
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


Fop-HEAD worked on Friday, but when I refreshed this morning it would no longer
render my nested table.

I isolated the issue and created a fotree/testcase for it.

[junit] org.apache.fop.apps.FOPException:
file:///usr/src/cvs/apache/fop/test/fotree/testcases/column-number_nested.fo:29:38:
cell overlaps in column 2
[junit] javax.xml.transform.TransformerException:
org.apache.fop.apps.FOPException:
file:///usr/src/cvs/apache/fop/test/fotree/testcases/column-number_nested.fo:29:38:
cell overlaps in column 2
[junit] at
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:501)
[junit] at
org.apache.fop.fotreetest.FOTreeTester.runTest(FOTreeTester.java:65)
[junit] at
org.apache.fop.fotreetest.FOTreeTestSuite$FOTreeTestCase.testMain(FOTreeTestSuite.java:121)
[junit] at
org.apache.fop.fotreetest.FOTreeTestSuite$1.runTest(FOTreeTestSuite.java:100)
[junit] Caused by: org.apache.fop.apps.FOPException:
file:///usr/src/cvs/apache/fop/test/fotree/testcases/column-number_nested.fo:29:38:
cell overlaps in column 2
[junit] at org.apache.fop.fo.flow.TableCell.bind(TableCell.java:139)
[junit] at org.apache.fop.fo.FObj.processNode(FObj.java:121)
[junit] at
org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:271)

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

Fwd: undefined page length

[Andreas L Delmelle]

Begin forwarded message (from fop-users)


From: Andreas L Delmelle <[EMAIL PROTECTED]>

On Sep 19, 2005, at 09:49, Jeremias Maerki wrote:


On 19.09.2005 09:36:49 Willy Reinhardt wrote:

Is it possible to create a pdf with all content into one page with
length adapted accordingly ?



No, this hasn't been implemented, yet. That would be
media-usage="bounded-in-one-dimension" on fo:root. Patches against FOP
Trunk are welcome.


For the sake of completeness:
page-height="indefinite" on fo:simple-page-master would also be 
relevant here, IIC.


BTW: Is it a correct assessment that implementing this should turn out 
to be far simpler than fixed page-sizes? IIC, theoretically, the whole 
page-breaking algorithm can be ignored for indefinite page-heights. 
getAvailableBPD() would always return, say, Integer.MAX_VALUE?


I'll look into it. Seems like a perfect opportunity to familiarize 
myself a bit more with the layout code.


If anyone has any pointers to offer, these would be much appreciated.

Cheers,

Andreas

rtf ignoring TableBody et al

[Matthew L Daniel]

I am using trunk code and with an input FO that produces excellent PDF
output, I am seeing the following messages about lots of ignored
instances.

After checking RTFHandler.java, it seems they are omitted from the very
large instance-switch in "invokeDeferredEvent".

My question is if this is "in progress" code or if RTFHandler has been
broken like this for a while?

I tried to be clever and hack support for them back in, but it went very
poorly.

  Thanks for your time,
  -- /v\atthew

> Ignored deferred event for [EMAIL PROTECTED]
> Ignored deferred event for [EMAIL PROTECTED]
> Ignored deferred event for [EMAIL PROTECTED]
> Ignored deferred event for [EMAIL PROTECTED]
> Ignored deferred event for [EMAIL PROTECTED]
> Ignored deferred event for [EMAIL PROTECTED]
> Ignored deferred event for [EMAIL PROTECTED]
> Ignored deferred event for [EMAIL PROTECTED]
> Ignored deferred event for [EMAIL PROTECTED]
> Ignored deferred event for [EMAIL PROTECTED]
> Ignored deferred event for [EMAIL PROTECTED]
> Ignored deferred event for [EMAIL PROTECTED]
> Ignored deferred event for [EMAIL PROTECTED]
> ... this continues for quite a while ...

DO NOT REPLY [Bug 36677] - [PATCH] ant dist does not include serializer.jar

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=36677





--- Additional Comments From [EMAIL PROTECTED]  2005-09-19 23:31 ---
(In reply to comment #2)
> I'm already looking at build dist to include the docs ...

I don't follow this comment. "Docs?"

Perhaps most important to the bug report, does the command 'ant dist; mkdir foo;
tar xzf *-bin.tar.gz -C foo; sh foo/*/fop.sh -fo examples/fo/basic/simple.fo 
-awt' 
work for you? If so, do you have serializer*.jar in ${java.endosred.dirs}?

-- 
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.
You are on the CC list for the bug, or are watching someone who is.

Re: svn commit: r289865 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/ fo/flow/ fo/properties/ layoutmgr/table/

[Andreas L Delmelle]

On Sep 19, 2005, at 18:03, Andreas L Delmelle wrote:


On Sep 19, 2005, at 11:08, Jeremias Maerki wrote:


Looks ok on first glance, though I've got a request: Would you please
consider installing a checkstyle plug-in into your IDE and configuring
the rules file for FOP? Thanks!


Dammit! And I thought I had all bases covered... :-(

My apologies for this. I hope it didn't cause too much inconvenience.


Ok, corrected most of my violations.

BTW: is it necessary for the FOTree tests to have an Apache header as 
well? Let me know, and I'll add them too...


Cheers,

Andreas

DO NOT REPLY [Bug 36625] - Percentage IPD incorrect in side regions

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=36625


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-09-19 22:32 ---
It seems as if Jeremias cleanly corrected this problem last week, at least for
side-regions (which was what the bug was about) :

http://svn.apache.org/viewcvs?rev=289426&view=rev

Thanks :)

I hope it's ok if I close the bug myself ? 

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

JPdfUnit

[J.Pietschmann]

Hi all,
fresh on freshmeat:
 http://freshmeat.net/releases/207188/

Can this be used to provide tests for the PDF renderer?

J.Pietschmann

Re: List and Item display

[J.Pietschmann]

siarom egrub wrote:

I am trying to have the s in an
 to display numerical values. The XSLFO
template below that I've developed is displaying zeros
"0" for all the list items.

...


   
 
   
 
 

You are matching orderedlist/listitem/para above and
counting orderedlist/listitem here. The para elements
don't have these descendants, and you get 0. Furthermore,
you create a list-block for every single list item in your
ordered list, which is probably not what you intended.

A more correct approach would be


   

 
   
 
 
 
   
   
  
   
 

   


You might have to provide an appropriate template matching para
elements.


Note that this is actually an XSLT question. You get faster replies
for this kind of questions if you ask on the XSL list:
  http://www.mulberrytech.com/xsl/xsl-list/

J.Pietschmann

Re: svn commit: r289865 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/ fo/flow/ fo/properties/ layoutmgr/table/

[Andreas L Delmelle]

On Sep 19, 2005, at 11:08, Jeremias Maerki wrote:


Looks ok on first glance, though I've got a request: Would you please
consider installing a checkstyle plug-in into your IDE and configuring
the rules file for FOP? Thanks!


Dammit! And I thought I had all bases covered... :-(

My apologies for this. I hope it didn't cause too much inconvenience.


Cheers,

Andreas

List and Item display

[siarom egrub]

Hi All!

I am trying to have the s in an
 to display numerical values. The XSLFO
template below that I've developed is displaying zeros
"0" for all the list items. Could someone please
inform me what I am doing incorrectly here, or the
correct way to accomplish this task?

Thanks in advance for your help!

~S.E.


===XSLFO TEMPLATE


   
 
   
 
 
 
   
   
  
   
 
   




===XML Snippet  



  First list item.


  Second list item.


  Third list item.




The current output (display) is like this:

0 First list item.
0 Second list item.
0 Third list item.

This is the output (display) that I want:

1. First list item.
2. Second list item.
3. Third list item.




__ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: Build error?

[Jeremias Maerki]

I've commented out the offending code. I don't really know what to do
with it. It would probably be cleanest if the cli package wrote to the
console using System.out/err only and only sets up the logger for the
rest of FOP. Hmmm.

On 19.09.2005 15:05:26 Manuel Mall wrote:
> Luca,
> 
> not sure if this is it but in CommandLineOptions we have:
> 
> if (System.getProperty("org.apache.commons.logging.Log") == null) {
>  logFactory.setAttribute("org.apache.commons.logging.Log",
>  CommandLineLogger.class.getName());
>setLogLevel("info");
> }
> log = LogFactory.getLog("FOP");
> 
> i.e. the log instance is created after the call to setLogLevel(...). But 
> setLogLevel starts with:
> ...
> if (log instanceof CommandLineLogger) {
> 
> so you are hitting a likely NPE here.
> 
> Manuel
> On Mon, 19 Sep 2005 08:57 pm, Luca Furini wrote:
> > Hi all.
> >
> > I'm noticing a strange problem: fop builds correctly, but then it
> > seems it is not working at all.
> >
> > I'm using it from the command line under win xp, and even if I don't
> > get any run time exception no output file is created. Launching fop
> > with no parameters, or with wrong parameters (missing files ...) does
> > not create any error: simply, nothing happens.
> >
> > I have compiled fop on two different computers, so I don't think this
> > is a local configuration problem.
> >
> > Hasn't anyone else noticed this?
> >
> > Regards
> >  Luca



Jeremias Maerki

Re: Build error?

[Manuel Mall]

Luca,

not sure if this is it but in CommandLineOptions we have:

if (System.getProperty("org.apache.commons.logging.Log") == null) {
 logFactory.setAttribute("org.apache.commons.logging.Log",
 CommandLineLogger.class.getName());
   setLogLevel("info");
}
log = LogFactory.getLog("FOP");

i.e. the log instance is created after the call to setLogLevel(...). But 
setLogLevel starts with:
...
if (log instanceof CommandLineLogger) {

so you are hitting a likely NPE here.

Manuel
On Mon, 19 Sep 2005 08:57 pm, Luca Furini wrote:
> Hi all.
>
> I'm noticing a strange problem: fop builds correctly, but then it
> seems it is not working at all.
>
> I'm using it from the command line under win xp, and even if I don't
> get any run time exception no output file is created. Launching fop
> with no parameters, or with wrong parameters (missing files ...) does
> not create any error: simply, nothing happens.
>
> I have compiled fop on two different computers, so I don't think this
> is a local configuration problem.
>
> Hasn't anyone else noticed this?
>
> Regards
>  Luca

Build error?

[Luca Furini]

Hi all.

I'm noticing a strange problem: fop builds correctly, but then it seems it 
is not working at all.


I'm using it from the command line under win xp, and even if I don't get 
any run time exception no output file is created. Launching fop with no 
parameters, or with wrong parameters (missing files ...) does not create 
any error: simply, nothing happens.


I have compiled fop on two different computers, so I don't think this 
is a local configuration problem.


Hasn't anyone else noticed this?

Regards
Luca

[EMAIL PROTECTED]: Project xml-fop-maintenance (in module xml-fop-maintenance) failed

[Sam Ruby]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project xml-fop-maintenance has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 12 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- xml-fop-maintenance :  XSL-FO (Formatting Objects) processor (Maintenance 
branch)


Full details are available at:

http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [fop.jar] identifier set to project name
 -INFO- Made directory 
[/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes]
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/gump_work/build_xml-fop-maintenance_xml-fop-maintenance.html
Work Name: build_xml-fop-maintenance_xml-fop-maintenance (Type: Build)
Work ended in a state of : Failed
Elapsed: 2 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only gump 
[Working Directory: /usr/local/gump/public/workspace/xml-fop-maintenance]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-19092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-19092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-19092005.jar
-
Buildfile: build.xml

init-avail:

init-filters-jdk14:
 [echo] JDK 1.4 present.
 [copy] Copying 1 file to 
/x1/gump/public/workspace/xml-fop-maintenance/build/src/codegen

init-filters-jdk13:

init:
 [echo] --- Fop 0.20.5 [1999-2003] 

prepare:
 [echo] Preparing the build directories
[mkdir] Created dir: 
/x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/fo/properties
[mkdir] Created dir: 
/x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/render/pdf/fonts
[mkdir] Created dir: 
/x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apa

[EMAIL PROTECTED]: Project xml-fop-maintenance (in module xml-fop-maintenance) failed

[Sam Ruby]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project xml-fop-maintenance has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 12 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- xml-fop-maintenance :  XSL-FO (Formatting Objects) processor (Maintenance 
branch)


Full details are available at:

http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [fop.jar] identifier set to project name
 -INFO- Made directory 
[/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes]
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/gump_work/build_xml-fop-maintenance_xml-fop-maintenance.html
Work Name: build_xml-fop-maintenance_xml-fop-maintenance (Type: Build)
Work ended in a state of : Failed
Elapsed: 2 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only gump 
[Working Directory: /usr/local/gump/public/workspace/xml-fop-maintenance]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-19092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-19092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-19092005.jar
-
Buildfile: build.xml

init-avail:

init-filters-jdk14:
 [echo] JDK 1.4 present.
 [copy] Copying 1 file to 
/x1/gump/public/workspace/xml-fop-maintenance/build/src/codegen

init-filters-jdk13:

init:
 [echo] --- Fop 0.20.5 [1999-2003] 

prepare:
 [echo] Preparing the build directories
[mkdir] Created dir: 
/x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/fo/properties
[mkdir] Created dir: 
/x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/render/pdf/fonts
[mkdir] Created dir: 
/x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apa

Re: Space-resolution doesn't work

[Manuel Mall]

On Tue, 13 Sep 2005 04:25 pm, Jeremias Maerki wrote:
> FYI, I'm going to try reimplementing the whole space-resolution part
> on the block-progression-dimension (to start with) using the inputs
> from both Luca and Simon and based on my findings I've documented in
> the Wiki:
> http://wiki.apache.org/xmlgraphics-fop/SpaceResolution
>
> I've started by creating a base class "UnresolvedElement" (holding a
> Position instance) from which SpaceElement (holding SpaceProperty)
> and BorderOrPaddingElement (holding a CondLengthProperty) are
> derived. We'll see how well this turns out.
>
Looking forward to seeing the result of this as the same/similar problem 
needs to be solved for the inline-progression-direction.

Side note: The LineLayoutManager currently doesn't add the the 
half-leading trait as space-before/space-after as required by the spec 
(4.5). This means you won't consider these as part of your space 
resolution in bpd although they probably should?

OTOH, I would prefer no big changes to the whole line/inline layout 
stuff until my batch of changes accumulated here are in Subversion.


> Jeremias Maerki

Manuel

Re: [Xmlgraphics-fop Wiki] Update of "ReleasePlanFirstPR" by JeremiasMaerki

[Jeremias Maerki]

Thanks for the hint. Looks like I overlooked that problem. I'll go after
it as soon as you get your account (I'm really annoyed about the delay
by now) and got a chance to fix the PDFRenderer.

On 19.09.2005 11:29:06 Manuel Mall wrote:
> On Mon, 19 Sep 2005 05:22 pm, Apache Wiki wrote:
> 
> > +  * '''(done)''' The PDF and PS renderers should have a good quality
> > and produce pretty much identical output
> 
> When I did the work on leaders recently I noticed that the PSRenderer 
> doesn't implement the fo:leader renderer (I haven't fixed that as I 
> don't know much about PS) and the PDF implementation was slightly 
> incorrect (I fixed that but still can't commit ...).
> 
> Manuel



Jeremias Maerki

Re: [Xmlgraphics-fop Wiki] Update of "ReleasePlanFirstPR" by JeremiasMaerki

[Manuel Mall]

On Mon, 19 Sep 2005 05:22 pm, Apache Wiki wrote:

> +  * '''(done)''' The PDF and PS renderers should have a good quality
> and produce pretty much identical output

When I did the work on leaders recently I noticed that the PSRenderer 
doesn't implement the fo:leader renderer (I haven't fixed that as I 
don't know much about PS) and the PDF implementation was slightly 
incorrect (I fixed that but still can't commit ...).

Manuel

Re: Characters and area traits

[Manuel Mall]

On Mon, 19 Sep 2005 04:23 pm, Jeremias Maerki wrote:
> On 18.09.2005 13:10:34 Manuel Mall wrote:
> > On Fri, 16 Sep 2005 11:41 pm, Jeremias Maerki wrote:

>
> > So, for the time being, I have now fop internally standardised the
> > meaning of the fop specific "offset" attribute in the fop area tree
> > as meaning the distance between the before edges of the parent area
> > and the area to be rendered. I have also introduced a new attribute
> > called "baselineOffset" which gives the point on the start-edge
> > (distance from the before-edge) for the actual alignment line for
> > all glyphs in that inline area, i.e. the alignment point in bpd for
> > all the glyphs in that area will be on that line.
>
> Sounds reasonable. Did you find anything in the spec what exactly the
> suggested set of trait is?
>
I believe the relevant sections of the spec are 4.2.6, 4.6 and 7.13 
which take quite a bit to digest.  However, in the end it seems to boil 
down to the spec suggesting to carry the actual-baseline-table, 
dominant-baseline-identifier, alignment-baseline, alignment-point and 
baseline-shift as traits and let the renderers do some of the placement 
calculations. May be "alignment-point" is the closest to what I have 
called baselineOffset.


> Jeremias Maerki

Manuel

Re: svn commit: r289865 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/ fo/flow/ fo/properties/ layoutmgr/table/

[Jeremias Maerki]

Looks ok on first glance, though I've got a request: Would you please
consider installing a checkstyle plug-in into your IDE and configuring
the rules file for FOP? Thanks!

On 18.09.2005 02:10:48 Andreas L Delmelle wrote:
> On Sep 18, 2005, at 01:59, [EMAIL PROTECTED] wrote:
> 
> > Author: adelmelle
> > Date: Sat Sep 17 16:59:25 2005
> > New Revision: 289865
> >
> > URL: http://svn.apache.org/viewcvs?rev=289865&view=rev
> > Log:
> > Implementation for initial values of the column-number property
> 
> Ok, after a whole lot of talking, here it is then --finally...
> 
> Since this is my first substantial contribution, if there's anything 
> the Java geeks around here have to add or if I made any serious errors, 
> please don't shoot me :-)
> 
> Passed all regression tests, so nothing should break for the common 
> cases. If anyone comes up with cases that break this approach, just add 
> them to the FOTree testsuite. I've added a few rather exceptional cases 
> myself to make sure it was as generic as possible.
> Don't hesitate to ask further info if something is not quite clear WRT 
> the logic/theory.
> 
> Thanks to everyone --especially Jeremias-- for your patience, and for 
> the FOTree testsuite, without which I'd probably still be analyzing 
> numerous log.debug() messages... :-)
> 
> Hope it meets with your approval.
> 
> Cheers,
> 
> Andreas



Jeremias Maerki

RE: txt-rendering

[Sergey Simonchik]

-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED] 
Sent: Saturday, September 17, 2005 3:29 PM
To: fop-dev@xmlgraphics.apache.org
Cc: Danila Ermakov
Subject: Re: txt-rendering

> Hi Sergey, 
> unfortunately, you didn't notice the TXTRenderer that was in 0.20.5 [1]. 
> The text renderer seems to work fine for many people who work with FOP 
> 0.20.5. IMO it should be simple to port that renderer to FOP Trunk. The 
> TXTRenderer currently found in FOP Trunk is only an empty shell which 
> needs to be filled. I'd investigate that before doing any serious coding 
> on a completely new TextRenderer. Please have a look at TXTRenderer and 
> get back to us so we can sort out any details. The old TXTRenderer is 
> capable of creating good output without any special handling in the area 
> tree. You will also find discussion snippets around the TXTRenderer in 
> the mailing list archives which should give you an idea about its design. 
> BTW, I'm glad that you're going to reintroduce the TextRenderer.

Oh, it was indiscreet for my part to offer something without previous code
preview.
So, now I'll yield to your advice.
Thanks.

Sergey Simonchik.

RE: txt-rendering

[Sergey Simonchik]

-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED] 
Sent: Saturday, September 17, 2005 3:29 PM
To: fop-dev@xmlgraphics.apache.org
Cc: Danila Ermakov
Subject: Re: txt-rendering

> AFAIK, there's still a open issue with a patch [2] where I asked you to 
> send in an ICLA so I can commit the patch. So far, I haven't seen an 
> ICLA being recorded with your name. 

Meanwhile, our lawer disallow ICLA using, but it's possible, soon we'll get
modified ICLA.

Re: FOray fonts / axslFonts / baselines / FOP fonts

[Jeremias Maerki]

On 19.09.2005 10:33:16 Vincent Hennebert wrote:
> BTW, I believe the required renderers for the pre-release are the following:
> * pdf
> * ps
> * awt
> * rtf
> Have I forgotten one?

No.

Jeremias Maerki

Re: FOray fonts / axslFonts / baselines / FOP fonts

[Vincent Hennebert]

Hi Manuel,

Thanks for your input. I'm forwarding your request to the aXSL list. I agree 
with you that this kind of information is relevant to the font used, and that 
this should be provided by the font system. I guess that this  should be 
available in the OpenType format; for the other formats this will have to be 
computed or defined in the config file.


For now I'm still hoping to have FOrayFont integrated in the pre-release; I'm 
currently working with Victor to meet the needs of the Postscript renderer. If I 
haven't succeeded in one week I'll change my strategy: learn pdf, postscript, 
font formats and work more on API improvements like this one.


BTW, I believe the required renderers for the pre-release are the following:
* pdf
* ps
* awt
* rtf
Have I forgotten one?

Vincent


Manuel Mall a écrit :

Vincent,

this is more "just for the record". To do all this alignment stuff 
(XSL-FO spec 7.13) correctly we need various baseline information 
(tables). And it all starts with the font, i.e. for each font we need 
to know its default baseline and where all the other baselines are for 
that font (actually on a per glyph basis or at least on a per script 
basis). None of this information is currently exposed in the font API, 
neither the current FOP Font nor AFAICT in axslFont. There is certainly 
no point in modifying the current FOP Font object as it will be 
superseded by your work in due course. So I hope axslFont and its first 
implementation FOray Font will take a lead here :-). This is further 
complicated by most fonts not having this sort of information embedded 
in their font files. So there must be other means of deriving it as 
well (algorithmic?, external font config files?, ...).


Manuel

Re: Characters and area traits

[Jeremias Maerki]

On 18.09.2005 13:10:34 Manuel Mall wrote:
> On Fri, 16 Sep 2005 11:41 pm, Jeremias Maerki wrote:
> > I'm not a specialist on typography, yet, but the character wrapping
> > (your option a) sounds definitely like a hack. I've started reading
> > the parts in the spec about baselines and that's not a casual read.
> > But I think that at one point we need to handle baselines and all
> > these little details. I'm not a big help here but I think it would be
> > worth reading through the following sections in the spec: 4.2.6,
> > 7.8.1, 7.13. Somewhere in there all the necessary traits and their
> > handling should be hidden. They should at least get you some hints
> > how to handle the problem at hand.
> 
> Jeremias, seems to me we are talking about two different things here.

I don't think so. I only tend to look at how to get a problem right for
good as opposed to a quick change to make things work. I see that this
was not fully appropriate here. Sorry for that.

> My 
> initial problem simply was that I needed more data in the area tree to 
> correctly draw border/padding/background for various inline fos 
> (leader, page-number, page-number-citation, character). The other, only 
> vaguely related matter, is the correct handling of all the area 
> alignment properties in layout. IMO it is only vaguely related, and 
> this may be contentious, because for rendering we only need to know 
> where to place the glyph, i.e. the x/y coordinates of its alignment 
> point. All the relative and baseline alignment stuff should have been 
> previously resolved by layout. If you go along with that argument it 
> would mean the fop area tree as exposed to the renderers will not carry 
> baseline tables or related data. Not sure if this causes an issue with 
> the plans to expose the area tree as an official external interface.

No, I don't think it would. As I said, I don't know too much about the
details involved here so I can't tell what the right approach would be.
People who would mess around with the area will need to know what
they're doing anyway. No problem if it might get a little complicated on
this level.

> So, for the time being, I have now fop internally standardised the 
> meaning of the fop specific "offset" attribute in the fop area tree as 
> meaning the distance between the before edges of the parent area and 
> the area to be rendered. I have also introduced a new attribute called 
> "baselineOffset" which gives the point on the start-edge (distance from 
> the before-edge) for the actual alignment line for all glyphs in that 
> inline area, i.e. the alignment point in bpd for all the glyphs in that 
> area will be on that line.

Sounds reasonable. Did you find anything in the spec what exactly the
suggested set of trait is?

> This seems to have worked well so far and introduced quite a bit of 
> consistency in the handling of offsets and basic vertical alignment for 
> all our inline areas. There is an assumption behind this that all 
> glyphs in an inline area have the same nominal alignment line. This is 
> certainly true in the moment and I am not aware of a font where 
> different glyphs have different nominal alignment lines (but there 
> probably is for fonts mixing Western and non Western glyphs). And even 
> if so, our font interface (nor FOray's i/f I assume) does not expose 
> this sort of detail. 
> 
> If the two attributes (offset and baselineOffset) are enough in the fop 
> area tree to cover vertical writing modes I am not sure about - this is 
> "for further study".
>
> Hope this makes sense

Sounds completely reasonable to me.
> 
> >
> > On 16.09.2005 15:50:50 Manuel Mall wrote:
> > > Still waiting for some feedback here from others. I am reluctant to
> > > change the interface to the renderers without other committers
> > > agreeing because such a change affects every renderer out there. On
> > > the other hand it feels a bit like a kludge to treat/represent
> > >  as x.
> > > There are also some subtleties in the handling of some properties
> > > which are interpreted differently when specified on a fo:character
> > > to a fo:inline.
> > >
> > > Manuel
> > >
> > > On Fri, 16 Sep 2005 03:31 pm, Manuel Mall wrote:
> > > > On Fri, 16 Sep 2005 02:58 pm, Finn Bock wrote:
> > > > > [Manuel]
> > > > >
> > > > > > I am currently looking at adding the missing background and
> > > > > > border/padding support to fo:character and have run into a
> > > > > > co-ordinate system issue. In fop text areas and character
> > > > > > areas are positioned in the bpd direction using the "offset"
> > > > > > attribute which refers to the character baseline position.
> > > > > > However, border/padding and backgrounds are positioned
> > > > > > everywhere relative to the top left (or should I say
> > > > > > before/start) corner of the area rectangle. However, in the
> > > > > > renderer based on the area traits (for a text or character
> > > > > > area) I cannot easily determine the before edge position 

Re: [EMAIL PROTECTED]: Project xml-fop-maintenance (in module xml-fop-maintenance) failed

[Jeremias Maerki]

(cc'ing dev@ant.apache.org)

On 16.09.2005 21:23:39 Stefan Bodewig wrote:
> On Fri, 16 Sep 2005, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> 
> > No idea what this is suddenly about. Looks like a permission
> > problem?
> 
> No, the file simply doesn't exist.  The properties directory is empty,
> at least after the build has finished.
> 
> Stefan


For the Ant people, links to related info:
http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200509.mbox/[EMAIL 
PROTECTED]

The build.xml in question:
http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/branches/fop-0_20_2-maintain/build.xml?view=markup
(the problem happens in the codegen target. Note: Constants.java is
supposed to be generated by the style task, it can't be there to be
deleted.)

Thanks for your reply, Stefan. I think this is due to a change in Ant.
I've downloaded SVN Trunk and used that and it reproduces the problem.
Here's the "-d" output:

[dependset] 2 nonexistent targets
[dependset] Deleting all target files.
[dependset] Deleting 
C:\Dev\FOP\branch\svn\build\src\org\apache\fop\fo\properties\Constants.java

BUILD FAILED
C:\Dev\FOP\branch\svn\build.xml:412: Unable to delete file 
C:\Dev\FOP\branch\svn\build\src\org\apache\fop\fo\properties\Constants.java
at org.apache.tools.ant.taskdefs.Delete.execute(Delete.java:541)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:104)
at org.apache.tools.ant.Task.perform(Task.java:365)
at org.apache.tools.ant.taskdefs.DependSet.execute(DependSet.java:185)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:104)
at org.apache.tools.ant.Task.perform(Task.java:365)
at org.apache.tools.ant.Target.execute(Target.java:356)
at org.apache.tools.ant.Target.performTasks(Target.java:384)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1236)
at org.apache.tools.ant.Project.executeTarget(Project.java:1205)
at 
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
at org.apache.tools.ant.Project.executeTargets(Project.java:1088)
at org.apache.tools.ant.Main.runBuild(Main.java:676)
at org.apache.tools.ant.Main.startAnt(Main.java:195)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:276)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:96)

Looks like the dependset has a problem due to a change in Delete:
http://svn.apache.org/viewcvs.cgi/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Delete.java?rev=280944&r1=278200&r2=280944&diff_format=h

This change happened 4 days ago which seems to fit with the first
occurence of the problem.



Jeremias Maerki