[GUMP@lsd]: xml-fop/xml-fop failed

[Sam Ruby]

Project: xml-fop
State: Failed
URL: http://lsd.student.utwente.nl/gump/xml-fop/xml-fop.html
- G U M P Y


Annotations:
 - Info - Made directory [/data/gump/xml-fop/build/classes]
 - Error - Failed with reason build failed


- G U M P Y
Work Name: build_xml-fop_xml-fop (Type: Build)
State: Failed
Elapsed: 0 hours, 0 minutes, 53 seconds
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/data/gump/xml-xerces2/java/build/xercesImpl.jar:/data/gump/xml-xerces2/java/build/xmlParserAPIs.jar:/data/gump/xml-xalan/java/build/xalan-unbundled.jar:/data/gump/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dbuild.clonevm=true 
-Dgump.merge=/data/gump/gump/work/merge.xml -Dbuild.sysclasspath=only gump 
[Working Directory: /data/gump/xml-fop]
-
[javac] symbol  : class IOUtil 
[javac] location: package io
[javac] import org.apache.commons.io.IOUtil;
[javac]  ^
[javac] 
/data/gump/xml-fop/src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/RtfExternalGraphic.java:61:
 cannot resolve symbol
[javac] symbol  : class IOUtil 
[javac] location: package io
[javac] import org.apache.commons.io.IOUtil;
[javac]  ^
[javac] /data/gump/xml-fop/src/java/org/apache/fop/fonts/type1/PFMFile.java:104: 
cannot resolve symbol
[javac] symbol  : variable IOUtil 
[javac] location: class org.apache.fop.fonts.type1.PFMFile
[javac] final byte[] buf = IOUtil.toByteArray(inStream);
[javac]^
[javac] 
/data/gump/xml-fop/src/java/org/apache/fop/fonts/truetype/FontFileReader.java:78: 
cannot resolve symbol
[javac] symbol  : variable IOUtil 
[javac] location: class org.apache.fop.fonts.truetype.FontFileReader
[javac] IOUtil.copy(in, bout);
[javac] ^
[javac] /data/gump/xml-fop/src/java/org/apache/fop/fonts/type1/PFBParser.java:264: 
cannot resolve symbol
[javac] symbol  : variable IOUtil 
[javac] location: class org.apache.fop.fonts.type1.PFBParser
[javac] calcLengths(pfb, IOUtil.toByteArray(bin));
[javac]  ^
[javac] /data/gump/xml-fop/src/java/org/apache/fop/pdf/PDFFactory.java:1183: 
cannot resolve symbol
[javac] symbol  : variable IOUtil 
[javac] location: class org.apache.fop.pdf.PDFFactory
[javac] byte[] file = IOUtil.toByteArray(in);
[javac]   ^
[javac] 
/data/gump/xml-fop/src/java/org/apache/fop/pdf/TempFileStreamCache.java:127: cannot 
resolve symbol
[javac] symbol  : variable IOUtil 
[javac] location: class org.apache.fop.pdf.TempFileStreamCache
[javac] final long bytesCopied = IOUtil.copy(input, out);
[javac]  ^
[javac] 
/data/gump/xml-fop/src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/RtfExternalGraphic.java:251:
 cannot resolve symbol
[javac] symbol  : variable IOUtil 
[javac] location: class org.apache.fop.render.rtf.rtflib.rtfdoc.RtfExternalGraphic
[javac] imagedata = IOUtil.toByteArray(url.openStream());
[javac] ^
[javac] 
/data/gump/xml-fop/src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/RtfExternalGraphic.java:253:
 cannot resolve symbol
[javac] symbol  : variable IOUtil 
[javac] location: class org.apache.fop.render.rtf.rtflib.rtfdoc.RtfExternalGraphic
[javac] IOUtil.shutdownStream(in);
[javac] ^
[javac] 13 errors

BUILD FAILED
/data/gump/xml-fop/build.xml:433: Compile failed; see the compiler error output for 
details.

Total time: 51 seconds
-

- G U M P Y
RSS: http://lsd.student.utwente.nl/gump/xml-fop/xml-fop.rss | Atom: 
http://lsd.student.utwente.nl/gump/xml-fop/xml-fop.atom

