From: Tobias Reif (tobiasreif@pinkjuice.com)
Date: Thu Jan 23 2003 - 13:18:08 PST
Hi
I'd be happy to get some statement from one of you RenderX guys
regarding SVG support.
I originally sent an inquiry to sales@xattic.com , in the reply
narine@renderx.com referred me to this list.
Will XEP support SVG? If so, when?
SVG 1.1 static would be the maximum XEP could support for now, with SVG
1.2 and 2.0 already in the works.
Perhaps it would make sense to start with some subset of SVG.
See
http://www.w3.org/TR/SVG11/feature#SVG-static [1]
You would simply publish a list of features strings, eg
* http://www.w3.org/TR/SVG11/feature#Shape
* http://www.w3.org/TR/SVG11/feature#Text
* http://www.w3.org/TR/SVG11/feature#CoreAttribute
* http://www.w3.org/TR/SVG11/feature#Structure
...
To make the work of document authors and illustrators easier, you could
implement module by module [2]; then, people would always have a clear
idea of what's supported.
SVG Tiny or SVG Basic
http://www.w3.org/TR/SVGMobile/
are also subsets of SVG.
Tobi
[1] http://www.w3.org/TR/SVG11/conform.html
[2] http://www.w3.org/TR/SVG11/feature.html
"Feature String:
http://www.w3.org/TR/SVG11/feature#SVG-staticUser Agent Supports:
The following features (described below)
* http://www.w3.org/TR/SVG11/feature#CoreAttribute
* http://www.w3.org/TR/SVG11/feature#Structure
* http://www.w3.org/TR/SVG11/feature#ContainerAttribute
* http://www.w3.org/TR/SVG11/feature#ConditionalProcessing
* http://www.w3.org/TR/SVG11/feature#Image
* http://www.w3.org/TR/SVG11/feature#Style
* http://www.w3.org/TR/SVG11/feature#ViewportAttribute
* http://www.w3.org/TR/SVG11/feature#Shape
* http://www.w3.org/TR/SVG11/feature#Text
* http://www.w3.org/TR/SVG11/feature#PaintAttribute
* http://www.w3.org/TR/SVG11/feature#OpacityAttribute
* http://www.w3.org/TR/SVG11/feature#GraphicsAttribute
* http://www.w3.org/TR/SVG11/feature#Marker
* http://www.w3.org/TR/SVG11/feature#ColorProfile
* http://www.w3.org/TR/SVG11/feature#Gradient
* http://www.w3.org/TR/SVG11/feature#Pattern
* http://www.w3.org/TR/SVG11/feature#Clip
* http://www.w3.org/TR/SVG11/feature#Mask
* http://www.w3.org/TR/SVG11/feature#Filter
* http://www.w3.org/TR/SVG11/feature#XlinkAttribute
* http://www.w3.org/TR/SVG11/feature#Font
* http://www.w3.org/TR/SVG11/feature#Extensibility
"
Tobias Reif wrote:
> Hi
>
> I'm currently evaluating XEP (xep317_trial on Windows), since it seems
> to implement more of the FO spec than FOP.
>
> So far, XEP indeed seems to be better than the current FOP [1] regarding
> FO support, and I would buy it right now, if it would support full SVG 1.0.
>
> In some of my DocBook projects, I make heavy use of SVG,
> eg via
>
> <fo:external-graphic src="url(ch01_pic01a.svg)" .../>
>
> Transformation to XHTML (referencing SVG) works well. Now I need to
> generate high-quality PDF from the FO (referencing SVG). FOP handles SVG
> SVG quite well already, but the FO part is not yet mature enough.
>
> XEP converts FO to PDF, and like FO, SVG is XML. Adobe's new document
> server products support FO, and SVG. Anyways, I believe SVG (among PNG
> etc) will become *the* graphics format for use with XML documents and FO.
>
> Implementing full SVG 1.0 is a *major* project, and it might not be
> feasible for you to start from scratch.
> One of the best SVG implementations is an open toolkit you probably
> know: Apache Batik's Squiggle. Perhaps you could incorporate Squiggle
> into XEP? It's being actively developed, and is the most complete open
> implementation AFAIK.
>
> Again:
> I, and probably many others, would purchase XEP it would have mature and
> comprehensive SVG 1.0 support (... and 1.2 is coming).
>
> SVG FAQ
> http://www.renderx.com/FAQ.html#1.1
>
> > 1.1. Does XEP support any form of embedded SVG inside the FO Markup
> > and, if it does, how do I get it to work?
> >
> > The current version of XEP does not support any elements outside the
> > XSL FO namespace. Moreover, we believe that free mixing of XSL FO and
> > SVG markup (as used in FOP)
>
> FOP also supports external referenced SVG, via
> fo:external-graphic src="" .
>
> > is not a clean solution,
>
> I also prefer external referenced SVG over inlined fragments, in most
> situations. But each of the two can be the best solution in a given
> scenario.
>
> > because it spoils interoperability between
> > XSL FO implementations (no means for an SVG-inaware implementation to
> > provide a fallback).
>
> There might be solutions for fallback, but I'm not aware of any right now.
> (... nor did I investigate)
>
> > The last XSL Working Draft (of March 27) provides
> > for inclusion of SVG/MathML markup by defining a special element
> > (fo:instream-foreign-object) that may contain children from outside
> > the XSL FO namespace.
>
> ... but there also is an element for referencing external SVG.
>
> > When we shift to the new draft, we plan to
> > support a subset of SVG (lines, curves, simple fills, and textboxes)
> > via this special element.
>
> Why not implement fo:external-graphic?
> Didn't you state above that you generally don't like inlined stuff in FO
> (not a clean solution)?
> fo:external-graphic looks like a better candidate to implement first.
>
> Anyways, I think it's best to support both inlined and external
> referenced SVG.
>
> I'd be happy to become your customer :)
>
> Tobi
>
> [1] FOP redesign / version 1.0 might be interesting
>
-- http://www.pinkjuice.com/ ------------------- (*) To unsubscribe, send a message with words 'unsubscribe xep-support' in the body of the message to majordomo@renderx.com from the address you are subscribed from. (*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html
This archive was generated by hypermail 2.1.5 : Thu Jan 23 2003 - 13:12:32 PST