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