--
Gump http://jakarta.apache.org/gump
[lsd]

RE: Just a small question...

[Glen Mazza]

I really appreciate your enthusiasm and am very happy,
upon you finding something possibly of use to FOP on
another ML, of your bringing it back to the team.  We
should just be careful in this particular case,
however.

(BTW, you may also wish to look at Xalan, Batik, and
Cocoon for other ideas--*that* code we should be able
to use directly.)

Glen


--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
wrote:
> > -Original Message-
> > From: Andreas L. Delmelle
> [mailto:[EMAIL PROTECTED]
> >
> 
> > Again, I *do* appreciate your concerns for the
> project as a whole, but I
> > strongly doubt whether these should be a reason to
> remain blind to other
> > peoples' approaches.
> >
> >
> 
> To summarize: it's all about learning from *their*
> mistakes as well, not? :)
> 
> Cheers,
> 
> Andreas
> 


__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

RE: Just a small question...

[Glen Mazza]

[Pardon me, Peter, for more shooting from the hip...]

--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
wrote:
> > --nor should FOP developers even
> > be looking at its internals.  Matter of simple
> > integrity.
> 
> I think this is a bit over the top. Suppose that
> tomorrow, someone gets
> fired at RX or AH, and this ex-employee decides to
> share some ideas with us.
> Are we really going to tell him to take a hike??

Yes, indeed, of course.  I don't know the difference
between US and European laws here--but most companies
do not allow you to share competitive information
learned from one company to the next.

So in the case of a disgruntled employee fired at RX
or AH deciding to unload that company's source code
with us--we're to stay clear away from it--have
nothing to do with the code or with him.


> Just because of simple
> integrity? 

I appear to value it more than you.  In America, your
integrity/character defines you, it's the beginning of
your essence.  Integrity is also something that can't
be taught or fixed, a very important point in
business--I've learned that once I detect problems
with a person's integrity, best to minimize
interaction with that individual.


> (Suppose that, before we find out, he has
> already submitted a few
> patches that have been applied. Would we undo all of
> these patches, because
> of 'simple integrity'?)

Indeed.  Of course.  In a heartbeat.

> 
> It's --should I add: of course ?- not the intention
> to copy anything, just
> gather some ideas.
> 

Close enough to be the same thing--and it doesn't
reflect very well on you for you to try to make such a
distinction.  

Keep in mind, Andreas, Apache Geronimo is already
running into headaches, apparently including
complaints on "architectural similarities":

http://incubator.apache.org/projects/geronimo/20031031_jboss.pdf


