Area Tree XML format as reloadable intermediate format
It's time bring this on the table. I've started writing down a proposal for an intermediate format for FOP. All the details are on the wiki page: http://wiki.apache.org/xmlgraphics-fop/AreaTreeIntermediateXml Thoughts welcome. Jeremias Maerki
Re: Area Tree XML format as reloadable intermediate format
Jeremias Maerki wrote: It's time bring this on the table. I've started writing down a proposal for an intermediate format for FOP. All the details are on the wiki page: http://wiki.apache.org/xmlgraphics-fop/AreaTreeIntermediateXml Thoughts welcome. Looks good Jeremias. All I found wrong was a couple of typos - now fixed. Chris
Re: svn commit: r279551 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/layoutmgr/inline/TextLayoutManager.java test/layoutengine/testcases/wrapper_text-transform_1.xmlLuca,
Luca,
can you have a look at this please - this is my code after integrating
your patch to add the knuth elements for line end / start
border/padding for the common justify=start or end case. What I am
getting now is a space at the beginning of each line break!:
if (lineStartBAP != 0 || lineEndBAP != 0) {
sequence.add
(new KnuthGlue(lineEndBAP, 0, 0,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthPenalty(0, 0, false,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthGlue(wordSpaceIPD.opt - (lineStartBAP + lineEndBAP),
wordSpaceIPD.max - wordSpaceIPD.opt,
wordSpaceIPD.opt - wordSpaceIPD.min,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthInlineBox(0, 0, 0, 0,
notifyPos(new LeafPosition(this, -1)), true));
sequence.add
(new KnuthPenalty(0, KnuthElement.INFINITE, false,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthGlue(lineStartBAP, 0, 0,
new LeafPosition(this, vecAreaInfo.size() - 1), false));
} else {
...
}
Manuel
On Thu, 8 Sep 2005 06:48 pm, you wrote:
Author: lfurini
Date: Thu Sep 8 03:47:57 2005
New Revision: 279551
URL: http://svn.apache.org/viewcvs?rev=279551view=rev
Log:
Removing trailing spaces at the end of text areas: this is done by
storing the Position, whose value points to the AreaInfo created for
a space, inside the glue element that is ignored if there is a line
break.
This fixes item 2) in bug 36533.
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/TextLa
youtManager.java
xmlgraphics/fop/trunk/test/layoutengine/testcases/wrapper_text-transf
orm_1.xml
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/TextLa
youtManager.java URL:
http://svn.apache.org/viewcvs/xmlgraphics/fop/trunk/src/java/org/apac
he/fop/layoutmgr/inline/TextLayoutManager.java?rev=279551r1=279550r2
=279551view=diff
=
= ---
xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/TextLa
youtManager.java (original) +++
xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/TextLa
youtManager.java Thu Sep 8 03:47:57 2005 @@ -458,14 +458,14 @@
wordSpaceIPD, false));
sequence.add
(new KnuthGlue(0, 3 *
LineLayoutManager.DEFAULT_SPACE_WIDTH, 0, -
new LeafPosition(this, vecAreaInfo.size() - 1), false));
+ new LeafPosition(this, -1),
false)); sequence.add
(new KnuthPenalty(0, 0, false,
new LeafPosition(this,
-1), true)); sequence.add
(new KnuthGlue(wordSpaceIPD.opt,
- 6 *
LineLayoutManager.DEFAULT_SPACE_WIDTH, 0, -
new LeafPosition(this, -1), true)); +
new LeafPosition(this, vecAreaInfo.size() - 1),
true)); sequence.add
(new KnuthInlineBox(0, 0, 0, 0,
new LeafPosition(this, -1),
true)); @@ -486,14 +486,14 @@
wordSpaceIPD, false));
sequence.add
(new KnuthGlue(0, 3 * wordSpaceIPD.opt, 0,
- new LeafPosition(this,
vecAreaInfo.size() - 1), false)); +
new LeafPosition(this, -1), false)); sequence.add
(new KnuthPenalty(0, 0, false,
new LeafPosition(this,
-1), true)); sequence.add
(new KnuthGlue(wordSpaceIPD.opt,
- 3 * wordSpaceIPD.opt, 0,
- new LeafPosition(this, -1),
true)); + new
LeafPosition(this, vecAreaInfo.size() - 1), true)); iNextStart ++;
break;
Modified:
xmlgraphics/fop/trunk/test/layoutengine/testcases/wrapper_text-transf
orm_1.xml URL:
http://svn.apache.org/viewcvs/xmlgraphics/fop/trunk/test/layoutengine
/testcases/wrapper_text-transform_1.xml?rev=279551r1=279550r2=279551
view=diff
=
= ---
xmlgraphics/fop/trunk/test/layoutengine/testcases/wrapper_text-transf
orm_1.xml (original) +++
xmlgraphics/fop/trunk/test/layoutengine/testcases/wrapper_text-transf
orm_1.xml Thu Sep 8 03:47:57 2005 @@ -41,7 +41,8 @@
checks
eval expected=none: This tExT is left as-IS.
xpath=//flow/block[1]/ eval expected=capitalize: This
Re: Area Tree XML format as reloadable intermediate format
On 08.09.2005 13:14:57 Finn Bock wrote: [Jeremias] It's time bring this on the table. I've started writing down a proposal for an intermediate format for FOP. All the details are on the wiki page: http://wiki.apache.org/xmlgraphics-fop/AreaTreeIntermediateXml Thoughts welcome. Looks fine, but a few things is unclear to me. - What is SAX-based serialization? Generation of XML by generating SAX events. Like in ExampleObj2XML. - The wrapper around a PageViewport is a functional extra that the pure area tree doesn't need by itself, right? Yes. The transformations could be put on the PageViewport itself but I find a wrapper the cleaner approach. - What and where do you mean no direct painting routines? It means that you won't have any XML elements in the area tree namespace that you can use to paint graphical shapes. I'll update the Wiki to clarify these points. Jeremias Maerki
[VOTE:RESULTS] Manuel Mall as new FOP committer
Time to sum up: 9 +1s and no other votes. The vote passes. And the winner is: Manuel Mall! Welcome!!! Manuel, you're ICLA is already on file which will speed up the next step considerably. What I need from you now is to give me your choice for unix user ID and to verify that the forwarding email address is correct: Preferred userid: ... [please provide acceptable alternatives] Full name:Manuel Mall Forwarding email address: [EMAIL PROTECTED] Thanks. While your user account is set up, please familiarize yourself with a few additional things: http://www.apache.org/dev/committers.html http://www.apache.org/dev/new-committers-guide.html If you have any questions, we're all happy to help. On 05.09.2005 10:29:36 Jeremias Maerki wrote: Manuel Mall has been investing a tremendous amount of time and effort into making FOP better lately. The results were just great. It's been a pleasure to apply his patches, even though it ate up a lot of my time. ;-) Manuel has been around since at least late 2002, even submitted a patch back then. He shows a good understanding of how things work in our project and is quick to learn in other areas. He doesn't fear diving into the code of the layout engine. That's exactly the sort of people we need in the project team. That's why I'd like to nominate him for committership in Apache FOP. Jeremias Maerki Jeremias Maerki
Re: svn commit: r279551 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/layoutmgr/inline/TextLayoutManager.java test/layoutengine/testcases/wrapper_text-transform_1.xml
Manuel Mall wrote:
this is my code after integrating your patch to add the knuth elements
for line end / start border/padding for the common justify=start or
end case. What I am getting now is a space at the beginning of each
line break!:
if (lineStartBAP != 0 || lineEndBAP != 0) {
sequence.add
(new KnuthGlue(lineEndBAP, 0, 0,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthPenalty(0, 0, false,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthGlue(wordSpaceIPD.opt - (lineStartBAP + lineEndBAP),
wordSpaceIPD.max - wordSpaceIPD.opt,
wordSpaceIPD.opt - wordSpaceIPD.min,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthInlineBox(0, 0, 0, 0,
notifyPos(new LeafPosition(this, -1)), true));
sequence.add
(new KnuthPenalty(0, KnuthElement.INFINITE, false,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthGlue(lineStartBAP, 0, 0,
new LeafPosition(this, vecAreaInfo.size() - 1), false));
} else {
...
}
The LeafPosition(this, vecAreaInfo.size() - 1) (the Position containing
the index of the AreaInfo objects storing information about the space)
should be the one that is discared if a line break happens: i.e. the
second one instead of the third.
With this change, this sequence should be correct for a space in justified
text.
With left- / right-aligned text the overall stretch and shrink of the sequence
should not be changed, so the sequence should be:
sequence.add
(new KnuthGlue(lineEndBAP, 3 * LineLayoutManager.DEFAULT_SPACE_WIDTH,
0,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthPenalty(0, 0, false,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthGlue(wordSpaceIPD.opt - (lineStartBAP + lineEndBAP),
- 3 * LineLayoutManager.DEFAULT_SPACE_WIDTH,
0,
new LeafPosition(***, false));
sequence.add
(new KnuthInlineBox(0, 0, 0, 0,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthPenalty(0, KnuthElement.INFINITE, false,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthGlue(lineStartBAP, 0, 0,
new LeafPosition(this, -1), true));
With centered text the combined sequence should be:
sequence.add
(new KnuthGlue(lineEndBAP, 3 * LineLayoutManager.DEFAULT_SPACE_WIDTH,
0,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthPenalty(0, 0, false,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthGlue(wordSpaceIPD.opt - (lineStartBAP + lineEndBAP),
- 6 * LineLayoutManager.DEFAULT_SPACE_WIDTH,
0,
new LeafPosition(***, false));
sequence.add
(new KnuthInlineBox(0, 0, 0, 0,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthPenalty(0, KnuthElement.INFINITE, false,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthGlue(lineStartBAP,
3 * LineLayoutManager.DEFAULT_SPACE_WIDTH, 0,
new LeafPosition(this, -1), true));
The Position marked *** should be a LeafPosition(this, vecAreaInfo.size()
- 1); as it is in the element more connected with the real space (if
this element is ignored, the space is too) maybe it is this one that must
be notified.
[from your other message]
I am also unsure what the correct knuth element sequences are in the
case of the forced line break and for hyphenation.
A forced line break should not be very different from the real end of
the inline, so I think it should be enough to add a box/glue element
(according to the conditionality [1]) whose width is lineEndBAP before the
penalty. In this case, the next returned sequence should start with the
elements for the initial border and padding.
As per the hyphenation, I think we could use the same sequence created for
a space (according to the alignment), but with the first penalty (the
second element) having the width of the -.
While answering your message I noticed that there are some inconstitencies
in the TextLM: for example, the LineLM.DEFAULT_SPACE_WIDTH is not used
everywhere it should ... I'll try and find some time to fix them.
I hope I did not answer you too late, otherwise ... tomorrow is another
day :-)
The time difference between Italy and Australia can hinder communication!
Regards
Luca
[1] in effects, as a preserved
Re: svn commit: r279551 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/layoutmgr/inline/TextLayoutManager.java test/layoutengine/testcases/wrapper_text-transform_1.xml
On Thu, 8 Sep 2005 09:55 pm, Luca Furini wrote: Manuel Mall wrote: snip / I hope I did not answer you too late, otherwise ... tomorrow is another day :-) Of course its not too late and yes tomorrow is another day :-). Your suggestions worked first time - great stuff. Still need to look at the hyphenation stuff though. The time difference between Italy and Australia can hinder communication! Look at it as an opportunity - you can think about any answers to my questions while I am sleeping = no pressure - no need to rush. Regards Luca Thanks Manuel
RE: font system: millipoints or floats?
Jeremias Maerki wrote: I don't see a big problem if you switch to points and double for the font library. These values can always be converted back to millipoints as needed. It's a relatively isolated area. After all, we already convert from and to millipoints back and forth. Doing the same for the font library is not a big deal I think. Unless I'm missing something, of course. The only issue I can think of would be the cumulative effect of the performance hit, and I'm not smart enough to predict whether that is significant or not (there are some operations that would be saved internally that might help pay for the expense of a client application converting). I think I will do some experimentation before I go any further with that. Some other day. Thanks for the feedback. Victor Mote
Centering Table
Hi all! I am having a real brain drain or brain poop today. Could you please advise on how to get a table centered on a page? Thanks in advance for your help! ~S.E. Here is a snippet of the style sheet: fo:block font-size=5mm text-align=center space-after=2mm xsl:for-each select=RegInfo xsl:apply-templates select=table/ /xsl:for-each!--RegInfo-- /fo:block xsl:template match=table fo:block space-before.optimum=7pt space-after.optimum=10pt xsl:apply-templates select=tgroup/ /fo:block /xsl:template xsl:template match=tgroup fo:table xsl:call-template name=set_columns xsl:with-param name=count select=@cols/ xsl:with-param name=columns select=@cols/ /xsl:call-template fo:table-header fo:table-row line-height=12pt font-size=11pt font-weight=bold xsl:apply-templates select=colspec/ /fo:table-row /fo:table-header xsl:apply-templates select=thead/ xsl:apply-templates select=tbody/ /fo:table /xsl:template xsl:template match=thead fo:table-body xsl:apply-templates select=row/ /fo:table-body /xsl:template xsl:template match=tbody fo:table-body xsl:apply-templates select=row/ /fo:table-body /xsl:template xsl:template match=row fo:table-row line-height=11pt font-size=12pt xsl:apply-templates select=entry/ /fo:table-row /xsl:template xsl:template match=entry fo:table-cell border-width=1pt padding-start=5pt padding-top=3pt padding-bottom=3pt display-align=after border-top-style=solid border-bottom-style=solid border-right-style=solid border-left-style=solid text-align=center fo:block xsl:apply-templates / !--xsl:value-of select=text()/-- /fo:block /fo:table-cell /xsl:template __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Centering Table
siarom egrub wrote: Could you please advise on how to get a table centered on a page? This is a FAQ, either http://xmlgraphics.apache.org/fop/faq.html#fo-center or http://xmlgraphics.apache.org/fop/faq.html#fo-center-table-horizon J.Pietschmann
Re: Logging for FOrayFont
Victor Mote wrote:
OK. Still I miss your point.
Well, I think loggin is much overrated and it is really overdone
in FOP.
Fatal errors are fatal errors. Just throw an exception and let
someone else figure out what to do. Some examples from the FOP
code where logging doesn't help:
public int getValue() {
log.error(getValue() called on + enumProperty + length);
return 0;
}
if ((bfSet MAXSET) != 0) {
// Warning: minmax, resetting max to min
log.error(forcing max to min in LengthRange);
}
maximum = minimum;
public Source resolve(String href, String base)
throws javax.xml.transform.TransformerException {
try {
// the above failed, we give it another go in case
// the href contains only a path then file: is assumed
absoluteURL = new URL(file: + href);
} catch (MalformedURLException mfue) {
log.error(Error with URL ' + href + ': +
mue.getMessage(), mue);
return null;
}
Especially the latter gets a Duh!, because of:
public Source resolveURI(String uri) {
...
if (uriResolver != null) {
try {
source = uriResolver.resolve(uri, getBaseURL());
} catch (TransformerException te) {
log.error(Attempt to resolve URI ' + uri + ' failed: , te);
}
}
if (source == null) {
// URI Resolver not configured or returned null, use default
// resolver
try {
source = foURIResolver.resolve(uri, getBaseURL());
} catch (TransformerException te) {
log.error(Attempt to resolve URI ' + uri + ' failed: , te);
}
}
FOP needs a facility to notify a user about warnings, recoverable
errors and progress reports. There may be a separate facility to
provide debug for developers and yet another to provide out-of-band
results like ressource ussage statistics and number of generated pages.
I don't think that generously sprinkling log.stuff() statements all
over the place is the best solution to the problems above, even though
this seems to fit.
J.Pietschmann
More style issues
Hi devs,
while examining the Checkstyle and JavaDoc complaints I
got a few more questions about the FOP style:
1. There is still quite a bit of hungarian notation here and
there. Hungarian notation generally sucks unless it is
consistently applied. Furthermore, it is systems hungarian
(see http://www.joelonsoftware.com/articles/Wrong.html),
which unconditionally sucks.
And yes, we do already have an int bFooFlag.
I'd like to exterminate this.
2. There are two different styles for constructors and setters
in use:
Constructor(int foo) {
this.foo=foo
}
and
Constructor(int f) {
foo=f
}
We should standardize on one form. I'd like the first because
the second may have the undesirable effect of using unintuitive
abbreviations or alternative names for the parameter.
I told Checkstyle laready to accept the first form (there are
*lots* of warnings about it). Unfortunately, Checkstyle can't yet
enforce it.
3. We have too much weird abbreviations everywhere. In particular,
usage of abbreviations is wildly inconsistent. I'd like to
remind everyone that using proper words to compose identifiers
has advantages. With the autocompletion features of modern IDEs,
long identifiers shouldn't impair typing too much.
I'll probably expand randomly choosen names in the future, which
may include class names. Tell me now if you don't like this.
Regards
J.Pietschmann
Re: More style issues
Joerg,
thank you for looking into this - fixing typos and style issues in other
peoples code is really quite a gruelling task.
And trying to get agreement on style issues in a community of developers
is virtually impossible, isn't it :-), as we all have our own likes and
dislikes.
On Fri, 9 Sep 2005 07:55 am, J.Pietschmann wrote:
Hi devs,
while examining the Checkstyle and JavaDoc complaints I
got a few more questions about the FOP style:
1. There is still quite a bit of hungarian notation here and
there. Hungarian notation generally sucks unless it is
consistently applied. Furthermore, it is systems hungarian
(see http://www.joelonsoftware.com/articles/Wrong.html),
which unconditionally sucks.
And yes, we do already have an int bFooFlag.
I'd like to exterminate this.
+1 I am with you here - allthough I am guilty as well: If I find a class
written in hungarian style and I have to make a modification I will
sick with the style of the original author. What I dislike most is
mixing styles as this make code IMO very difficult to read.
2. There are two different styles for constructors and setters
in use:
Constructor(int foo) {
this.foo=foo
}
and
Constructor(int f) {
foo=f
}
We should standardize on one form. I'd like the first because
the second may have the undesirable effect of using unintuitive
abbreviations or alternative names for the parameter.
I told Checkstyle laready to accept the first form (there are
*lots* of warnings about it). Unfortunately, Checkstyle can't yet
enforce it.
Doesn't worry me too much although I prefer the style you prefer as
well.
3. We have too much weird abbreviations everywhere. In particular,
usage of abbreviations is wildly inconsistent. I'd like to
remind everyone that using proper words to compose identifiers
has advantages. With the autocompletion features of modern IDEs,
long identifiers shouldn't impair typing too much.
I'll probably expand randomly choosen names in the future, which
may include class names. Tell me now if you don't like this.
That's a difficult one - I don't think there is a right or wrong here.
And yes consistency would be great (e.g. all layout manager classes
should be called ...LayoutManager and not some ...LM). I agree that
this is not really a typing issue but it is arguable at what length an
identifier actually gets in the way of readability, e.g. is
'lineStartBorderAndPaddingWidth' preferable to 'lineStartBAP' if that
variable is used a lot in expressions which are then split over multi
lines everywhere this variable is used?
What about a WIKI page listing commonly used abbreviations found in the
code base?
So +1 for consistent class names and +1 for consistent and considered
use of abbreviations but please don't ban them altogether.
Regards
J.Pietschmann
Thanks again for taking this on
Manuel
[EMAIL PROTECTED]: Project xml-fop (in module xml-fop) failed
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 has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - xml-fop : XSL-FO (Formatting Objects) processor Full details are available at: http://vmgump.apache.org/gump/public/xml-fop/xml-fop/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/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/xml-fop/gump_work/build_xml-fop_xml-fop.html Work Name: build_xml-fop_xml-fop (Type: Build) Work ended in a state of : Failed Elapsed: 34 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 package [Working Directory: /usr/local/gump/public/workspace/xml-fop] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop/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-08092005/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-08092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-08092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-08092005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-08092005.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-08092005.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar - [style] Processing /x1/gump/public/workspace/xml-fop/src/codegen/HelveticaOblique.xml to /x1/gump/public/workspace/xml-fop/build/gensrc/org/apache/fop/fonts/base14/HelveticaOblique.java [style] Loading stylesheet /x1/gump/public/workspace/xml-fop/src/codegen/font-file.xsl [style] Warning: the task name style is deprecated. Use xslt instead. [style] Processing /x1/gump/public/workspace/xml-fop/src/codegen/HelveticaBoldOblique.xml to /x1/gump/public/workspace/xml-fop/build/gensrc/org/apache/fop/fonts/base14/HelveticaBoldOblique.java [style] Loading stylesheet
[EMAIL PROTECTED]: Project xml-fop (in module xml-fop) failed
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 has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - xml-fop : XSL-FO (Formatting Objects) processor Full details are available at: http://vmgump.apache.org/gump/public/xml-fop/xml-fop/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/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/xml-fop/gump_work/build_xml-fop_xml-fop.html Work Name: build_xml-fop_xml-fop (Type: Build) Work ended in a state of : Failed Elapsed: 34 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 package [Working Directory: /usr/local/gump/public/workspace/xml-fop] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop/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-08092005/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-08092005/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-08092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-08092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-08092005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-08092005.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-08092005.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar - [style] Processing /x1/gump/public/workspace/xml-fop/src/codegen/HelveticaOblique.xml to /x1/gump/public/workspace/xml-fop/build/gensrc/org/apache/fop/fonts/base14/HelveticaOblique.java [style] Loading stylesheet /x1/gump/public/workspace/xml-fop/src/codegen/font-file.xsl [style] Warning: the task name style is deprecated. Use xslt instead. [style] Processing /x1/gump/public/workspace/xml-fop/src/codegen/HelveticaBoldOblique.xml to /x1/gump/public/workspace/xml-fop/build/gensrc/org/apache/fop/fonts/base14/HelveticaBoldOblique.java [style] Loading stylesheet
