Re: Serialization

[Keiron Liddle]

Hi Peter,

An inner class is actually a separate class that contains a reference to 
the containing class.
When the class is serialized it will serialize that reference (since I 
presume it is not transient).
If the class is static then it will not have a rreference to the 
containing class but that may not be suitable for other reasons.

On 2002.03.13 02:44 Peter B. West wrote:
> Dear Fops,
> 
> I'm naïve about serialization (among other things.)  Can anyone tell me 
> whether it is possible to serialize an instance of an inner class 
> without implicitly serializing the containing class instance?
> 
> Peter

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

Re: LoggingHandler patch [was: Using Avalon/Logkit]

[Jeremias Maerki]

Michael

It's me again. I'm against that for the reasons layed out in my mail
from a few moments ago. I appreciate your effort but I think this is the
wrong way. I'm not a committer so my opinion doesn't count but I have
grown very fond of FOP to just be silent.

Cheers,
Jeremias Märki

mailto:[EMAIL PROTECTED]

OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Tel. +41 41 317 2020 - Fax +41 41 317 2029
Internet http://www.outline.ch


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

Re: Using Avalon/Logkit

[Jeremias Maerki]

Michael

> Jeremias Maerki wrote:
> > Logging is one thing. Error handling (like layout problems, image that
> > can't be found etc.) is another. Right
> As much as it at the moment. Obviously, errors need to be reported, and 
> the most convenient way to do that is via a logging mechanism. In 
> addition, it's often useful if there's some sort of callback mechanism 
> so that the application, whether that be Driver or some code embedding 
> FOP, can decide how to continue, *if* it should continue, and 
> potentially, how to log the error.
> 
> Again, I think the way SAX does this, using org.xml.sax.ErrorHandler, is 
> a convenient and flexible way to go.

Right, I think we agree here.

> > Logging: I'd go for the Avalon Logger interface which lets us freely
> > choose the logging backend. We can even use the new ConsoleLogger or
> > even NullLogger. :-)
> 
> Fair enough, but I maintain that it's still too much work for embedders. 
> It is a right pain to have to have to include two more large libraries 
> (Avalon and Logkit) with your application just to let FOP do logging, 
> and it's too much functionality if your application has it's own logging 
> mechanism already.
> 
> I'd suggest it would be a poor move to lock FOP into using one 
> particular logging mechanism, especially when there are many 
> alternatives out there: Log4J, 1.4's native logging mechanism, and all 
> the existing, custom jobs, many of which have rabid supporters who won't 
> use anything else. 8)

I'm exactly proposing this. I suggest you really have a look at Avalon.
Avalon is very far from being another large library. Avalon Framework is
46K, LogKit is about 52K. Is that large? Avalon consists of several
subprojects (Framework, LogKit, Excalibur, Cornerstone, Phoenix and
Applications). Framework is the core which defines some simple contracts.
org.apache.avalon.framework.logger.Logger is almost exactly what you did
in your proposal, except that you introduce yet another API, while the
one from Avalon is mature and already has implementations for LogKit,
Log4J, JDK14Logging, Console logging und /dev/null logging. We're
talking about reusing mature code. And that sometimes means we have one
more jar to include. But what holds us back from extracting the classes
we need from avalon-framework.jar and include them in fop.jar. Not very
nice, but if it has to be that way... IMO software development today
goes more and more in the direction of reusing instead of doing it again
and again. You can build big complex application by using several
modules and plugging them together. A consequence of that is that we
have to get used to add some more jars to our classpaths. That's a small
effort when placed against the benefit of reusing mature software.

Here's the interface:
http://jakarta.apache.org/avalon/api/org/apache/avalon/framework/logger/Logger.html

Avalon won't stop at only providing a logging facility. FOP can profit
form several components especially in Excalibur by not having to
implement its own. For example the Cocoon team is currently moving some
components (like SourceResolver) over to Avalon Excalibur. As another
FOP could also profit from the use of the caching framework (for images).

A big genefit from using Avalon pattern is that it forces you to create
cleaner more reusable code. My company has profited a lot from adopting
Avalon.

I'm disappointed that you're shooting against something you don't know.