> 
> My point exactly: how are we going to make sure of
> that if we're not even
> meant to look at their internals? (Who knows, maybe
> it's 0.47%
> already... 

If nobody has looked at their code, then it is
0%--anything else is coincidence.

> 
> Are you by any chance familiar with (--Picasso's, I
> think...):
> "Bad artists copy, good artists --steal."
> 

Thankfully, no.

Glen


__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

Re: Just a small question...

[Peter B. West]

Nikolai Grigoriev wrote:
I realize I was wrong when I answered to this forum - I could not 
expect my words to be interpreted this way. Please disregard my 
previous message; I also unsubscribe from the list, to make you feel 
sure I don't induce anyone into wrongdoing. 


RenderX (--still wondering which of the two is more true: either his
employers have no idea what he's doing, or he doesn't care whether 
they know... or he is his own employer trying to lure me into doing
something illegal --in which case he'll fail 


I _am_ in the position to decide myself how much technical information 
about RenderX XEP can be safely disclosed. But if you prefer to see 
any word that comes from RenderX as a fraud attempt, you're welcome.


- hey, come to think of it, does RX need money or what? =D )


And they have the money - earned by writing software, not by cheating.

Yours truly,
Nikolai Grigoriev
XEP Project Leader
RenderX
Nikolai,

Please re-consider your decision.  I, for one, am extremely pleased that 
developers on other XSL-FO projects, especially ones so successful as 
RenderX, are interested enough in FOP to monitor this list, and, even 
more, to respond here.

If you have watched us for a while, you will realise that Glen tends to 
shoot from the hip, and expresses himself forcefully.  (I have done the 
same on occasion.)  More than one of the regulars here has been stung by 
Glen's comments, but we understand that that is Glen's manner.  We value 
his contributions greatly, and shrug off the more over-the-top 
expressions of opinion because we are used to the way he says things.

I hope you can bring yourself to do the same.

Glen raised issues which we in FOP must consider carefully.  However, I 
enjoy the community of interest between us and commercial developers, 
and if you or, say, Tony Graham from Sun's xmlroff, wants to chime in to 
the discussions I welcome the input greatly.

Peter
--
Peter B. West 

RE: Just a small question...

[Andreas L. Delmelle]

> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
>

> Again, I *do* appreciate your concerns for the project as a whole, but I
> strongly doubt whether these should be a reason to remain blind to other
> peoples' approaches.
>
>

To summarize: it's all about learning from *their* mistakes as well, not? :)

Cheers,

Andreas

Re: Just a small question...

[Nikolai Grigoriev]

I realize I was wrong when I answered to this forum - I could not 
expect my words to be interpreted this way. Please disregard my 
previous message; I also unsubscribe from the list, to make you feel 
sure I don't induce anyone into wrongdoing. 

> RenderX (--still wondering which of the two is more true: either his
> employers have no idea what he's doing, or he doesn't care whether 
> they know... or he is his own employer trying to lure me into doing
> something illegal --in which case he'll fail 

I _am_ in the position to decide myself how much technical information 
about RenderX XEP can be safely disclosed. But if you prefer to see 
any word that comes from RenderX as a fraud attempt, you're welcome.

> - hey, come to think of it, does RX need money or what? =D )

And they have the money - earned by writing software, not by cheating.

Yours truly,
Nikolai Grigoriev
XEP Project Leader
RenderX


- Original Message - 
From: "Andreas L. Delmelle" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, February 05, 2004 9:58 PM
Subject: RE: Just a small question...


> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> Please do *not* share anything you find with the
> team--We don't need any you-stole-our-code headaches
> from the commercial implementations.
>

Ok, I won't

No offense, but I think you mistake my intentions here, Glen. If not, then
of course I appreciate your concern... Fact is, I have up to now blindly
refused to even have a glance at competing products, probably just because I
share these very same concerns.

To be honest: I was quite surprised to receive an answer from s.o. at
RenderX (--still wondering which of the two is more true: either his
employers have no idea what he's doing, or he doesn't care whether they
know... or he is his own employer trying to lure me into doing something
illegal --in which case he'll fail - hey, come to think of it, does RX need
money or what? =D )

>
> Be careful, Andreas--RenderX or AntennaHouse code
> should not be in FOP

I *will* be careful. I agree 100% with this, but I don't agree at all with
your stating that

> --nor should FOP developers even
> be looking at its internals.  Matter of simple
> integrity.

I think this is a bit over the top. Suppose that tomorrow, someone gets
fired at RX or AH, and this ex-employee decides to share some ideas with us.
Are we really going to tell him to take a hike?? Just because of simple
integrity? (Suppose that, before we find out, he has already submitted a few
patches that have been applied. Would we undo all of these patches, because
of 'simple integrity'?)
Please, don't get me wrong. I definitely appreciate the nobility of your
motives here, and I too would certainly enjoy the satisfaction of having it
done the honest way, whatever that means.

> Stay away from their work--it's not worth
> it!!!  At worst, it's illegal, at best you're taking
> away the reward--from everyone!--of coming up with a
> comparable implementation.

It's --should I add: of course ?- not the intention to copy anything, just
gather some ideas.

>
> I don't want FOP tarnished with 0.001% of RenderX
> or AntennaHouse code (or inspired code).

My point exactly: how are we going to make sure of that if we're not even
meant to look at their internals? (Who knows, maybe it's 0.47%
already... Besides that, you never get to see the source from commercial
implementations --source in the strict sense -, unless you're working there
or know your bytecode by heart ;) )

> If we can't provide a comparable implementation, then let us lose
> honorably.  If we can, we can then enjoy the
> satisfaction of having done it the honest way, not by
> copying work!
>

