W3C home > Mailing lists > Public > www-svg@w3.org > November 2004

Re: SVG 1.2 Comment: 4 Flowing text and graphics

From: Jon Ferraiolo <jon.ferraiolo@adobe.com>
Date: Tue, 02 Nov 2004 08:34:30 -0800
To: Robin Berjon <robin.berjon@expway.fr>, Håkon Wium Lie <howcome@opera.com>
Cc: www-svg@w3.org
Message-id: <6.1.1.1.2.20041102081254.06002f48@mailsj-v1.corp.adobe.com>

Robin,
Very well said. I will supplement your comments as follows:

At Adobe, we constantly refer to a conceptual model of three levels (well, 
actually four):

Level 3: Raw semantic XML (no styling information, no presentation information)
   *** Apply styling (e.g., CSS stylesheets) to get ***
Level 2: Reflowable, styled content (i.e., blocks, inlines, master pages, 
roughly equivalent to XSL-FO)
   *** Run formatter to get ***
Level 1: 2D graphics (roughly equivalent to SVG, PDF or PostScript)
   *** Run 2D graphics engine to get ***
Level 0: Colored bits on paper or a display

In the above model, XHTML in the absence of CSS is mainly a Level 3 grammar 
and CSS is a styling facility which performs the transformation from Level 
3 to Level 2. SVG in the absence of CSS (and most people don't use CSS with 
SVG) is mainly a Level 1 grammar.

With SVG 1.2 flowable text, we have added a small amount of Level 2 
features within the SVG language in response to the SVG community's strong 
requests. Flowable text was either the top request by the community, or at 
least it was in the top three. Large number of SVG applications require a 
small amount of text wrapping and it was just too hard to do in JavaScript 
and via attempting to mix XHTML and SVG. (Content developers tried 
valiantly on both fronts.) Thus, the SVG WG added flowing text to SVG 1.2 
in service to the Web community who requested this strongly; certainly not 
because of any desire to threaten and infringe upon the territorial domains 
of HTML or CSS.

As Peter Sorotokin has pointed out, Adobe has learned through 
implementation experience that SVG 1.2 flowable text has good compatibility 
with XHTML, CSS, and XSL-FO. We have succeeded in creating a single text 
engine that addresses all markup combinations. Our experience indicates 
that SVG 1.2 flowable text has very good compatibility characteristics with 
other related W3C technologies, which isn't a total surprise since the SVG 
WG studied tried its best to achieve good compatibility.

In my opinion, all of this talk about how SVG 1.2 flowing text infringes on 
XHTML or infringes on CSS represents barking up the wrong tree. What it 
really "infringes" on, if anything, is XSL-FO's <fo:block> and <fo:inline>. 
However, as has been pointed out in previous emails, SVG has many special 
considerations for text which are not covered by XSL-FO, such as irregular 
shapes and compound paths (e.g., shapes with cutout areas such as donut 
holes). In my assessment, the key focus for reconciliation and coordination 
of SVG 1.2 flowing text at the W3C is with the XSL-FO working group, not 
XHTML or CSS. I hope the XSL-FO working group will study the feature 
carefully and provide detailed feedback.

Jon Ferraiolo
Adobe Systems, Inc.

At 03:44 AM 11/2/2004, Robin Berjon wrote:

>Håkon, all,
>
>Håkon Wium Lie wrote:
>>The problem lies in how different specs interact. Placing strings of
>>text on a line or on a path nicely complements vector graphics and
>>naturally belongs in SVG. When you add flowing text you turn SVG from
>>a vector graphics format to a generic document format.
>
>I'll take time for longer comments later, but I have to jump in here as I 
>believe the above sentence is at the crux of the misunderstanding.
>
>Assuming that by "generic document format" you mean something along the 
>lines of "text-oriented documents like HTML" then that simply is not the case.
>
>SVG's flowable text is that neither in intent, nor in purpose, and while 
>it is difficult to predict what users will make of features I very, very 
>highly doubt that anyone will be using SVG's flow text for block/paragraph 
>style flow as defined by CSS (unless they're stuck with a UA that only 
>supports SVG).
>
>Ever seen poetry laid out inside a shape? Ever seen ad text following the 
>shiny curves of the latest spacecraft? Ever seen some sombre lament about 
>the passing of time animated as it falls through an hourglass? *That* is 
>what it's for. It's for text when used as graphics.
>
>Like all WGs, the SVG WG does indeed plan to take over the world. There's 
>no denying it. However that plan does not include making (X)HTML or CSS 
>redundant. Text flow has entirely different purposes and use cases than 
>what is currently available.
>
>Yes, it doesn't separate presentation from content. It's *graphics*. The 
>content *is* the presentation. Use as appropriate. If you want to draw a 
>cat by filling its outline with "meow" or "miaou" (having switched on the 
>user's language settings) use this. If you want to report at length on 
>Kerry's surprise landslide victory in Texas use something else.
>
>There are accessibility advantages in describing graphics in SVG over 
>sending rasters or proprietary formats like SWF but there's only so much 
>you can do. Graphics are ex definitio visual, and their semantics are 
>expressed at a different level.
>
>What's great about the CDF work starting up is precisely that people will 
>be able to use the right technology for the right situations.
>
>--
>Robin Berjon
Received on Tuesday, 2 November 2004 16:48:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:52 UTC