> > Error handling: We had a short discussion back in November. Doing that
> > in the user agent sounds good (it's the obvious place) although I can't
> > fully figure out yet if this solves everything we need. 
> 
> I agreee, FOP needs something like the ProblemListener you suggested in 
> the thread above.
> 
> As I suggested in an earlier email WRT logging, I think the UA is the 
> right place to get an instance of an ErrorHandler/ProblemListener, but 
> should not itself be responsible for that functionality. What should 
> happen (IMHO) is similar to the SAX model:
> 
> The application (Driver, or the embedding app) optionally supplies an 
> instance of ErrorHandler. If none is supplied, a default instance is 
> used which provides resonable default behavior (something like letting 
> warnings pass but throwing exceptions for errors). When an error 
> condition arises, the code should obtain that instance of ErrorHandler 
> from the UA or potentially elsewhere (but it should not just instantiate 
> it's own) and invoke the appropriate method on the handler, passing it 
> an appropriate exception object. The implementation then decides if it 
> is worth throwing that exception, and can do anything else it considers 
> worthwhile as well.
> Again, with this sort of mechansim, you get flexibility and control, and 
> it is very much embedding-friendly.

Seems like we agree here.

Cheers,
Jeremias Märki

mailto:[EMAIL PROTECTED]

OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Tel. +41 41 317 2020 - Fax +41 

LoggingHandler patch [was: Using Avalon/Logkit]

[Michael Gratton]

Guys,

To further to my suggestions about using an interface for logging in 
core FOP components, I've produced a working implementation of my 
suggestion. After a precursory test using the command line, the changes 
seem to work fine.

The patch, for the "fop-0_20_3" branch in CVS, and the two additional 
required source files are available at:

   

The two added files are src/org/apache/fop/apps/LoggingHandler.java and 
src/org/apache/fop/apps/LogkitLoggingHandler.java. The former is the 
LoggingHandler interface, which has replaced any use of 
org.apache.log.Logger in core FOP code. The latter is an implementation 
of LoggingHandler which uses Logkit and is Loggable (for Avalon).

I've identified three applications which use assume the use of Logkit 
for logging: The command line app, the FOP task for Ant and 
TestConverter. All three have been modified to use LogkitLoggingHandler 
and hence function in the exact same fashion as before. In addition, if 
no LoggingHandler is explicitly set on Driver, it by default uses an 
instance of LogkitLoggingHandler, again to make it behave the same as 
before.

Embedders who do not wish to use Logkit for logging can write their own 
implementation of LoggingHandler and call Driver.setLogger() prior 
invoking Driver.render().

There are three issues which need to be addressed before I would 
consider this code ready to commit:
  - Is the Loggable implementation of LogkitLoggingHandler sufficient 
for Avalon? Not really knowing how Avalon works, I'm not sure if 
implementing Loggable on LogkitLoggingHandler is sufficient, or will an 
"AvalonDriver" subclass of Driver be needed which translates between 
logging objects be required? Can any Avalon gurus comment on this?
  - MessageHandler's use of Logger for screen output needs to be fixed. 
This will probably require a setLoggingHandler() method to be added, and 
ensuring it gets called prior to MessageHandler getting invoked.
  - ToBeImplementedProperty grabs a Logger out of thin air, this should 
probably use MessageHandler or just throw an exception (as outlined in 
the comments for that class in the patch).

Outstanding, non-essential work includes:
  - Perhaps renaming {get|set}Logger() on Renderer and similar classes 
to {get|set}LoggingHandler()
  - Adding optional implementations of LoggingHandler for Log4J, 1.4's 
logging mechanism, and any others.

Please have a look at the patch, try it out applied to the "fop-0_20_3" 
branch and let me know if you have any suggestions. I'll fix up the 
three issues above sometime in the next few days and post a new patch.

Provided it all works well, would anyone mind having these changes 
committed to the tree?

Thanks,
Mike.

-- 
Michael Gratton <[EMAIL PROTECTED]>
Recall Design 
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555



smime.p7s
Description: S/MIME Cryptographic Signature

Re: userconfig.xml

[David B. Bitton]

Revelation:

Now I know why System.getProperties("user.dir") == "c:\windows\system32",
because that's where the Tomcat NT service must start from (not to mention
the java.exe that's in that folder also).  Hmm, what to do?  Ok, so how can
I have a not so relative path?

Conundrum:

How can I gain access to configuration info that resides in the web.xml file
for the SOAP servlet that calls my class, that in turn calls FOP?


--

David B. Bitton
[EMAIL PROTECTED]
www.codenoevil.com

Diversa ab illis virtute valemus.
- Original Message -
From: "Beer, Christian" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, March 12, 2002 2:55 AM
Subject: AW: userconfig.xml


> > Yeah.  If I try File file = new File("userconfig.xml"), where
> > is it looking
> > relative to the class file requesting the file?
> >
> No, he is looking relative to the path you started java from.
>
> Greets,
> Christian
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>


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

Serialization

[Peter B. West]

Dear Fops,

I'm naïve about serialization (among other things.)  Can anyone tell me 
whether it is possible to serialize an instance of an inner class 
without implicitly serializing the containing class instance?

Peter


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

Re: Using Avalon/Logkit

[Michael Gratton]

Jeremias Maerki wrote:
> Logging is one thing. Error handling (like layout problems, image that
> can't be found etc.) is another. Right
As much as it at the moment. Obviously, errors need to be reported, and 
the most convenient way to do that is via a logging mechanism. In 
addition, it's often useful if there's some sort of callback mechanism 
so that the application, whether that be Driver or some code embedding 
FOP, can decide how to continue, *if* it should continue, and 
potentially, how to log the error.

Again, I think the way SAX does this, using org.xml.sax.ErrorHandler, is 
a convenient and flexible way to go.

> Logging: I'd go for the Avalon Logger interface which lets us freely
> choose the logging backend. We can even use the new ConsoleLogger or
> even NullLogger. :-)

Fair enough, but I maintain that it's still too much work for embedders. 
It is a right pain to have to have to include two more large libraries 
(Avalon and Logkit) with your application just to let FOP do logging, 
and it's too much functionality if your application has it's own logging 
mechanism already.

I'd suggest it would be a poor move to lock FOP into using one 
particular logging mechanism, especially when there are many 
alternatives out there: Log4J, 1.4's native logging mechanism, and all 
the existing, custom jobs, many of which have rabid supporters who won't 
use anything else. 8)

> Error handling: We had a short discussion back in November. Doing that
> in the user agent sounds good (it's the obvious place) although I can't
> fully figure out yet if this solves everything we need. 

I agreee, FOP needs something like the ProblemListener you suggested in 
the thread above.

As I suggested in an earlier email WRT logging, I think the UA is the 
right place to get an instance of an ErrorHandler/ProblemListener, but 
should not itself be responsible for that functionality. What should 
happen (IMHO) is similar to the SAX model:

The application (Driver, or the embedding app) optionally supplies an 
instance of ErrorHandler. If none is supplied, a default instance is 
used which provides resonable default behavior (something like letting 
warnings pass but throwing exceptions for errors). When an error 
condition arises, the code should obtain that instance of ErrorHandler 
from the UA or potentially elsewhere (but it should not just instantiate 
it's own) and invoke the appropriate method on the handler, passing it 
an appropriate exception object. The implementation then decides if it 
is worth throwing that exception, and can do anything else it considers 
worthwhile as well.
Again, with this sort of mechansim, you get flexibility and control, and 
it is very much embedding-friendly.

Mike.

-- 
Michael Gratton <[EMAIL PROTECTED]>
Recall Design 
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Using Avalon/Logkit

[Michael Gratton]

Keiron Liddle wrote:
> 
> I think the are three possibilities:
> - use a generic logging package such as found in avalon, it is quite 
> possible to use the LogkitLogger, Log4JLogger and Jdk14Logger

True, but it introduces a dependency on Yet Another API (YAAPI). I'm 
generalizing here, but in my experience and from what I've picked up 
from other people in similar situations, is that keeping YAAPI bloat to 
a bare minimum is highly desirable.

> - use an interface

I see this as the most flexible method.

> - use methods on the user agent

I can see that this approach would provide some flexibility, but I'd 
suggest that the UA would be useful for obtaining an instance of the 
logging interface, rather than exposing methods for doing the actual 
error reporting itself, exactly as it does at the moment.

> The interface almost guarantees that we will need extra code to do 
> things that everyone else is doing. 

I don't think the amount of extra code would be too great. It would 
require 2 additional source files right now: one for the interface, one 
for the default Logkit implementation. Both would be tiny.

> We also need to remember context and threading issues.
> 

True.

What I have in mind, after getting some sleep in on it, would be to 
define an interface for all logging, effectively just replacing 
references org.apache.log.Logger in the existing code with this 
interface. So getLogger() and setLogger() on Driver, Renderer, etc 
accept or return objects which implement this interface, for example.

I would suggest that this interface look somewhat like a cut down 
version of org.apache.log.Logger - one that only exposes logging methods 
such as info(), warn(), error(), etc. For the default implementation we 
  extend org.apache.log.Logger and have the new subclass implement this 
interface, or provide just provide a wrapper implementation. Lastly, 
modify Driver (and any other classes which provide default loggers) to 
instantiate the new default implementation class instead of a Logger, 
and you're done.

For extreme convenience, the interface's logging methods could be 
identical to those of Logger, so that the default impementation would be 
extremely basic, and the calls to methods on Logger in existing code 
would not need to be changed.

This mechanism is fast, conveient, and above all, flexible. It means 
that embedders can write their own, thin implementation of the logging 
interface and set that on Driver, rather than having to use Avalon and 
Logkit, but existing users see no change whatsoever, unless they are 
getting and modifying the default logger provided by Driver or similar. 
In those cases, it would be a small change to get it working again.

If no one has any other objections, I'll whip up a patch for review on 
the list.

Mike.

-- 
Michael Gratton <[EMAIL PROTECTED]>
Recall Design 
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555



smime.p7s
Description: S/MIME Cryptographic Signature

DO NOT REPLY [Bug 7063] New: - text alignment problems when using fo:wrapper

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=7063

text alignment problems when using fo:wrapper 

   Summary: text alignment problems when using fo:wrapper
   Product: Fop
   Version: 0.20.3
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Minor
  Priority: Other
 Component: pdf renderer
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Characters are rendered on top of each when using the fo:wrapper.  I change my  
font characteristics to use a bold and larger font at a beginning on a 
sentence, then close the fo:wrapper (sentence start text).  The original font 
characteristics then render the rest of the sentence (sentence end text).  The 
sentence start text correctly renders but the sentence end text begins to 
render over the sentence start text.

Ex xsl snippet:  

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

Re: [iText-questions] Re: merging two libraries

[Nicola Ken Barozzi]

From: "alex" <[EMAIL PROTECTED]>

> At 14:27 12/03/02, Keiron Liddle wrote:
> > > FOP behaves exactly the same but instead of having its own pdf
> > generation code then iText is
>  > used as a library to generate pdf.
>
> I agree that if anything iText could be considered as a "plugin" for PDF
> generation and FOP as an XSL:FO processor which could use iText to
generate
> the end result. I think however it would require a significant software
> change which I am not qualified to estimate. Those more familiar with the
> FOP source code can evaluate that.
>
> > > So the questions are:
> > > - is the license useable
> > > - is the api sufficient for FOP to use
>
> A look at Sourceforge tells us that the licenCes (bloody Americans can't
> spell English words) are
> License: GNU Lesser General Public License (LGPL), Mozilla Public License
1.1
>
> If Bruno is still the copyright holder then he can presumably simply "add"
> an Apache-style licence.
> I don't feel comfortable using the LGPL for this and don't know about the
> Mozilla license.

Any *GPL licenced stuff cannot go in Apache CVS.
If the code goes in the Apache CVS, it must have Apache licen(c|s)e.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


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

RE: Error with 20.0.3!

[Savino, Matt C]

MostFrequentlyAskedQuestion

Just adding a keyword to this thread for future archive search pointers.

Matt


> -Original Message-
> From: David B. Bitton [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 12, 2002 9:13 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Error with 20.0.3!
> 
> 
> Snipped from CHANGES in the 0.20.3 distro:
> 
> ...
> - Changed "master-name" to "master-reference" on fo:page-sequence,
>   fo:single-page-master-reference, 
> fo:repeatable-page-master-reference and
>   fo:conditional-page-master-reference to comply with the latest XSL
> recommendation.
>   Also changed the unimplemented property space-treatment to
> white-space-treatment and
>   updated examples and tests to use the new syntax.
> ...
> 
> You need to update you XSL-FO to reflect this change in the code.
> 
> --
> 
> David B. Bitton
> [EMAIL PROTECTED]
> www.codenoevil.com
> 
> Diversa ab illis virtute valemus.
> - Original Message -
> From: "Klosa Uwe" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, March 12, 2002 5:29 AM
> Subject: Error with 20.0.3!
> 
> 
> > With 20.0.2 all pages worked fine, but now I'm getting the following
> error:
> >
> > org.apache.fop.apps.FOPException: 'master-reference' for
> > 'fo:page-sequence'matches no 'simple-page-master' or
> 'page-sequence-master'
> > at
> >
> org.apache.fop.fo.pagination.PageSequence.getNextPageMaster(Pa
> geSequence.jav
> > a:532)
> > at
> > 
> org.apache.fop.fo.pagination.PageSequence.makePage(PageSequenc
> e.java:334)
> > at
> > 
> org.apache.fop.fo.pagination.PageSequence.format(PageSequence.
> java:268)
> > at
> > org.apache.fop.apps.StreamRenderer.render(StreamRenderer.java:200)
> > at
> > org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:182)
> > at
> > org.apache.fop.tools.DocumentReader.parse(DocumentReader.java:463)
> > at org.apache.fop.apps.Driver.render(Driver.java:481)
> > at org.apache.fop.apps.Driver.render(Driver.java:501)
> > at
> >
> diva.xml.xsql.serializers.XSQLFOP203Serializer.serialize(XSQLF
> OP203Serialize
> > r.java:43)
> > at
> > 
> oracle.xml.xsql.XSQLPageProcessor.process(XSQLPageProcessor.java:282)
> > at oracle.xml.xsql.XSQLServlet.doGet(XSQLServlet.java:60)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilt
> er(Application
> > FilterChain.java:247)
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli
> cationFilterCh
> > ain.java:193)
> > at
> >
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardW
> rapperValve.ja
> > va:243)
> > at
> >
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardP
> ipeline.java:5
> > 66)
> > at
> >
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipel
> ine.java:472)
> > at
> > 
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > at
> >
> org.apache.catalina.core.StandardContextValve.invoke(StandardC
> ontextValve.ja
> > va:190)
> > at
> >
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardP
> ipeline.java:5
> > 66)
> > at
> >
> org.apache.catalina.valves.CertificatesValve.invoke(Certificat
> esValve.java:2
> > 46)
> > at
> >
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardP
> ipeline.java:5
> > 64)
> > at
> >
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipel
> ine.java:472)
> > at
> > 
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > at
> > 
> org.apache.catalina.core.StandardContext.invoke(StandardContex
> t.java:2343)
> > at
> >
> org.apache.catalina.core.StandardHostValve.invoke(StandardHost
> Valve.java:180
> > )
> > at
> >
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardP
> ipeline.java:5
> > 66)
> > at
> >
> org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDi
> spatcherValve.
> > java:170)
> > at
> >
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardP
> ipeline.java:5
> > 64)
> > at
> >
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReport
> Valve.java:170
> > )
> > at
> >
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardP
> ipeline.java:5
> > 64)
> > at
> > 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValv
> e.java:468)
> > at
> >
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardP
> ipeline.java:5
> > 64)
> > at
> >
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipel
> ine.java:472)
> > at
> > 
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > at
> >
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEn
> gineValve.java
> > :174)
> > at
> >
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardP
> ipeline.java:5
> > 66)
> > at
> >
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipel
> ine.java:472)
> > at
> > 
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > at
> > 