Are you by any chance familiar with (--Picasso's, I think...):
"Bad artists copy, good artists --steal."

Look at the evolution of the human species, and ask yourself: what would
have happened if every generation had to start from scratch?
What I mean is: you won't find me copying anything! (To be honest, I'm a
little offended by the mere supposition that I might be inclined to do
that... )

Again, I *do* appreciate your concerns for the project as a whole, but I
strongly doubt whether these should be a reason to remain blind to other
peoples' approaches.


Cheers,

Andreas

RE: Nasty bug: maint vs. HEAD - Some Follow-up...

[Andreas L. Delmelle]

> -Original Message-
> From: Simon Pepping [mailto:[EMAIL PROTECTED]
>
> I have seen this problem too. The PDF renderer is able to render out
> of order, but from this bug it seems that the mechanism is
> broken. Could it be that the page is inserted at the point when all
> its forward references are resolved? At that point it is rendered, but
> the PDF renderer should insert it at the proper position. That does
> not seem to happen.
>

When debugging the output using the AreaTree XML, the pages are in the
proper sequence in there (only, outside of their page-sequences?*), so
fo:page-number works as expected, correct values on the correct
pages --only, the sequence gets screwed up when rendered to PDF.

* I wonder if this is in some way related to the memory problems I ran into.
Since 0.20.5 doesn't produce page-sequences in the AreaTree XML, and
performs the PDF rendering without problems.

Cheers,

Andreas

RE: Just a small question...

[John Austin]

On Thu, 2004-02-05 at 15:28, Andreas L. Delmelle wrote:

> I think this is a bit over the top. Suppose that tomorrow, someone gets
> fired at RX or AH, and this ex-employee decides to share some ideas with us.
> Are we really going to tell him to take a hike?? Just because of simple
> integrity? (Suppose that, before we find out, he has already submitted a few
> patches that have been applied. Would we undo all of these patches, because
> of 'simple integrity'?)

I am surprised that MS or their minions at SCO haven't twigged to the
following scheme"

They could 'set-up' Open Source by masquerading as some student
in netland and submit some provably proprietary code as original.

Six months later, MS sues Linus for malfeasance with the vigorous
support of Homeland Security ... 

Of course, conspiracies never succeed for long. Some small fish
would rat them out.


-- 
John Austin <[EMAIL PROTECTED]>

RE: Just a small question...

[Andreas L. Delmelle]

> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> Please do *not* share anything you find with the
> team--We don't need any you-stole-our-code headaches
> from the commercial implementations.
>

Ok, I won't

No offense, but I think you mistake my intentions here, Glen. If not, then
of course I appreciate your concern... Fact is, I have up to now blindly
refused to even have a glance at competing products, probably just because I
share these very same concerns.

To be honest: I was quite surprised to receive an answer from s.o. at
RenderX (--still wondering which of the two is more true: either his
employers have no idea what he's doing, or he doesn't care whether they
know... or he is his own employer trying to lure me into doing something
illegal --in which case he'll fail - hey, come to think of it, does RX need
money or what? =D )

>
> Be careful, Andreas--RenderX or AntennaHouse code
> should not be in FOP

I *will* be careful. I agree 100% with this, but I don't agree at all with
your stating that

> --nor should FOP developers even
> be looking at its internals.  Matter of simple
> integrity.

I think this is a bit over the top. Suppose that tomorrow, someone gets
fired at RX or AH, and this ex-employee decides to share some ideas with us.
Are we really going to tell him to take a hike?? Just because of simple
integrity? (Suppose that, before we find out, he has already submitted a few
patches that have been applied. Would we undo all of these patches, because
of 'simple integrity'?)
Please, don't get me wrong. I definitely appreciate the nobility of your
motives here, and I too would certainly enjoy the satisfaction of having it
done the honest way, whatever that means.

> Stay away from their work--it's not worth
> it!!!  At worst, it's illegal, at best you're taking
> away the reward--from everyone!--of coming up with a
> comparable implementation.

It's --should I add: of course ?- not the intention to copy anything, just
gather some ideas.

>
> I don't want FOP tarnished with 0.001% of RenderX
> or AntennaHouse code (or inspired code).

My point exactly: how are we going to make sure of that if we're not even
meant to look at their internals? (Who knows, maybe it's 0.47%
already... Besides that, you never get to see the source from commercial
implementations --source in the strict sense -, unless you're working there
or know your bytecode by heart ;) )

