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 bu...@apache.org on 2001/11/21 16:02:14 UTC

DO NOT REPLY [Bug 4999] New: - FOP claims to support the same SVG elements as Batik, but it doesn't

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=4999>.
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=4999

FOP claims to support the same SVG elements as Batik, but it doesn't

           Summary: FOP claims to support the same SVG elements as Batik,
                    but it doesn't
           Product: Fop
           Version: all
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: svg
        AssignedTo: fop-dev@xml.apache.org
        ReportedBy: jamie.lokier@degree2.com


In the "implemented" documentation, there is a claim that FOP
supports the same SVG elements and attributes as Batik, because it
uses Batik's renderer.

Not so!

Specifically, I am unable to render an instream-foreign-object which
contains the font-face, font-face-src and font-face-uri elements.
Those are used to reference SVG fonts.  These work fine in standalone Batik.

(I have to use SVG fonts because Batik doesn't look at the
same font database as FOP, and I've never managed to get TTF fonts
working with Batik satisfactorily).
I'm guessing that this is because FOP's instream-foreign-object doesn't
simply pass the DOM subtree to Batik, but instead for some reason
parses the subtree itself then reconstructs it for Batik.  I have no idea
why.
cheers,
-- Jamie

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org