Re: [iText-questions] Re: merging two libraries

[alex]

At 14:27 12/03/02, Keiron Liddle wrote:
> > FOP behaves exactly the same but instead of having its own pdf 
> generation code then iText is
 > used as a library to generate pdf.

I agree that if anything iText could be considered as a "plugin" for PDF 
generation and FOP as an XSL:FO processor which could use iText to generate 
the end result. I think however it would require a significant software 
change which I am not qualified to estimate. Those more familiar with the 
FOP source code can evaluate that.


> > So the questions are:
> > - is the license useable
> > - is the api sufficient for FOP to use

A look at Sourceforge tells us that the licenCes (bloody Americans can't 
spell English words) are
License: GNU Lesser General Public License (LGPL), Mozilla Public License 1.1

If Bruno is still the copyright holder then he can presumably simply "add" 
an Apache-style licence.
I don't feel comfortable using the LGPL for this and don't know about the 
Mozilla license.

Now I can't even find the exact text of these on the sourceforge site but I 
know they must be somewhere.

I suppose I could always just download the software since the licences will 
be in the software package, no?

Alex




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

Re: FW: [iText-questions] Re: merging two libraries

[David B. Bitton]

Absolutely.  In fact, I am using iText to do just that, encryption.  iText
has a PDFReader class that take a byte[] array for the constructor.

...
PdfReader reader = new PdfReader(out.toByteArray());
...

goto to http://www.lowagie.com/iText/tutorial/ch01.html#readingPDF and check
out the http://www.lowagie.com/iText/examples/Encrypt.java sample.  If you
check the API JavaDocs, you can see how you can adapt the sample to use the
PdfReader constructor i noted earlier.  :)

--

David B. Bitton
[EMAIL PROTECTED]
www.codenoevil.com

Diversa ab illis virtute valemus.
- Original Message -
From: "Matt Savino" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, March 12, 2002 8:32 AM
Subject: Re: FW: [iText-questions] Re: merging two libraries


> Is it possible to use iText for post-FOP processing like encryption or
> adding conditional text based on page breaks?
>
> "New, Cecil (GEAE)" wrote:
> >
> > My suggestion was *not* to merge the two!
> >
> > iText is a Java API with a document creation focus.  In this day and
age,
> > XSL:FO can be viewed as just another document type - in the same way
that
> > more proprietary or older formats are (that is, PDF, RTF, etc.).
> >
> > Now XSL:FO is different in that you can't just double click on one and
see
> > something.  But the FOP project comes close.
> >
> > Making iText (optionally) output xsl:fo would greatly extend its
potential
> > applications and make it squarely standards based.
> >
> > I would like to think that someday, StarOffice, Wordperfect, etc. would
> > either natively use xsl:fo as their file storage format or at least be
able
> > to import it.
> >
> > Having something like iText that *programatically* create documents is
very
> > exciting!
> >
> > -Original Message-
> > From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, March 12, 2002 3:53 AM
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: [iText-questions] Re: merging two libraries
> >
> > Hi,
> >
> >  From the archives it appears that the discussion on the fop-dev list
was
> > about 2 years ago (no apparent refusal though). It is certainly time to
> > revisit.
> >
> >  From the small amount of information I know about iText it would appear
> > to be a more advanced pdf library.
> > I don't know what the license issues might be.
> >
> > What sort of joining forces are you proposing?
> >
> > Please send to the fop-dev list for further discussion.
> >
> > Regards,
> > Keiron.
> >
> > On 2002.03.12 09:27 [EMAIL PROTECTED] wrote:
> > > Hello all,
> > >
> > > I'm not familiar with FOP, but I can't help noticing
> > > that people are moving from FOP to iText and vice versa. As original
> > > developer of iText, a JAVA-PDF library, I already
> > > proposed you guys at Apache twice to join forces and to combine
> > > both libraries. I now subscribe to this mailing list only to
> > > ask you a third time to reconsider your refusal. Please read these
mails
> > > from some iText/FOP users:
> > > http://www.geocrawler.com/lists/3/SourceForge/8175/0/8071577/
> > >
> >
http://www.mail-archive.com/itext-questions%40lists.sourceforge.net/msg00491
> >
> > > .html Please send your answers to the iText mailing list.
> > > You don't need to subscribe, I will pass them through.
> > > Remark: sorry, but due to the lack of time to read all
> > > my mail as it is, I will now unsubscribe from the FOP
> > > mailing list. kind regards,
> > > Bruno Lowagie
> >
> > ___
> > iText-questions mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/itext-questions
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>


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

Re: Error with 20.0.3!

[David B. Bitton]

Snipped from CHANGES in the 0.20.3 distro:

...
- Changed "master-name" to "master-reference" on fo:page-sequence,
  fo:single-page-master-reference, fo:repeatable-page-master-reference and
  fo:conditional-page-master-reference to comply with the latest XSL
recommendation.
  Also changed the unimplemented property space-treatment to
white-space-treatment and
  updated examples and tests to use the new syntax.
...

You need to update you XSL-FO to reflect this change in the code.

--

David B. Bitton
[EMAIL PROTECTED]
www.codenoevil.com

Diversa ab illis virtute valemus.
- Original Message -
From: "Klosa Uwe" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, March 12, 2002 5:29 AM
Subject: Error with 20.0.3!


> With 20.0.2 all pages worked fine, but now I'm getting the following
error:
>
> org.apache.fop.apps.FOPException: 'master-reference' for
> 'fo:page-sequence'matches no 'simple-page-master' or
'page-sequence-master'
> at
>
org.apache.fop.fo.pagination.PageSequence.getNextPageMaster(PageSequence.jav
> a:532)
> at
> org.apache.fop.fo.pagination.PageSequence.makePage(PageSequence.java:334)
> at
> org.apache.fop.fo.pagination.PageSequence.format(PageSequence.java:268)
> at
> org.apache.fop.apps.StreamRenderer.render(StreamRenderer.java:200)
> at
> org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:182)
> at
> org.apache.fop.tools.DocumentReader.parse(DocumentReader.java:463)
> at org.apache.fop.apps.Driver.render(Driver.java:481)
> at org.apache.fop.apps.Driver.render(Driver.java:501)
> at
>
diva.xml.xsql.serializers.XSQLFOP203Serializer.serialize(XSQLFOP203Serialize
> r.java:43)
> at
> oracle.xml.xsql.XSQLPageProcessor.process(XSQLPageProcessor.java:282)
> at oracle.xml.xsql.XSQLServlet.doGet(XSQLServlet.java:60)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
> FilterChain.java:247)
> at
>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
> ain.java:193)
> at
>
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
> va:243)
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
> 66)
> at
>
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
>
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
> va:190)
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
> 66)
> at
>
org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:2
> 46)
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
> 64)
> at
>
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2343)
> at
>
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180
> )
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
> 66)
> at
>
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
> java:170)
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
> 64)
> at
>
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170
> )
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
> 64)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468)
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
> 64)
> at
>
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
>
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
> :174)
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
> 66)
> at
>
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
> org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:429)
> at
> org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:495)
> at java.lang.Thread.run(Thread.java:536)
>
> This is my stylesheet:
>
> 
> http://www.w3.org/1999/XSL/Transform";
> xmlns:fo="http://www.w3.org/1999/XSL/Format";
version="1.0">
>   
> 
>
>   
> page-height="24.2cm"
>page-width="16.4cm"
>margin-top="0.0cm"
>margin-bottom="1cm"
>margin-left="2cm"
>margin-right="2cm">
>   
> 

