headers
Keiron Liddle | 1 May 2003 01:21

Re: svg doc

> It would seem cleaner to have this (very well-written)
> information on the Batik site--so all Batik users can
> be aware of it--and add a Forrest <note> on the FOP
> SVG page letting them know (1) you don't need to use
> FOP for SVG->PDF generation, and (2) referring them to
> this information on the Batik site.  (This may also
> have the added benefit of routing User ML questions on
> SVG transcoders properly to the Batik site.)

I agree totally. Now that the pdf-transcoder is distributed with batik it is even more 
appropriate.

Glen, do you think you would be able to help out with this, a quick patch or two?

Thanks.

> Glen
> 
> --- Jeremias Maerki <dev.jeremias <at> greenmail.ch> wrote:
> > Back from the beach... :-)
> > 
> > I do. Keiron probably, too. This is about the
> > transcoders (SVG->PDF,
> > SVG->PostScript, SVG->EPS) that represent a very
> > useful Batik extension.
> > You can see it as some kind of sub-subproject of
> > FOP. We can probably
> > separate the Transcoder documentation from the rest
> > a bit to avoid
> > confusion. So a simple remove is to quite the right
(Continue reading)

Permalink | Reply | 501 comments |
headers
Glen Mazza | 1 May 2003 03:32
Picon
Favicon

Re: svg doc

I'll look into it tomorrow.

--- Keiron Liddle <keiron <at> aftexsw.com> wrote:
> 
> Glen, do you think you would be able to help out
> with this, a quick patch or two?
> 
> Thanks.
> 

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
Permalink | Reply | 501 comments |
headers
Jeremias Maerki | 1 May 2003 10:50
Picon
Favicon

Re: Rendering PDF with EPS graphics in it


On 25.04.2003 18:30:58 Olivier Imbert wrote:
> Hi all,
> I sent the mail hereafter on the user list but nobody answer so I send it here 
> ...
> 
>  I have to render PDF including EPS graphics.
>  Everything renders fine using FOP 0.20.4.
>  I got a performance issue when printing on a PostScript printer  (several
>  types used) thru Acrobat Reader : for each page including EPS graphics the
>  printer spend a lot of time (formatting ?) before printing.
>  Printing an equivalent document from WordPerfect to the postscript printer
>  works fine.
>  Any idea ? Is there anything I can tune in the way FOP encapsulate EPS in
>  PDF ?
> 
> One thing I cannot understand is why fop insert a "scale" command before the 
> eps content and why this scale command is linked to the bounding box of the 
> eps ... The scale parameter seem very small also ...

I did not write the EPS wrapper but I believe the scale parameter is
basically so small (around 1/1000) because FOP works with millipoints
internally while PostScript/EPS works with points (1pt = 1000
millipoints) initially.

> For the same EPS file I got the fop following generation :

<snip what="Two PostScript wrappers for EPS files"/>

> Any idea or suggestion will be welcome ...
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jeremias Maerki | 1 May 2003 19:52
Picon
Favicon

Re: Merge TRAXInputHandler into XSLTInputHandler?

I'd prefer if we called it "new API", not "avalonized API". Because we
may end up with two different APIs.

On 28.04.2003 18:33:59 J.Pietschmann wrote:
> In the avalonized API, both classes will be deprecated.

Jeremias Maerki
Permalink | Reply | 4 comments |
headers
Jeremias Maerki | 1 May 2003 20:09
Picon
Favicon

Re: Startup Concepts Proposal; Avalon/API


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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Stephan Michels | 1 May 2003 20:28
Picon
Favicon

Re: Startup Concepts Proposal; Avalon/API


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.
Permalink | Reply | 0 comments |
headers
bugzilla | 1 May 2003 23:24
Picon
Favicon

DO NOT REPLY [Bug 19530] - graphics.xml: Link to Batik site for Rasterizer documentation

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19530>.
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=19530

graphics.xml:  Link to Batik site for Rasterizer documentation

------- Additional Comments From glenmazza <at> yahoo.com  2003-05-01 21:24 -------
Created an attachment (id=6142)
Diff file of graphics.xml
Permalink | Reply | 0 comments |
headers
bugzilla | 1 May 2003 23:23
Picon
Favicon

DO NOT REPLY [Bug 19530] New: - graphics.xml: Link to Batik site for Rasterizer documentation

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19530>.
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=19530

graphics.xml:  Link to Batik site for Rasterizer documentation

           Summary: graphics.xml:  Link to Batik site for Rasterizer
                    documentation
           Product: Fop
           Version: 1.0dev
          Platform: Other
               URL: http://xml.apache.org/fop/graphics.html#svg
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: documentation
        AssignedTo: fop-dev <at> xml.apache.org
        ReportedBy: glenmazza <at> yahoo.com

Note added to graphics.xml indicating to user that Batik's SVG Rasterizer 
utility may also be used to generate PDF from SVG documentation.  A link to the 
SVG Rasterizer documentation is provided.
Permalink | Reply | 0 comments |
headers
bugzilla | 1 May 2003 23:25
Picon
Favicon

DO NOT REPLY [Bug 19530] - [PATCH] graphics.xml: Link to Batik site for Rasterizer documentation

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19530>.
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=19530

[PATCH] graphics.xml:  Link to Batik site for Rasterizer documentation

glenmazza <at> yahoo.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|graphics.xml:  Link to Batik|[PATCH] graphics.xml:  Link
                   |site for Rasterizer         |to Batik site for Rasterizer
                   |documentation               |documentation
Permalink | Reply | 0 comments |
headers
Glen Mazza | 1 May 2003 23:56
Picon
Favicon

Re: Startup Concepts Proposal; Avalon/API

--- Jeremias Maerki <dev.jeremias <at> 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.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane