Re: interface instead of implementation

Hi Peter Sorry, that question slipped away under my fingers. But thanks, Kevin, for this excellent answer. I couldn't have done it better. So if I may provide a short answer to your question and to sum up the mail by Kevin: IMO the cost, if any, is by far not enough to outweigh the benefits (code

Re: plan for 0.20.5 release

Will do. On Sun, 10 Nov 2002 22:58:19 +0200 Oleg Tkachenko wrote: > Jeremias Maerki wrote: > > > It works in my environment. I'd be very grateful if I got feedback if it > > works for others as well because the changes have quite some impact. > Nice feature, works like a charm for me. I believe i

Re: interface instead of implementation

On Mon, 2002-11-11 at 10:18, Peter B. West wrote: > Jeremias, > > This was a serious question, really. Joerg, when he gets back, might > like to comment on this, because it was as a result of some of his input > that I first realised there was a significant cost associated with such > Java fun

Re: interface instead of implementation

Jeremias, This was a serious question, really. Joerg, when he gets back, might like to comment on this, because it was as a result of some of his input that I first realised there was a significant cost associated with such Java fundamentals as instanceof and type casting. Those discussions

Re: plan for 0.20.5 release

Jeremias Maerki wrote: It works in my environment. I'd be very grateful if I got feedback if it works for others as well because the changes have quite some impact. Nice feature, works like a charm for me. I believe it should be documented along with baseDir and also example of defining fontBas

Re: PDF streaming through Apache.

On Sun, 10 Nov 2002, Oleg Tkachenko wrote: > Robert Ferney wrote: > > I want to be able to generate these PDF reports on the fly, however, I'm > > not really wanting to use Jakarta-Tomcat as a Http server to accomplish > > this. > Actually tomcat is a servlet engine, not http server. Do you mean yo

Re: PDF streaming through Apache.

Robert Ferney wrote: Use Background: Ok, I'm working on a database where the primary inface is web based. So I presume you have some server-side middleware between them. I want to be able to generate these PDF reports on the fly, however, I'm not really wanting to use Jakarta-Tomcat as a Http

Re: [RT] Proprietary extension to fo:external-graphic

J.Pietschmann wrote: > I think so. But nevertheless that would be a cool feature. Consider > such a real use case: one have image stored in an application jar > file. At the moment I think FOP cannot handle such case, I didn't try myself, but a jar URI should work. Something like jar:file://

DO NOT REPLY [Bug 14419] New: - Imlplement SourceResolver, Image Resolver

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_bu

PDF streaming through Apache.

System User here. Use Background: Ok, I'm working on a database where the primary inface is web based. My client wants reports where the printed results is paginated and PDF made sense, and using XML-FO to generate said documents also made sense. So, here's the rub I want to be able to generate

DO NOT REPLY [Bug 14417] New: - fop can't render embedded SVG in pcl

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_bu