RE: SVG 1.2 Comment: 4 Flowing text and graphics

Hi, Ian-

Ian Hickson wrote:
| 
| On Tue, 2 Nov 2004, Robin Berjon wrote:
| > 
| > 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.
| 
| All three of those examples are great examplies of documents 
| that need semantic markup. 

That seems like a stretch to me. What do any of those particularly need
markup for? Much less the rather poor semantics of HTML...

Are you arguing that:

<p>Fly me to the moon...</p>

Has more semantics than:

<text><textPath xlink:href='#rocketCurve'>Fly me to the
moon...</textPath></text>

? I don't see how. Unless you're going to mark up your poetry with
<metaphor> and <simile> and <irony> tags, I don't think you're going to get
much more semantic content. Ok, perhaps <cite> could be useful... But
couldn't you embed that in <metadata>, with some proper RDF, in SVG?

(For the record, I think that Robin might have been referencing this:
http://svg-whiz.com/svg/text/flowTextHourglass.svg
Note that you'll need ASV6pr1 to view it; it uses their preliminary syntax.)


| Sure, they are presented with 
| lovely shapes. But at the heart of the issue, they are still 
| text, and it would make just as much sense for them to be 
| rendered aurally using a speech CSS stylesheet, or to a TTY 
| using a UA's built-in styling rules, or to have them indexed 
| using Semantic Web inference rules.

Why are you assuming that a proper UA couldn't extract the <text> and
present it in an appropriate fashion? I can author a document with poor
semantics just as easily with HTML+CSS as with SVG; you can't mandate good
authoring. But I think that SVG provides ample tools to address the needs of
those authors who want to create accessible documents, from <title> and
<desc> and <hint>, to custom namespaces (which I used to create a
linguistics app that tagged the parts of speech and theta roles of words as
well or better than I could have done in HTML), to <metadata> (with RDF or
what-have-you).

But I don't even agree with your original claim. The very essense of
"concrete poetry" is that it *is* in a shape; it's designed explicitly to
mix both text and drawing, and deprived of that context, it doesn't make
"just as much sense". No matter how well you describe a Monet painting to a
person blind from birth, they won't understand it the same way you do; they
won't have the same emotional reaction to it at a visceral level. That's not
to say that we shouldn't describe it, just that we must understand that it's
a lossy process. Text can be extracted and given alternate presentation, but
it's simply not the same, in these cases.

Did you see how you had to struggle to read the whole paragraph in the
hourglass sample I provided? How it slipped away from you even as you were
reading it? That wasn't an accident... I did that on purpose. It might not
be high art, but it wouldn't have been the same read aloud.

Another use case that Robin didn't mention is text bubbles in comics. This
is different than novels or cartoons. It has its own aesthetic and pragmatic
requirements.

| If those three examples are examples of when multiline text 
| is to be used in SVG, then multiline text in SVG should be 
| done by applying SVG to documents in other markup languages, 
| not by adding more text markup to SVG, in clear violation of 
| both AWWW and WCAG.

Which other presentation layer markup languages are you proposing? Which
three or four presentation markups would provide richer semantics than can
be afforded in SVG using the capabilities I mentioned?

All of this is beside the point, however. It's clear from your above
statement that you agree that we need the capability to use SVG to provide
text that flows within a given shape. If this can be done in a mixed-NS
document, it should be able to be done in a single-NS document, the NS that
provides the layout mechanism.

Without a proper mechanism to lay out multiline text within an arbitrary
shape, it simply couldn't be done. I have seen 3 proposals for such a
mechanism: Adobe's original (which is implemented in ASV6pr1); the refined
one that grew out of that, which is in the current draft of SVG 1.2; and
your informal one. While I don't really care much about the syntax used, it
seems like the one in the proposal is as good as any other.

Using things like 'flowPara' would help newbies understand what that tag
does. So what's the problem?

Regards-
-Doug

Received on Wednesday, 3 November 2004 18:19:31 UTC