RE: PDF -> FO (slightly off topic)

[Jonathan Jenkins]

I was really after a lazy way to pull the style information 
out - I agree though that without the structural info - 
its of limited use.

-Original Message-
From: Beer, Christian [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 12, 2002 8:00 AM
To: '[EMAIL PROTECTED]'
Subject: AW: PDF -> FO (slightly off topic)


> 
> Apologies for the slightly off-topic mail - but does anyone 
> know of an 
> easy way to convert PDF docs to XSL-FO ?
> 

I don't think there is any way to do this, especialy no easy 
way!

PDF does not contain any structural information, like XSL-FO 
does. So that would have to be constructed. But the output 
would not be very good, I think.


Christian


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

Re: problems with fo:external-graphic

[Guillaume Laforge]

Hello Michael,
 
Do you still have the same problem ? 
(SVGDocument class not found ?)
I've got the same problem. It heavily 
depends on your tomcat version you are using.
A quick hack for me was to move batik.jar 
from my WEB-INF/lib directory to Tomcat's common/lib.
It works, but it's not very cool if you 
wish to make a deployable archive (a WAR file), because you have to install the 
WAR, AND THEN : Batik.jar in common/lib.
I think the problem comes from Tomcat 
itself, in the way it loads the jar files. The custom class loaders behaves 
totally differently between Tomcat 3.2 and Tomcat 4.0.x. And even between Tomcat 
4.0.1, 2 and 3 
I dont have the problem with Tomcat 
4.0.1 (jdk1.3.1 on Linux and on Windows2K) and the problem appears with 
Tomcat 4.0.3 on W2K. 

Did you find another solution to this 
problem ?
 
Guillaume

   "Michael 
  Schifferdecker" <[EMAIL PROTECTED]> wrote
  Hello all,I have a problem with 
  fo:external-graphic.I use a Servlet to do PDF generation together with 
  a test style sheet whichproduces FO-code in which the following 
  fo:external-graphic is contained:...height="0.58cm" 
  width="2.71cm"/>...When I use this under jBuilder with 
  integrated Apache Tomcat 3.2 to includethe GIF fd_logo.gif into the PDF 
  everything works fine.But: after the whole application is distributed 
  to my stand alone Tomcat 4.0server problems occur (see following 
  exception).The error occurs with FOP 0.20.2RC and with 0.20.3 
  also.What's the cause for this?What alternatives do I 
  have?Best regards, Michael(exception information 
  follows)exception root cause...  
  java.lang.NoClassDefFoundError: org/w3c/dom/svg/SVGDocumentcomplete 
  exception as follows...type Exception reportmessage Internal 
  Server Errordescription The server encountered an internal error 
  (Internal Server Error)that prevented it from fulfilling this 
  request.exceptionjavax.servlet.ServletException: Servlet 
  execution threw an exception	atroot 
  causejava.lang.NoClassDefFoundError: 
  org/w3c/dom/svg/SVGDocument	atorg.apache.fop.image.analyser.ImageReaderFactory.Make(ImageReaderFactory.java:45)	at 
  org.apache.fop.image.FopImageFactory.Make(FopImageFactory.java:100)	at 
  org.apache.fop.fo.flow.ExternalGraphic.layout(ExternalGraphic.java:125)	at 
  org.apache.fop.fo.flow.Block.layout(Block.java:259)	at 
  org.apache.fop.fo.flow.TableCell.layout(TableCell.java:263)	at 
  org.apache.fop.fo.flow.TableRow.layout(TableRow.java:344)	at 
  org.apache.fop.fo.flow.TableBody.layout(TableBody.java:172)	at 
  org.apache.fop.fo.flow.Table.layout(Table.java:226)	at 
  org.apache.fop.fo.flow.Block.layout(Block.java:259)	at 
  org.apache.fop.fo.flow.StaticContent.layout(StaticContent.java:78)	atorg.apache.fop.fo.pagination.PageSequence.layoutStaticContent(PageSequence.java:413)	atorg.apache.fop.fo.pagination.PageSequence.formatStaticContent(PageSequence.java:362)	at 
  org.apache.fop.fo.pagination.PageSequence.format(PageSequence.java:302)	at 
  org.apache.fop.apps.StreamRenderer.render(StreamRenderer.java:191)	at 
  org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:178)	at 
  org.apache.xerces.parsers.SAXParser.endElement(SAXParser.java:1398)	atorg.apache.xerces.validators.common.XMLValidator.callEndElement(XMLValidator.java:1007)	atorg.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1255)	atorg.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:380)	at 
  org.apache.xerces.framework.XMLParser.parse(XMLParser.java:908)	at 
  org.apache.fop.apps.Driver.render(Driver.java:459)	at 
  org.apache.fop.apps.Driver.run(Driver.java:542)	atformdirekt.pdfgen.POSTReceiveServlet.renderFO(POSTReceiveServlet.java:145)	at 
  formdirekt.pdfgen.POSTReceiveServlet.doPost(POSTReceiveServlet.java:71)	at 
  javax.servlet.http.HttpServlet.service(HttpServlet.java:760)	at 
  javax.servlet.http.HttpServlet.service(HttpServlet.java:853)	at.

Re: Using Avalon/Logkit

[Jeremias Maerki]

Logging is one thing. Error handling (like layout problems, image that
can't be found etc.) is another. Right?

Logging: I'd go for the Avalon Logger interface which lets us freely
choose the logging backend. We can even use the new ConsoleLogger or
even NullLogger. :-)

