- From: Doug Schepers <doug@schepers.cc>
- Date: Wed, 3 Nov 2004 13:19:26 -0500
- To: "'Ian Hickson'" <ian@hixie.ch>, "'Robin Berjon'" <robin.berjon@expway.fr>
- Cc: 'Håkon Wium Lie' <howcome@opera.com>, <www-svg@w3.org>
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