DO NOT REPLY [Bug 35534] - fo document output is placed in page margins

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

fop contribution

Hello Do not know exactly the person that is responsible for such issue as mine. So I decided to write to fop-dev. Our company has been sucessfully using FOP for several years. As our customers required extended functionality and FOP had several bugs and restrictions, 3 years ago we created our

Re: fop contribution

On 26.07.2005 15:47:03 Siarhei Baidun wrote: > Hello > Do not know exactly the person that is responsible for such issue as mine. Not a single person, but the whole FOP developer community and eventually the XML Graphics project management committee (PMC). But you found exactly the right spot to

MathML and barcode support for FOP

Devs, I'd like to have your thoughts about the following proposal. MathML and barcodes are frequently asked for and I would consider it a service to our users if we provided support for both out-of-the-box without people having to scratch together the little pieces to make this stuff work. JEuclid

Re: fop contribution

Jeremias, I'm impressed with your fluency in English... :-p On Jul 26, 2005, at 7:10 AM, Jeremias Maerki wrote: I hope that helps. If you have any further questions, don't hesitate to ask. Jeremias Maerki Regards, Web Maestro Clay -- <[EMAIL PROTECTED]> -

Re: MathML and barcode support for FOP

It all sounds good to me. I was one of those asking for batik-less FOP, since I needed to output PDF from a headless system (I think we ended up using the Postscript renderer, and cat'ing it to the printer...). I also welcome the thought of additional XML Graphics projects. Not so much for the

Flame-fodder: Thinking about starting to release again....

Another thing, that I'd like to bring up. We're approaching a state where FOP Trunk code is usable for more serious use cases. The important FOs are all implemented. In the past, we talked about making 1.0 meet XSL 1.0 Basic Conformance. I believe to do that would be bad for the project in its curr

Re: MathML and barcode support for FOP

I was not so much thinking about additional XML Graphics projects. Bringing Barcode4J here was on my mind, but not lately. I'm not sure if it would be a good fit as it doesn't exclusively have to do the converting XML to graphical output. That's only one use case. Generating barcodes as bitmap imag

Re: fop contribution

1. the insertion of exeternal PDF documents into the rendered PDF document. The mechanism is similar on the images insertion, we use fo:external-graphics element and put content-type property equals to "pdf" For example, An external PDF file is inserted into rendered PDF document AS-IS, also

Re: Flame-fodder: Thinking about starting to release again....

Jeremias Maerki wrote: Another thing, that I'd like to bring up. We're approaching a state where FOP Trunk code is usable for more serious use cases. The important FOs are all implemented. In the past, we talked about making 1.0 meet XSL 1.0 Basic Conformance. I believe to do that would be bad f

Re: fop contribution

On 26.07.2005 16:51:35 Siarhei Baidun wrote: > >> 1. the insertion of exeternal PDF documents into the rendered PDF > >> document. > >> The mechanism is similar on the images insertion, we use > >> fo:external-graphics element and put content-type property equals to > >> "pdf" > >> > >> For exam

Re: MathML and barcode support for FOP

Jeremias Maerki wrote: Devs, I'd like to have your thoughts about the following proposal. MathML and barcodes are frequently asked for and I would consider it a service to our users if we provided support for both out-of-the-box without people having to scratch together the little pieces to mak

Re: Flame-fodder: Thinking about starting to release again....

I don't know of any such convention. I've seen various variants: rc, beta, previews etc. I think we're free to choose. Starting with a couple of preview releases would IMO be good to inform people that the release is not supposed to be used in production, yet. A release candidate is more like a pr

Re: Flame-fodder: Thinking about starting to release again....

The thought of having a release from the TRUNK branch is very exciting. I agree that releasing as 0.9rc1 (or 0.9b1, since we may not yet be at release candidate stage or 0.9xx1) makes sense, and tells the world we've moved past the 0.20.5 stage, which our project and community desperately needs

Re: Flame-fodder: Thinking about starting to release again....

On Tue, Jul 26, 2005 at 08:22:28AM -0700, The Web Maestro wrote: > The thought of having a release from the TRUNK branch is very exciting. > I agree that releasing as 0.9rc1 (or 0.9b1, since we may not yet be at > release candidate stage or 0.9xx1) makes sense, and tells the world > we've moved

Re: MathML and barcode support for FOP

Having MathML and barcode support is a good thing. But I am not very enthousiastic about the goal of providing support for both out-of-the-box. Scratching pieces of functionality together and integrating them is a different role than developing an application. I am a Debian Linux user, and an advoc

Re: Flame-fodder: Thinking about starting to release again....

On 26.07.2005 17:22:28 The Web Maestro wrote: > Before we actually move to make this release, I'd like to understand > the discrepancies between 0.20.5 and the proposed 0.9rc1 release of > TRUNK a bit better. Yes, that's an important point. > I was under the impression that the first TRUNK >

Re: Flame-fodder: Thinking about starting to release again....

Jeremias Maerki wrote: I don't know of any such convention. I've seen various variants: rc, beta, previews etc. I think we're free to choose. I'd rather go for "alpha". "rc" means "release candidate", meaning features and APIs are stable, and I don't think HEAD is there already. Other than tha

Re: Flame-fodder: Thinking about starting to release again....

On 26.07.2005 21:51:03 Simon Pepping wrote: > I think that the first production release should be on parity with > 0.20.5, unless we can advertise that the gains in new features > outweigh the loss of features. The very first release does not have to > satisfy that criterion, so we can do that soo

Re: MathML and barcode support for FOP

I understand your concerns but we should make it as easy as possible for beginners. There are a lot of them, many knowing almost nothing about Java and classpaths. The beauty with these extensions is that they can easily be deleted when not used. No rebuild necessary. On 26.07.2005 21:45:33 Simon

Re: svn commit: r225143 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: apps/ fo/ render/ render/java2d/ render/pdf/ render/ps/ render/svg/ render/xml/ util/

Jeremias Maerki wrote: Just had. I must say that I don't get it from a 5 minute glance at it. Me too. Commons math used to use discovery for getting an implementation class for root solvers, but they abandoned the approach because they thought the added dependency wont outweight the benefits. B

DO NOT REPLY [Bug 21265] - referencing a custom font (TTF or Adobe Type 1) for a pdf document fails witch fop-0.20.4

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

getPageCount and FOP 1.0dev

Jeremias, happy to do so - I just setup Fop under NetBeans 4.1. However, where do I start for something like this? Manuel PS: I moved this thread over to fop-dev as I assume its more appropriate here. -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Wednesday, 2

Building Fop 1.0dev with JDK 1.3 ??

The question seemed to fit in this list rather than fop-users: I've checked out the fop trunk and tried to build it with JDK 1.3, however that doesn't seem to work (getting a number of compile errors on among other things, java.awt.Color) Is the trunk known to require JDK1.4 or higher, if not, w

Re: getPageCount and FOP 1.0dev

Manuel, thanks for grabbing this. I think the easiest thing will be to recreate what was in 0.20.5. It doesn't offer very much and I have a better overall mechanism in mind (as a long-term solution) but for the moment it is easiest to do that. Here's what I would do: - Copy over FormattingResults

Re: Building Fop 1.0dev with JDK 1.3 ??

Until we decide otherwise, FOP is still targeted at JDK 1.3 but you're right it currently doesn't compile. Nobody took the time, yet, to make it compile under 1.3. It's on my list of things but there are so many little things still to do. If you could try to fix it and send a patch that would be ab

RE: Building Fop 1.0dev with JDK 1.3 ??

Phew... OK, I'll try. Though I have very limited insight into FOP to know what my changes would incur, and unfortunately _very_ limited time so I don't want you to count on me... ;) Btw, when you develop FOP, what environment are you using ? I'm thinking of cramming it into Eclipse which is sail