Error handling: We had a short discussion back in November. Doing that
in the user agent sounds good (it's the obvious place) although I can't
fully figure out yet if this solves everything we need. Well, I should
think about that some more, then.
http://marc.theaimsgroup.com/?l=fop-dev&m=100642654705366&w=2

> If you can do it and it will be an improvement then I welcome your input.
> 
> I think the are three possibilities:
> - use a generic logging package such as found in avalon, it is quite 
> possible to use the LogkitLogger, Log4JLogger and Jdk14Logger
> - use an interface
> - use methods on the user agent
> 
> The interface almost guarantees that we will need extra code to do things 
> that everyone else is doing. The user agent could provide flexibility 
> while incorporating the first option.
> 
> We also need to remember context and threading issues.
> 
> On 2002.03.12 08:09 Michael Gratton wrote:
> > Personally, I'd suggest having core FOP logging services taken care of 
> > by something akin to org.xml.sax.ErrorHandler. This mechanism works 
> > quite nicely. FOP could provide a default implementation which uses 
> > Logkit/Avalon and embedders could provide their own.
> > 
> > Also, I'm prepared to put my money where my mouth is, so to speak. If 
> > people are happy with this approach, I'll gladly implement it over the 
> > next few days. I hope this conveys how important I think this issue is.
> > 
> > What does everyone say?

Cheers,
Jeremias Märki

mailto:[EMAIL PROTECTED]

OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Tel. +41 41 317 2020 - Fax +41 41 317 2029
Internet http://www.outline.ch


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

Re: [iText-questions] Re: merging two libraries

[Keiron Liddle]

That sounds like a good suggestion.

To start with I think we should consider only this:
FOP behaves exactly the same but instead of having its own pdf generation 
code then iText is used as a library to generate pdf.

So the questions are:
- is the license useable
- is the api sufficient for FOP to use

Once this is sorted out then we can think of other areas.

On 2002.03.12 15:05 Nicola Ken Barozzi wrote:
> From: "New, Cecil (GEAE)" <[EMAIL PROTECTED]>
> 
> > My suggestion was *not* to merge the two!
> >
> > iText is a Java API with a document creation focus.  In this day and
> age,
> > XSL:FO can be viewed as just another document type - in the same way
> that
> > more proprietary or older formats are (that is, PDF, RTF, etc.).
> 
> Sorry if it's a bit off-topic, but this issue is similar to the one we
> just
> managed to handle between POI (http://jakarta.apache.org/poi/) and Cocoon
> (http://xml.apache.org/cocoon/).
> 
> POI is a project that makes it possible to read-write common office file
> formats in Java.
> Cocoon is an XML processing framework-server.
> 
> The POI team donated a Cocoon component that uses POI and outputs XML,
> but
> on the Cocoon side, committers saw too much POI code in it.
> 
> Basically we understood that a project to read-write a file format should
> have a solid Java API. Other projects can use it to produce other
> results.
> Merging is not the best solution, both for developers and users.
> 
> >From this experience, I would humbly suggest that, after getting the
> licencing stuff straight, FOP could be refactored to use iText as a PDF
> generation step.
> In this way communities can focus on a smaller part of the project with
> greater efficiency, and the two products may have a much wider
> applicability
> than a single merged one.
> 
> Since iText has a strong community behind it, since it would like to
> integrate code with FOP, thus coming to Apache, and since FOP could use
> part
> of it proficiently, I would like to see iText make a proposal at Jakarta
> for
> the creation of a project.
> All details for this are under
> http://jakarta.apache.org/site/newproject.html .
> 
> What do you think?

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

Re: [iText-questions] Re: merging two libraries

[Nicola Ken Barozzi]

From: "New, Cecil (GEAE)" <[EMAIL PROTECTED]>

> My suggestion was *not* to merge the two!
>
> iText is a Java API with a document creation focus.  In this day and age,
> XSL:FO can be viewed as just another document type - in the same way that
> more proprietary or older formats are (that is, PDF, RTF, etc.).

Sorry if it's a bit off-topic, but this issue is similar to the one we just
managed to handle between POI (http://jakarta.apache.org/poi/) and Cocoon
(http://xml.apache.org/cocoon/).

POI is a project that makes it possible to read-write common office file
formats in Java.
Cocoon is an XML processing framework-server.

The POI team donated a Cocoon component that uses POI and outputs XML, but
on the Cocoon side, committers saw too much POI code in it.

Basically we understood that a project to read-write a file format should
have a solid Java API. Other projects can use it to produce other results.
Merging is not the best solution, both for developers and users.

>From this experience, I would humbly suggest that, after getting the
licencing stuff straight, FOP could be refactored to use iText as a PDF
generation step.
In this way communities can focus on a smaller part of the project with
greater efficiency, and the two products may have a much wider applicability
than a single merged one.

Since iText has a strong community behind it, since it would like to
integrate code with FOP, thus coming to Apache, and since FOP could use part
of it proficiently, I would like to see iText make a proposal at Jakarta for
the creation of a project.
All details for this are under
http://jakarta.apache.org/site/newproject.html .

What do you think?

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


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

Re: FW: [iText-questions] Re: merging two libraries

[Matt Savino]

Is it possible to use iText for post-FOP processing like encryption or
adding conditional text based on page breaks?

"New, Cecil (GEAE)" wrote:
> 
> My suggestion was *not* to merge the two!
> 
> iText is a Java API with a document creation focus.  In this day and age,
> XSL:FO can be viewed as just another document type - in the same way that
> more proprietary or older formats are (that is, PDF, RTF, etc.).
> 
> Now XSL:FO is different in that you can't just double click on one and see
> something.  But the FOP project comes close.
> 
> Making iText (optionally) output xsl:fo would greatly extend its potential
> applications and make it squarely standards based.
> 
> I would like to think that someday, StarOffice, Wordperfect, etc. would
> either natively use xsl:fo as their file storage format or at least be able
> to import it.
> 
> Having something like iText that *programatically* create documents is very
> exciting!
> 
> -Original Message-
> From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 12, 2002 3:53 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [iText-questions] Re: merging two libraries
> 
> Hi,
> 
>  From the archives it appears that the discussion on the fop-dev list was
> about 2 years ago (no apparent refusal though). It is certainly time to
> revisit.
> 
>  From the small amount of information I know about iText it would appear
> to be a more advanced pdf library.
> I don't know what the license issues might be.
> 
> What sort of joining forces are you proposing?
> 
> Please send to the fop-dev list for further discussion.
> 
> Regards,
> Keiron.
> 
> On 2002.03.12 09:27 [EMAIL PROTECTED] wrote:
> > Hello all,
> >
> > I'm not familiar with FOP, but I can't help noticing
> > that people are moving from FOP to iText and vice versa. As original
> > developer of iText, a JAVA-PDF library, I already
> > proposed you guys at Apache twice to join forces and to combine
> > both libraries. I now subscribe to this mailing list only to
> > ask you a third time to reconsider your refusal. Please read these mails
> > from some iText/FOP users:
> > http://www.geocrawler.com/lists/3/SourceForge/8175/0/8071577/
> >
> http://www.mail-archive.com/itext-questions%40lists.sourceforge.net/msg00491
> 
> > .html Please send your answers to the iText mailing list.
> > You don't need to subscribe, I will pass them through.
> > Remark: sorry, but due to the lack of time to read all
> > my mail as it is, I will now unsubscribe from the FOP
> > mailing list. kind regards,
> > Bruno Lowagie
> 
> ___
> iText-questions mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/itext-questions
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]

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

FW: [iText-questions] Re: merging two libraries

[New, Cecil (GEAE)]

My suggestion was *not* to merge the two!

iText is a Java API with a document creation focus.  In this day and age,
XSL:FO can be viewed as just another document type - in the same way that
more proprietary or older formats are (that is, PDF, RTF, etc.).

Now XSL:FO is different in that you can't just double click on one and see
something.  But the FOP project comes close.

Making iText (optionally) output xsl:fo would greatly extend its potential
applications and make it squarely standards based.

I would like to think that someday, StarOffice, Wordperfect, etc. would
either natively use xsl:fo as their file storage format or at least be able
to import it.

Having something like iText that *programatically* create documents is very
exciting!

-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 12, 2002 3:53 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [iText-questions] Re: merging two libraries


Hi,

 From the archives it appears that the discussion on the fop-dev list was 
about 2 years ago (no apparent refusal though). It is certainly time to 
revisit.

 From the small amount of information I know about iText it would appear 
to be a more advanced pdf library.
I don't know what the license issues might be.

What sort of joining forces are you proposing?

Please send to the fop-dev list for further discussion.

Regards,
Keiron.


On 2002.03.12 09:27 [EMAIL PROTECTED] wrote:
> Hello all,
> 
> I'm not familiar with FOP, but I can't help noticing
> that people are moving from FOP to iText and vice versa. As original 
> developer of iText, a JAVA-PDF library, I already
> proposed you guys at Apache twice to join forces and to combine
> both libraries. I now subscribe to this mailing list only to
> ask you a third time to reconsider your refusal. Please read these mails 
> from some iText/FOP users:
> http://www.geocrawler.com/lists/3/SourceForge/8175/0/8071577/
>
http://www.mail-archive.com/itext-questions%40lists.sourceforge.net/msg00491

> .html Please send your answers to the iText mailing list.
> You don't need to subscribe, I will pass them through.
> Remark: sorry, but due to the lack of time to read all
> my mail as it is, I will now unsubscribe from the FOP
> mailing list. kind regards,
> Bruno Lowagie

___
iText-questions mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/itext-questions

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

Re: [ANNOUNCEMENT] Fop 0.20.3 released

[Raimund Kammering]

Hi,

in the announcement for the fop 0.20.3 release there was a note about
EPS images. I am not sure what this means:

a.) Now you can also use EPS images in the FOP -> PDF process
b.) FOP can now produce an EPS file as output

I guess and hope the first is meant?!
But if so I couldn't figure out how to include EPS images in my fo file.

A simple include by

(just the way as it is done with JPEG) dose not work. I got an error
message like:
--snip--
[INFO]: [2]
[ERROR]: Batik not in class path
[ERROR]: Error while creating area : No ImageReader for this type of
image (myepsfile.eps)
--snip--

What am I doing wrong (by the way batik IS definitely in my classpath)?
Or is there no support for input of EPS images - meaning b.) was right?

Any comments and tips are very wellcome!

Raimund
--
DESY -MVP-
Notkestrasse 85
D-22603 Hamburg
Tel.: +49 40 8998 -4903
e-mail: [EMAIL PROTECTED]



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

RE: merging two libraries

[Arved Sandstrom]

OK, thanks. The messages certainly don't indicate that we turned down any
proposal, per se. I happened to be talking about PDFLib and CLibPDF
specifically in one referenced message, but Fotis (and others) were talking
about the others, and the idea is all the same. It sure looks to me like we
were looking specifically at integration, but I don't recall that we were
talking about _inclusion_. It was as straightforward as saying, "do we have
good interfaces for allowing other PDF producers to be used, and if not, do
we want to?"

The main thing, though, is that I think this issue just died. Nobody had
very strong opinions. We had PDF code all along that met the needs of the
moment. No argument that other PDF libraries may have done specific things
better all along, or maybe many things better, but we never (as I recall)
found the PDF generation side of things to be a major problem. It's always
been property handling and layout.

Regards,
AHS

-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: March 12, 2002 7:14 AM
To: [EMAIL PROTECTED]
Subject: Re: merging two libraries

The references that I found are:
http://marc.theaimsgroup.com/?l=fop-dev&m=86952068309324&w=2
and
http://marc.theaimsgroup.com/?l=fop-dev&m=86952068308872&w=2

both over 2 years ago.

On 2002.03.12 11:56 Arved Sandstrom wrote:
> I can't seem to usefully search the archive (no search terms have any
> apparent effect), so I'll just have to assume that we did talk about it.
> If
> someone has the URL and/or search terms that actually work then I can
> revisit, but in the meantime it doesn't ring a bell that we at any time
> flat-out refused to "join forces", so to speak. I am not saying we didn't
> give that appearance, but I don't remember anything that positive.
>
> So I second Keiron in asking, what kind of useful cooperation do you
> propose?
>
> I've been aware of iText for quite a while - I tried it out when it was
> still rugPDF - and I'll speculate that if anything was a question at an
> earlier time that perhaps there was no clear idea of how iText would help
> FOP. And that statement would have to be interpreted in the light of what
> iText offered at the time. I'm prepared to accept that the PDF rendering
> capabilities of iText have gotten considerably better in the meantime,
> and
> it makes sense to look at the matter again. IMO.
>
> Regards,
> Arved Sandstrom

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


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

