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 Victor Mote <vi...@outfitr.com> on 2003/04/28 21:55:17 UTC
Startup Concepts Proposal; Avalon/API
I have added a section to the Avalonization/API wiki with the title "Startup
Concepts Proposal", which outlines some thoughts I have about the hierarchy
of objects (or perhaps Avalon services ??) that I think are worth
considering as part of that project. I think it is relevant to the Avalon
work, but only tangentially to the API.
Victor Mote (mailto:vic@outfitr.com)
2025 Eddington Way
Colorado Springs, Colorado 80916
Voice +1 (719) 622-0650
Fax +1 (720) 293-0044
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Startup Concepts Proposal; Avalon/API
Posted by Stephan Michels <st...@apache.org>.
On Thu, 1 May 2003, Jeremias Maerki wrote:
> > Another problem is that it would be good to have FOP
> > eventually integrated into the JDK like Xalan and
> > Xerces are, but I don't see Sun ever including Avalon
> > into its JDK.
>
> I still hate Sun for integrating Xerces and Xalan in the JDK.
> Non-english users who have tried to run the command-line Xalan can sing
> a song. And anyone struggling with the endorsement stuff, too. Anyway,
> XSL:FO is too much of a specialized thing to be ever included in the JDK
> IMO.
Amen, can't agree more.
Stephan.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
AW: Startup Concepts Proposal; Avalon/API
Posted by "J.U. Anderegg" <ha...@bluewin.ch>.
Glen Mazza wrote:
> It is indeed unlikely, but let's not rule it out:
> a) PDF is a very common, in-demand format heavily
> promoted by Adobe as well as the anti-Microsoft,
> anti-.DOC world.
>
o PDFGraphics2D integration might be Java's direction
Copied from: JavaT Print Service API User Guide: "The Java 2 SE SDK V1.4
includes one stream print service that can export Postscript from graphics
calls, such as through the Pageable and Printable interfaces. To verify the
availability of this service, use the StreamPrintServiceFactory class to try
to locate it. The
Printing and Streaming 2D Graphics chapter discusses streaming 2D graphics".
Does Adobe promote PDFGraphics2D in the SDK?
o or take advantage from platform printer drivers available today
Copied from: JavaT Print Service API User Guide: "The base set of printers
returned from the
lookupPrintServices method are the same as
the set of printers returned by the platform. For example, when using
Windows NT, the set
of returned printers is the same as the set of printers visible in the
Windows Printer Control
Panel. Likewise, when using Solaris, the returned printers are the same as
those enumerated
by the System V Unix "lpstat" command. However, since third parties can
augment these
sets, additional printers, such as JINI printers, can be returned".
Acrobat's PDFWriter is a printer driver.
o Anyway, my point is: Java's device-independent printing/viewing is and
will be based on Graphics2D interfaces. Consequences for FOP design and
development?
Hansuli Anderegg
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Startup Concepts Proposal; Avalon/API
Posted by Glen Mazza <gl...@yahoo.com>.
--- Jeremias Maerki <de...@greenmail.ch> wrote:
> Anyway,
> XSL:FO is too much of a specialized thing to be ever
> included in the JDK
> IMO. Everyone needs an XML parser and an XSLT
> transformer but not
> everyone needs an XSL:FO processor.
>
It is indeed unlikely, but let's not rule it out:
a) PDF is a very common, in-demand format heavily
promoted by Adobe as well as the anti-Microsoft,
anti-.DOC world.
b) Sun including Xerces and Xalan into the JDK may
increase XML/XSLT usage over 4GL products such as
Oracle Reports that also generate PDF.
c) The Jakarta Struts roadmap plans for future
releases of their MVC framework to have increased
XML/XSLT integration for the view--with PDF probably
becoming a more popular output format as a result.
It will be interesting to see how this
evolves--including the issue of how much a
fast-running and reliable FOP will influence matters.
>
> Oh, I put Xalan on the same level as FOP, too. Both
> are transformers.
> Cocoon and Forrest embrace transformers. They are
> higher level
> constructs (Forrest even above Cocoon).
>
It's good to see we have the same "mental model" of
FOP.
Glen
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Startup Concepts Proposal; Avalon/API
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 29.04.2003 01:49:10 Glen Mazza wrote:
> It seems strange to have FOP sit on top of a
> framework. I would be more comfortable were Xalan and
> Xerces using Avalon, but they appear to be staying
> clear of it.
>
> Language compilers and parsers--FOP's closest
> programmatic siblings--normally don't run on top of
> external frameworks.
Normally, but that doesn't mean they can't. And FOP is not just a parser,
it's a quite complex package that has to provide various internal
services. That's where Avalon can offer a lot.
And don't forget that Cocoon is built on Avalon and FOP could use
Cocoon's internal services when run inside Cocoon (for example for
uniform URI resolution).
> With accuracy, speed, and tight
> binding to standards being the criteria of FOP's
> success, I see de-Avalonization occurring in the
> future.
Not necessarily. The standard API will then simply be a wrapper around
FOP hiding all interna (Avalon or not).
> Another problem is that it would be good to have FOP
> eventually integrated into the JDK like Xalan and
> Xerces are, but I don't see Sun ever including Avalon
> into its JDK.
I still hate Sun for integrating Xerces and Xalan in the JDK.
Non-english users who have tried to run the command-line Xalan can sing
a song. And anyone struggling with the endorsement stuff, too. Anyway,
XSL:FO is too much of a specialized thing to be ever included in the JDK
IMO. Everyone needs an XML parser and an XSLT transformer but not
everyone needs an XSL:FO processor.
> But maybe my views are different here because my
> mental model of FOP is that of an eventual
> Xalan/Xerces, while others may think of FOP in terms
> of Cocoon or Forrest.
Oh, I put Xalan on the same level as FOP, too. Both are transformers.
Cocoon and Forrest embrace transformers. They are higher level
constructs (Forrest even above Cocoon).
Documentation framework: Forrest
-------
Publishing system: Cocoon
-------
Transformer: Xalan, FOP, POI, Morphos/Piper
-------
Parser: Xerces
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Startup Concepts Proposal; Avalon/API
Posted by Glen Mazza <gl...@yahoo.com>.
It seems strange to have FOP sit on top of a
framework. I would be more comfortable were Xalan and
Xerces using Avalon, but they appear to be staying
clear of it.
Language compilers and parsers--FOP's closest
programmatic siblings--normally don't run on top of
external frameworks. With accuracy, speed, and tight
binding to standards being the criteria of FOP's
success, I see de-Avalonization occurring in the
future.
Another problem is that it would be good to have FOP
eventually integrated into the JDK like Xalan and
Xerces are, but I don't see Sun ever including Avalon
into its JDK.
But maybe my views are different here because my
mental model of FOP is that of an eventual
Xalan/Xerces, while others may think of FOP in terms
of Cocoon or Forrest.
Glen
--- Victor Mote <vi...@outfitr.com> wrote:
> I have added a section to the Avalonization/API wiki
> with the title "Startup
> Concepts Proposal", which outlines some thoughts I
> have about the hierarchy
> of objects (or perhaps Avalon services ??) that I
> think are worth
> considering as part of that project. I think it is
> relevant to the Avalon
> work, but only tangentially to the API.
>
> Victor Mote (mailto:vic@outfitr.com)
> 2025 Eddington Way
> Colorado Springs, Colorado 80916
> Voice +1 (719) 622-0650
> Fax +1 (720) 293-0044
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> fop-dev-unsubscribe@xml.apache.org
> For additional commands, email:
> fop-dev-help@xml.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org