> If we can't provide a comparable implementation, then let us lose
> honorably.  If we can, we can then enjoy the
> satisfaction of having done it the honest way, not by
> copying work!
>

Are you by any chance familiar with (--Picasso's, I think...):
"Bad artists copy, good artists --steal."

Look at the evolution of the human species, and ask yourself: what would
have happened if every generation had to start from scratch?
What I mean is: you won't find me copying anything! (To be honest, I'm a
little offended by the mere supposition that I might be inclined to do
that... )

Again, I *do* appreciate your concerns for the project as a whole, but I
strongly doubt whether these should be a reason to remain blind to other
peoples' approaches.


Cheers,

Andreas

cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr LineLayoutManager.java

[bckfnn]

bckfnn  2004/02/05 09:59:31

  Modified:src/java/org/apache/fop/layoutmgr LineLayoutManager.java
  Log:
  Support for text-indent.
  
  Revision  ChangesPath
  1.12  +7 -1  xml-fop/src/java/org/apache/fop/layoutmgr/LineLayoutManager.java
  
  Index: LineLayoutManager.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/java/org/apache/fop/layoutmgr/LineLayoutManager.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- LineLayoutManager.java17 Jan 2004 19:29:46 -  1.11
  +++ LineLayoutManager.java5 Feb 2004 17:59:30 -   1.12
  @@ -178,6 +178,10 @@
   clearPrevIPD();
   int iPrevLineEnd = vecInlineBreaks.size();
   
  +// Adjust available line length by text-indent. 
  +if (iPrevLineEnd == 0 && bTextAlignment == TextAlign.START) {
  +availIPD.subtract(new MinOptMax(iTextIndent));
  +}
   prevBP = null;
   
   while ((curLM = getChildLM()) != null) {
  @@ -618,7 +622,9 @@
   }
   break;
   case TextAlign.START:
  -//indent = 0;
  +if (prevLineEnd == 0) {
  +indent = iTextIndent;
  +}
   break;
   case TextAlign.CENTER:
   indent = (targetWith - realWidth) / 2;
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: xml-fop status.xml

[bckfnn]

bckfnn  2004/02/05 09:58:13

  Modified:.status.xml
  Log:
  Latest changes about property datatypes.
  
  Revision  ChangesPath
  1.35  +4 -0  xml-fop/status.xml
  
  Index: status.xml
  ===
  RCS file: /home/cvs/xml-fop/status.xml,v
  retrieving revision 1.34
  retrieving revision 1.35
  diff -u -r1.34 -r1.35
  --- status.xml22 Jan 2004 10:54:39 -  1.34
  +++ status.xml5 Feb 2004 17:58:13 -   1.35
  @@ -105,6 +105,10 @@
 
  
   
  +  Rolled property datatypes classes into the property classes and
  +  un-nested the Property.Maker inner-class.
  +
  +
 Abandoned code-generated property maker classes.
   
  
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Adding PPD support when rendering PS

[Chris Bowditch]

Alex wrote:

Hi, 
I've been looking at this for a couple of days, and figured I'd do best
to post and see what other folks think about this. 
Thanks for speaking up.

I have to implement PPD when generating PS for the project (FOP embedded
app) that I'm working on - I need to be able to force printer tray
selection/stapling etc. 
I also have had to do this. I wrote a java program to post process the 
postscript. But the tray can only be switched for physical pages, and 
not according to when a page master changes. To switch tray on logical 
pages, a change needs to be made to FOP. An extension element as a child 
of simple page master is one way of achieving this.

As such, I have "butchered" the version of FOP (0.20.5) that were using
in development here and have managed to get a rough and ready version of
what we need. If anyone is interested or has had a play with area,
please feel free to drop me a line. 

I'd be really interested if the group as a whole had any thoughts/ideas
which I could look at implementing and/or contributing back to the
project (if you'll take 'em of course!). 
Patches are most welcome, but as Jeremias pointed out they are unlikely 
to make it into 0.20.5 because that is a frozen code base. We are 
focused on HEAD development.

Thanks,

Chris