Re: merging two libraries

[Keiron Liddle]

The references that I found are:
http://marc.theaimsgroup.com/?l=fop-dev&m=86952068309324&w=2
and
http://marc.theaimsgroup.com/?l=fop-dev&m=86952068308872&w=2

both over 2 years ago.

On 2002.03.12 11:56 Arved Sandstrom wrote:
> I can't seem to usefully search the archive (no search terms have any
> apparent effect), so I'll just have to assume that we did talk about it.
> If
> someone has the URL and/or search terms that actually work then I can
> revisit, but in the meantime it doesn't ring a bell that we at any time
> flat-out refused to "join forces", so to speak. I am not saying we didn't
> give that appearance, but I don't remember anything that positive.
> 
> So I second Keiron in asking, what kind of useful cooperation do you
> propose?
> 
> I've been aware of iText for quite a while - I tried it out when it was
> still rugPDF - and I'll speculate that if anything was a question at an
> earlier time that perhaps there was no clear idea of how iText would help
> FOP. And that statement would have to be interpreted in the light of what
> iText offered at the time. I'm prepared to accept that the PDF rendering
> capabilities of iText have gotten considerably better in the meantime,
> and
> it makes sense to look at the matter again. IMO.
> 
> Regards,
> Arved Sandstrom

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

