You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Jeremias Maerki <de...@greenmail.ch> on 2003/04/23 18:02:58 UTC
Re: uniform formatter interface (jaxp)
While discussing the new API the use of JAXP with FOP came up. Having
something similar to JAXP would be a good thing IMO. I'd appreciate if
you investigated your idea. Of course, we would like to have
implementations for both the maintenance branch and the redesign but it
probably makes more sense to make a proof of concept on the maintenance
branch first. Please also see the Wiki page below for info on what is
going on in the API corner.
There are several things to keep in mind when trying this approach:
- OutputStreams are not the only possible output path. There's AWT,
direct printing, SAX output (Area tree XML), etc.
- There are parameters that need to be set: Encryption, PostScript Level,
etc.
Well, while writing this, I think it is not absolutely necessary that we
handle the AWT case over a simple JAXP-style API. It's a special case
anyway so we might just as well have our users use the Avalon-based API
in that case.
Thanks for voluteering. You're also invited to participate in the
shaping of our new API (see Wiki).
References:
- http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization
- mailing list archives
On 23.04.2003 17:13:32 Barry Van Landeghem wrote:
> Hi guys,
> There is something that bothers me. There are these days many formatters around but there is not one uniform way to talk to those formatters. On the other hand there are also many XML parsers and Transformers but JAXP is there a uniform way to use a parser or transformer independent of a specific vendor implementation.
> So wouldn't it be nice to have some kind of extension to JAXP so it can also be used for every formatter. I think people would like if they can do stuff like.
> FormatterFactory factory = FormatterFactory.newInstance();
> formatter = factory.newFormatter();
> formatter.format(new StreamSource(new FileInputStream("input.fo")),new StreamResult(new FileOutputStream("output.pdf")));
> Of course is this just a simple example but you get the picture...
> If you guys think that this might indeed be a good idea then I would like to volunteer to make such framework in JAXP for formatting as a FOP implementation as well. Consider it then as a proof of concept. If it then turns out to work nice and good then it perhaps might be useful to make a demand to the JCP to extend the JAXP API. But of course that are issues for later. For now I just want to know if you like the idea, if you would like me to work this out in detail or not, etc ...
> And on which FOP API should I try to do this? The old API or the new Avalonized API?
> Let me know your opinion...
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: uniform formatter interface (jaxp)
Posted by Jeremias Maerki <de...@greenmail.ch>.
I didn't mean to say we have to include it in 0.20.5. We need a better
API. That's a fact. The Driver and InputHandler stuff is just plain
strange. Even more importantly we need a stable API that can be used by
the Cocoon guys. The Cocoon-FOP-Block is a big hack and we need to be
able to switch between the old and new FOP easily in Cocoon. But this is
not possible with the old Driver API IMHO.
So this has nothing to do with a moving target. This is research work.
Barry's work can (ATM) easily be a separate package that simply provides
a good API (read: Adapter) for XSL-FO processors (not only FOP for that
matter).
On 23.04.2003 18:23:44 Clay Leeds wrote:
> I've read Victor's comments RE: changing the focus of 1.0Dev to merely
> bringing the it up to speed with the maintenance branch (functionality
> of 1.0dev = functionality of 0.20.5). This makes sense to me. I realize
> nothing has been "decided" either way on this topic yet. Once fop-0.20.5
> (final) is released, focus on getting 1.0dev up-to-speed to the level of
> 0.20.5 (final). Then, add whatever bells and whistles are requested.
>
> Getting 1.0dev out the door will be a lot easier if the door isn't
> moving laterally and/or vertically along the wall. Having worked on too
> many projects that never saw the light of day because they were based on
> a continually moving target. Define the target, and then shoot for it.
>
> (NOTE: Don't get me wrong! It "hurts" me to say, 'Don't work on nifty
> feature "X"!' It's just that I want to play with 0.20.5rc3 (!) and my
> thought is that the addition of one more thing will only mean it'll take
> that much longer for 0.20.5rc3 will see the light of day! ;-p)
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: uniform formatter interface (jaxp)
Posted by Clay Leeds <cl...@medata.com>.
Howdy Devs,
I've read Victor's comments RE: changing the focus of 1.0Dev to merely
bringing the it up to speed with the maintenance branch (functionality
of 1.0dev = functionality of 0.20.5). This makes sense to me. I realize
nothing has been "decided" either way on this topic yet. Once fop-0.20.5
(final) is released, focus on getting 1.0dev up-to-speed to the level of
0.20.5 (final). Then, add whatever bells and whistles are requested.
Getting 1.0dev out the door will be a lot easier if the door isn't
moving laterally and/or vertically along the wall. Having worked on too
many projects that never saw the light of day because they were based on
a continually moving target. Define the target, and then shoot for it.
(NOTE: Don't get me wrong! It "hurts" me to say, 'Don't work on nifty
feature "X"!' It's just that I want to play with 0.20.5rc3 (!) and my
thought is that the addition of one more thing will only mean it'll take
that much longer for 0.20.5rc3 will see the light of day! ;-p)
Respectfully,
Web Maestro Clay
Jeremias Maerki wrote:
> While discussing the new API the use of JAXP with FOP came up. Having
> something similar to JAXP would be a good thing IMO. I'd appreciate if
> you investigated your idea. Of course, we would like to have
> implementations for both the maintenance branch and the redesign but it
> probably makes more sense to make a proof of concept on the maintenance
> branch first. Please also see the Wiki page below for info on what is
> going on in the API corner.
>
> There are several things to keep in mind when trying this approach:
> - OutputStreams are not the only possible output path. There's AWT,
> direct printing, SAX output (Area tree XML), etc.
> - There are parameters that need to be set: Encryption, PostScript Level,
> etc.
>
> Well, while writing this, I think it is not absolutely necessary that we
> handle the AWT case over a simple JAXP-style API. It's a special case
> anyway so we might just as well have our users use the Avalon-based API
> in that case.
>
> Thanks for voluteering. You're also invited to participate in the
> shaping of our new API (see Wiki).
>
> References:
> - http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization
> - mailing list archives
>
> On 23.04.2003 17:13:32 Barry Van Landeghem wrote:
--
Clay Leeds - cleeds@medata.com
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org