Re: [ANNOUNCEMENT] Fop 0.20.3 released

[Christian Geisert]

David B. Bitton wrote:

> I notice the timestamp on the files is 3/4.  Is that right, because that
> means I already have code made fresh daily.


Yeah, that correct. I've just been on holiday last week and had
no time to send the announcement until now.

> David B. Bitton

Christian


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

DO NOT REPLY [Bug 6676] - PNG images where supported in version 0.20.2 but not anymore in version 0.20.3.

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=6676

PNG images where supported in version 0.20.2 but not anymore in version 0.20.3.





--- Additional Comments From [EMAIL PROTECTED]  2002-03-12 10:31 ---
According to Bug 6691 and after test, the version 0.20.3rc (Jan 19th) work fine
with PNG images as version 0.20.3rc2 and 0.20.3 don't.

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

Error with 20.0.3!

[Klosa Uwe]

With 20.0.2 all pages worked fine, but now I'm getting the following error:

org.apache.fop.apps.FOPException: 'master-reference' for
'fo:page-sequence'matches no 'simple-page-master' or 'page-sequence-master'
at
org.apache.fop.fo.pagination.PageSequence.getNextPageMaster(PageSequence.jav
a:532)
at
org.apache.fop.fo.pagination.PageSequence.makePage(PageSequence.java:334)
at
org.apache.fop.fo.pagination.PageSequence.format(PageSequence.java:268)
at
org.apache.fop.apps.StreamRenderer.render(StreamRenderer.java:200)
at
org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:182)
at
org.apache.fop.tools.DocumentReader.parse(DocumentReader.java:463)
at org.apache.fop.apps.Driver.render(Driver.java:481)
at org.apache.fop.apps.Driver.render(Driver.java:501)
at
diva.xml.xsql.serializers.XSQLFOP203Serializer.serialize(XSQLFOP203Serialize
r.java:43)
at
oracle.xml.xsql.XSQLPageProcessor.process(XSQLPageProcessor.java:282)
at oracle.xml.xsql.XSQLServlet.doGet(XSQLServlet.java:60)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:243)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:190)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:2
46)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2343)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180
)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
java:170)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170
)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:174)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:429)
at
org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:495)
at java.lang.Thread.run(Thread.java:536)

This is my stylesheet:


http://www.w3.org/1999/XSL/Transform";
xmlns:fo="http://www.w3.org/1999/XSL/Format"; version="1.0">
  


  

  


  

  

  

  

  


What's wrong now?

Uwe

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

DO NOT REPLY [Bug 6676] - PNG images where supported in version 0.20.2 but not anymore in version 0.20.3.

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=6676

PNG images where supported in version 0.20.2 but not anymore in version 0.20.3.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|Windows NT/2K   |All
Summary|external-graphics does not  |PNG images where supported
   |work|in version 0.20.2 but not
   ||anymore in version 0.20.3.



--- Additional Comments From [EMAIL PROTECTED]  2002-03-12 09:58 ---
PNG images where supported in version 0.20.2 but not anymore in version 0.20.3
(any  release).

We are using fop to build PDF file from a xml and a xsl file. 

The test was made with binary distribution and source file recompiled of fop
0.20.3. Both tests have beed done on a Linux box (Red hat 7.2 Enigma) and
Windows 2000 with java 1.2.2 and 1.3.1.

The test with fop binary 0.20.2 have been done on a Windows 2000 box with java
1.3.1.

I send an attached zip file (simple_test.zip) to test.

Cedric.

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

DO NOT REPLY [Bug 6676] - external-graphics does not work

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=6676

external-graphics does not work





--- Additional Comments From [EMAIL PROTECTED]  2002-03-12 09:46 ---
Created an attachment (id=1335)
Attachement include a xml exemple, a xsl exemple for version 0.20.2 and 0.20.3 and 2 
images (gif and png)

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

Re: Using Avalon/Logkit

[Keiron Liddle]

If you can do it and it will be an improvement then I welcome your input.

I think the are three possibilities:
- use a generic logging package such as found in avalon, it is quite 
possible to use the LogkitLogger, Log4JLogger and Jdk14Logger
- use an interface
- use methods on the user agent

The interface almost guarantees that we will need extra code to do things 
that everyone else is doing. The user agent could provide flexibility 
while incorporating the first option.

We also need to remember context and threading issues.

On 2002.03.12 08:09 Michael Gratton wrote:
> Personally, I'd suggest having core FOP logging services taken care of 
> by something akin to org.xml.sax.ErrorHandler. This mechanism works 
> quite nicely. FOP could provide a default implementation which uses 
> Logkit/Avalon and embedders could provide their own.
> 
> Also, I'm prepared to put my money where my mouth is, so to speak. If 
> people are happy with this approach, I'll gladly implement it over the 
> next few days. I hope this conveys how important I think this issue is.
> 
> What does everyone say?
> 
> Mike.

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

Re: merging two libraries

[Keiron Liddle]

Hi,

 From the archives it appears that the discussion on the fop-dev list was 
about 2 years ago (no apparent refusal though). It is certainly time to 
revisit.

 From the small amount of information I know about iText it would appear 
to be a more advanced pdf library.
I don't know what the license issues might be.

What sort of joining forces are you proposing?

Please send to the fop-dev list for further discussion.

Regards,
Keiron.


On 2002.03.12 09:27 [EMAIL PROTECTED] wrote:
> Hello all,
> 
> I'm not familiar with FOP, but I can't help noticing
> that people are moving from FOP to iText and vice versa. As original 
> developer of iText, a JAVA-PDF library, I already
> proposed you guys at Apache twice to join forces and to combine
> both libraries. I now subscribe to this mailing list only to
> ask you a third time to reconsider your refusal. Please read these mails 
> from some iText/FOP users:
> http://www.geocrawler.com/lists/3/SourceForge/8175/0/8071577/
> http://www.mail-archive.com/itext-questions%40lists.sourceforge.net/msg00491 
> .html Please send your answers to the iText mailing list.
> You don't need to subscribe, I will pass them through.
> Remark: sorry, but due to the lack of time to read all
> my mail as it is, I will now unsubscribe from the FOP
> mailing list. kind regards,
> Bruno Lowagie

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

fop-dev@xml.apache.org

[Charley Collins]

I tried to use page-position first, rest and last. But right now I can't
get last to work.Last will allways be true.

I found nothing about a limitation on the fop web site.

Is this feature implemented? 

If not, will it be implemented?

I think page-position="last" is much more complicate to implement than
first or rest!


Greetings

Charley



-- 

Charley Collins
COLLINS EDV-Service
Hegenheimerstrasse 40
CH-4123 Allschwil

Tel.0848 COLLINS
oder0848 2655467
Fax 01 274 22 02
mailto: [EMAIL PROTECTED]


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