At first glance it is simple. The “T” in HTML is for text; the “G” in SVG is for graphics. We have two distinct worlds.

But then we can look at the real world of shop signs, corporate logos, CD and album covers, packaging, and labels and we find that the artists of the real world have blurred the line between text and graphics in fascinating ways.  In the Arab world, as in the world of Chinese calligraphy writing and art, semantics and geometry become juxtaposed, fused and counter-pointed in ways numerous and hard to categorize.

In this paper we are interested in exploring the relationship between the characters of text and the geometry of their presentation. We’re also interested in discussing how that relationship can affect accessibility in various ways and for various audiences. We’re also interested in identifying some of the ways that SVG as a standard, and that SVG authors as practitioners might improve accessibility for graphically rich text. Ultimately, we’re interested in raising (or perhaps re-raising) the issue of what is the difference between presentation and semantics when it comes to graphics.

As the popularity of incorporating SVG graphics on web page increases, so do the implications for accessibility especially if a broadened definition of accessibility is employed. Our broadened definition of accessibility within the graphical environment includes the visually impaired and the blind, but is expanded to also include the human reader of code and future search engines. Often times, SVG is read and modified by the human coder and thus needs to be readable. This type of readability is analogous to the concept of self documenting code that is encouraged (and oft required by organizations) of programmers creating desktop applications.  The expansion of the accessibility definition to include search engines is a result of recognizing the fact that future search engines may display or index SVG. Consider search engines of the future looking for examples of pentagons found in North African tilings rendered in SVG.  Current HTML-oriented search engines can find the words pentagon, pentagonal, Pentagoni, البنتاغون, պնտագոն, beşbucaq, pentagono, пяцікутніка, পঁচভুজ , петоъгълник and even recognize similarities in their meaning. Might it be unrealistic to think that SVG-aware search engines might one day be able to find and "understand" the similarities between the rollowing geometric instantions of pentagons? We think not, but we think it may be time to begin to envision such a day.

SVG path (five points) -- a convex pentagon <path fill = "#771fab" d="M 257 189 188 285 77 248 77 131 188 94 z" stroke = "black" stroke-width = "1" />	SVG path (five points) -- a convex pentagon <path fill = "#f83379" stroke = "black" d="M 32 55 111 41 157 106 120 145 25 98 z" stroke-width="3"  />	SVG:polygon: Six coordinates; first two redundant <polygon fill = "#f83379" stroke = "black" points="32 55 32 55 111 41 157 106 120 145 25 98"  stroke-width="3"  />	<clipPath id="C"><path d="M 32 55 111 41 157 106 120 145 25 98 z"  /> </clipPath> <image xlink:href="p17.jpg" width="180" clip-path="url(#C)" height="170" />

Background

Obviously, desc and text tags can be used by programmers to address the problem.  However, programmers are notoriously lazy and do not often use these descriptions.  In the United States, the nondiscrimination requirements in Title II of the Americans with Disabilities Act (ADA) applies to state and local government websites. The toolkit [REF1] specifically mentions HTML tags, but does not yet mention SVG tags.

Currently, websites often rely on graphics to convey meanings:  many companies now draw their logos (e.g., HTML5 logo),  graphics for often used symbols (e.g., copyright symbol and non-copyright symbol), text is drawn (word art), and textual effects of a visual nature abound (word art, word puns,  calligrams, shape poems). When graphics are relied on, a visually impaired person may miss the semantics of the page.

Content accessibility guidelines do exist for SVG [REF2]. The content accessibility guidelines according to the W3C recommendation include: provide text equivalents for graphics, do not rely on color alone, use markup and styles sheets properly, clarify natural language usage, and ensure that dynamic content is accessible.  In addition, the W3C recommendations include authoring tool accessibility guidelines and user agent accessibility guidelines.

What SVG can do currently with text:  theory and practice

The SVG 1.1 specification for text [REF3] is approximately 90 pages long (if printed). SVG provides the ability to vary these properties of text:

• Directionality (left to right being the default)
• Inter-word and inter-character spacing
• Vertical Alignment (relative to baseline)
• Decoration (things like boldface, underline and the like)
• Orientation (rotation)
• Squeezing to fit (using textLength and lengthAdjust)
• Relative sizing (using viewBox)
• Aligning to a curve (using textPath)
• Substring styling (using tspan)
• The character set itself (using SVG fonts and WOFF)

Support for these features is not uniform across browsers . There are, indeed, discussions afoot suggesting SVG font support be replaced with the weaker server-side downloadable technology of WOFF.

Additionally, through others of SVG’s features (like masks, clip-paths, filters, gradients, transforms, animation, replication, pattern, and script) , we have the ability to

• Fill typefaces with all manner of texture and pattern
• Rotate, stretch, and skew text
• Distort the shapes of characters (using feDisplacement)
• Fill typefaces with animation
• Animate text moving along paths
• Simulate 3D effects
• Vary shapes of glyphs dynamically

What is currently lacking in SVG1.1 (without extensive scripting or server-side intervention) are the following:

• Flowing text into a rectangle  (as in the HTML <textarea>)
• Glyph to path conversion for access to font geometry
• Flowing lines of text into shapes (as with word poems)
• Allowing text to be “top-aligned” so that characters conform to a top-line rather than a baseline.
• Reshaping glyphs to fit non-rectangular containers.

We will argue that all of the above features are a part of the extant world (both the physical and web-based world) and that for reasons of accessibility (as broadly interpreted) they are useful additions to SVG. In particular there is need for such effect and SVG is the place where most logically they belong

Examples of text departing from standard alignment:

How do people use text in “the wild?”

In beginning work on this subject we sought to gather examples of real world uses of text. We not only kept a lookout for such things as shape distortions and varied geometries, but did some Internet searching for special text effects.

A wide variety of interesting effects were found. (Many can be seen at http://srufaculty.sru.edu/david.dailey/svg/top-align.htm  )

In this section we will present some "found examples" of natural text

Top alignment

SVG has long recognized that text flow (directionality) as well as alignment vary as a function of language. The SVG spec mentions specifically the Indic scripts as varying baseline alignment:

However one need not go to India nor Bangladesh to find examples of varied alignment as the following examples demonstrate.

Book cover from: http://www.glogster.com/media/4/14/98/42/14984230.jpg see also http://www.rangersapprentice.com/	Rush album cover from: http://www.canadiandesignresource.ca/officialgallery/ wp-content/uploads/2008/07/rush1974.jpg	Shop sign (western PA), from: http://c2.ac-images.myspacecdn.com/images02/ 87/m_fe64ca0fef8b45dab7c29db8e31eec89.jpg

If one actually looks for top-aligned English text, it is in fact fairly common.  But this is not an easy effect to accomplish in SVG, even with script. See for example the discussion in the public archives of the SVG Working Group (at http://lists.w3.org/Archives/Public/www-svg/2011Jun/0006.html )

Experiments with making top-aligned text using SVG and JavaScript may be seen at http://granite.sru.edu/~ddailey/svg/tspanmeasure.svg and http://granite.sru.edu/~ddailey/svg/tspanmeasure4.svg

The last attempt is actually successful in Opera, but here are the results of trying to top-align text in different browsers:

Dual curve alignment

In the authors' search for examples in-the-wild of top-aligned text, we found, somewhat to our surprise, that "dual alignment" in which text is aligned simultaneously to be a top and bottom curve is actually more common still. It is a far more common typographical effect than we would have predicted at the beginning of our analysis of such things. Herewith are just some of the many examples:

Google image search for NFL logo	HTML 5 logo: http://www.w3.org/html/logo/	Google image search for Harley-Davidson logo	d
Google image search: Rubber Soul	Album cover -- Herb Alpert's Tijuana Brass	Photoshop effect from http://www.photoshopfiles.com/photoshop/ text_effects/3d_text_effects__499.html
From http://obeyclothing.com/blog/?p=1875	Cooler Master logo: http://www.coolermaster-usa.com/	Text effect: http://wsmithdesign.wordpress.com/ 2010/05/26/silverlight-text-effects/

It is noteworthy that a) the glyphs themselves (and not merely their baselines and font-sizes) conform to the top and bottom curves and b) that these effects are not linear. That is to say the warping of the glyphs is often curvilinear and can not be produced merely by applying a perspective transform to the text.

Shape art: including word poems

Results of a Google image search for "shape poems", as shown below indicate that shape poems tend to be either designed to follow a path (currently possible in SVG) or to flow into a shape. Though the "rules" for how to flow text into complex shapes can be nontrivial, and probably are non-algorithmic, instead relying on the author's sense of  semantics, legibility and good design.


In the following examples, it is clear that even with SVG's current text-on-a-path and the proposed text-flow-into-a-shape, the curvilinearity of glyph reshaping can be quite complex at times.

From http://www.designflavr.com/resources/ 21-Inspirational-Typography-Artworks--from-DeviantArt-i116/	From http://commons.wikimedia.org/wiki/File:Bi%C3%A1ng_%28regular_script%29.svg [earlier from http://www.hiddengarments.cn/index.php/tag/zhaoqing/page/4/ ]

Glyph Distortion

Characters are often, in advertising and other contexts, distorted in interesting ways, that do not merely involve the paths along which they are typeset, as in many of the above examples. Sometimes, for sake of connotative meaning, characters are bloated, extruded or pinched in ways that would not necessarily demand the creation of new fonts. More on this topic will be seen below in our discussion of pictograms.

Source: http://www.superstock.com/stock-photos-images/1850-23262	Source: http://arro-signs.co.uk/3d-letters/chinese-writing/

Glyph decoration:

Source: http://www.amazon.com/Wallmonkeys-Peel-Stick-Wall-Graphic/dp/B005IVQS98/ref=sr_1_23?s=baby-products&ie=UTF8&qid=1317522255&sr=1-23

Typographic Puns (double doubles)

The term "visual pun" often refers to things like this picture of a huge manatee (zepelin shaped) crashing into a tower with the caption "Oh the huge manatee!" Unlike the word poems,
for example, this from http://dbqp.blogspot.com/2007/03/this-is-your-body-this-is-your-blood.html :

These "typographic puns" tend to draw the concept of the word using exactly the letters of the word (no extras),  with a bit of orthographic styling.  The older reader may remember a semi-regular column in Playboy Magazine consisting of a page of typesetting puns.Here are several I remember from my youth:



All but "PROTECT"  viewed at http://granite.sru.edu/~ddailey/svg/embedpun.html in Opera. proTect as viewed in Internet Explorer with Adobe plugin.


Here are some others of the same general ilk that we were able to find on the 'net and that illustrate the very same concept:

From Adam Paxman at http://adampaxman.blogspot.com/2009/ 08/typographic-pun-fun.html	From http://jonahschrogin.blogspot.com/	From http://jamesbrook.wordpress.com/2011/ 01/10/watching-words-move/

A few more may be seen at http://educationdigitalmedia.com/view/8 . Many more (of the ones author Dailey drew in high school) can be see at TypographicPuns1.jpg and TypographicPuns2.jpg. It is interesting to note that of the more than one hundred examples contained in those last two documents, the following was observed:

• only twenty of these effects could be expected to be rendered "easily" (e.g. in HTML)  without necessarily resorting to SVG.
• another sixteen are fairly easily rendered in SVG, and might be renderable in HTML5 using CSS3, but at some cost to accessibility.
• Several require SVG's more advanced methods like clip-paths, filters, gradients, textPaths and the like. A few of these are illustrated here. More of these sorts of things are illustrated later in the paper.
• Many seem to require special glyphs. Of those shown in the above two scans, fully 37 seem to require the creation of special glyphs. This could either be done with WOFF requiring about two hours per font (since WOFF requires an entire font for a glyph), beyond the drawing of the special characters, or using SVG Fonts, at an additional cost of about 30 seconds per glyph. Those that would on first (and quick) analysis seem to fall into this category include {ELONGATE, ARROWHEAD, CENSORED, SHAKY, SQUARE, ROUND, DEFORMED, TRIANGLE, WINDOW, CHEW, GOLF, EYES, PREGNANT, UNRAVEL, DIAMOND, FONETIC, ANTIAIRCRAFT, WAVES, VOLCANO, DENT, LEFT, PENTAGON, VOMIT, ORIENTAL, BALANCE, SPIRAL, ALABAMA, RECTANGLE, SOON, LSD, KNEEL, PRAY, FOLLOW, SKETCH, CUT, COMPUTERIZED, and STOP}
• A few cry out for animation (SWING, BUBBLES, WAVES, BALANCE, ARGUMENTATIVE). SMIL animation would be far preferrable we believe, from an accessibilty perspective since the behavior is located with the object, consistent with the philosophy of both SMIL and SVG. Examples of some of these sorts of effects are shown below.
• Some seem to have no way, currently within SVG to bring about anything close to the desired effect. Recourse to bitmaps with explanatory accessibility tags seems to be the only possibility, but with the loss of several kinds of accessibility as well as scalability. It is these sorts of things, we believe, that will necessitate change to the SVG specification.Things that force us (currently) to use Bitmaps and alt-tags, hence compromising usability)  includ SHAPE, BATTLE, ENTANGLED (COMPACT), LOOPS, LASSO, and because of the inability to work consistently across browers PROTECT. This extreme category is considered more below in our discussion of calligrams.

One of the points to be made from these sorts of examples, is that while the typographic effects are relatively easily brought about if the author is willing to hand-adjust the placement of the special effects (the mask in "ECLIPSE", the Tomato, or the rectangle in Censored) the current mechanisms available for performing many of these operations in script is virtually non-existent in SVG. Some browsers use getBBox, while others prefer getExtentOfChar. None seems to have implemented these things completely consistently with the SVG specification. Furthermore, the ability to rescale the T in PROTECT is present only in the Adobe plugin and is apparently inconsistent with the specification on this matter. <tspan> tags within a <text> have very little control over positioning, other than the obvious tags and are not full partners in the SVG pantheon of tags. Applying transforms to stretch the font does not work except in IE/ASV and the ability to stretch parts of the font and not other will not become possible unless SVG exposes font-geometry to authors in some way.

More importantly for accessibility, without SVG fonts to allow the final O in tomato, or the obscuring rectangle in Censored to be viewed as glyphs, there is no way for a screen reader to determine what the word censored or tomato are unless the author overtly provides those accessibility cues manually -- something authors are notoriously negligent at doing!

One last example, provides a sort of transition between these typographic puns and the more elaborate calligrams, since it provides an example where the shaping of the characters themselves is crucial to the effect:

Calligrams (extreme glyph distorition)

Calligrams are drawings made of glyphs. Here are some examples from Chinese, Arabic and English. In Words as Images,  Matthew Larking , in an article for the Japan Times  (http://search.japantimes.co.jp/cgi-bin/fa20090101a2.html  )  discusses a bit of the rather long, illustrious and international history of "concrete poetry" or  "calligrames" as they were called by Guillaume Apollinaire (1880-1918). For Japanese, Larking explains that "the three Japanese scripts — kanji and the simplified, phonetic hiragana and katakana — lent themselves well to the basic premises of concrete poetry as they are readable from right to left or in reverse, up and down or otherwise scattered over a page as in the chirashigaki calligraphic script popular since the 11th century. But the tradition seems rich and long in Chines and Arabic writing as well.


Copyrighted calligrams (linked in-line here) from http://www.flickr.com/photos/24235169@N04/with/4754291334/  (see also http://www.chinasmack.com/2010/pictures/chinese-character-art.html )


By Hua Jiang for the Beijing International Design Triennial. Source: http://en.bidt.org/designer/413.html



Cherry Blossoms and camels from http://search.japantimes.co.jp/cgi-bin/fa20090101a2.html

Calligraphy of the "Basmala" phrase  bismi-llāhi ar-raħmāni ar-raħīmi بسم الله الرحمن الرحيم in in the form of a pear. From http://en.wikipedia.org/wiki/Calligram .	18th century mirror writing in Ottoman calligraphy. Depicts the phrase 'In the name of God, Most Merciful, Most Gracious' From http://en.wikipedia.org/wiki/Islamic_calligraphy

From http://en.wikipedia.org/wiki/File:Caligrafia_arabe_pajaro.svg with further explanation at http://en.wikipedia.org/wiki/Micrography	Zoomorphic calligram of tiger -- from http://en.wikipedia.org/wiki/File:Shiite_Calligraphy_symbolising_Ali_as_Tiger_of_God.png [previously from Sudanese artist Hassan Musa (from  http://www.sudanartists.org/2artwork/hassanmusad2.gif via http://laurashefler.net/arthistory2010/?page_id=345 ).]

 An animated calligram representing the Al-Jazeera logo, gradually morphed into the word “Al-Jazeera” that is well worth watching is shown here:  http://upload.wikimedia.org/wikipedia/en/b/b7/Al_jazeera_Calligraphy_Animation.gif . It is well worth the view!

Calligram Elephant by Absurdnyka From http://absurdynka.deviantart.com/art/calligram-elephant-91893633	Calligram Ant by ~Inky-la-reve From http://inky-la-reve.deviantart.com/art/Calligram-Honey-Ant-Final-45755836

Text effects in the wild: an inventory.

The above examples (in various categories) all represent experiments with the geometry of text: either with the shape of the glyphs or their alignment relative to one another or both. It is natural to wonder how commonplace are these sorts of effects in behavior of designers, web authors, merchants, and typographers. Accordingly, we performed a quick inventory of textual effects by performing a search in Google Images for "font effects" and "text effects." About two hundred images were examined and about one hundred were selected for closer examination (about half were totally uninteresting, because of duplication, irrelevance, or illegibility.) The following shows some of the images and an intermediate stage in the process of classifying these effects.


Generally, it was observed that the predominant categories of "found objects" were

• simple effects that can easily be done in SVG through the application of colors or gradients
• application of pattern or texture to text -- such as could be done with <pattern> or <clipPath>
• distortions of the shape of text ( like lighting effects,  starbursts, or blurring, as might use feDisplacement or feSpecular) filters.
• drop shadow effects and other quasi-3D effects
• 3D extrusions
• texture effects  (fire, metallic, water and plastic effects seem to be favorites)
• other (hard to tell if these are just unusual fonts or the application of special effects)

The good news for SVG is that most of the standard text and font effects that web authors tend to utilize (almost always through bitmapped images) are relatively easy to accomplish within SVG at present. In the following section is a collection of examples of many of the currently supported effects that can be applied to text in SVG. The more complex shape distortions such as discussed above seem to appear more in the world outside the web, perhaps since few design tools currently support them.

Text effects that are possible and currently supported in SVG

As illustrated above in Figure 1, browser support for text effects is not uniform. In fact as the author of one and a half books on SVG, one of this articles authors can claim that of the major components of SVG (including paths, masks, filters, patterns, animation, and text), text has the least consistency of cross-browser support of any of the other parts of the language. As such, some of the effects shown work only in some browsers. The most consistent and broad ranging support can be seen currently with the Opera browser, and as such, the reader may wish to use that browser for viewing some of these examples.

Here is an example (visible at http://srufaculty.sru.edu/david.dailey/svg/text/textplay.svg ) in which browser support is markedly inconsistent:

Another involving vertical alignment (at http://srufaculty.sru.edu/david.dailey/svg/text/verticalText.svg ) shows similar cross browser problems.

Filling text with gradients or patterns (not clipPaths)

It is quite easy using <text  fill="url(#pattern)" ... > or <text  fill="url(#gradient)" ... > to fill text with either a pattern or a gradient. Here is one simple example of each.

Text filled with a gradient (See http://cs.sru.edu/~ddailey/svg/rainbow0.svg   )	Text filled with a pattern ( see: http://granite.sru.edu/~ddailey/svg/flowers0.svg  )

See also

• http://srufaculty.sru.edu/david.dailey/svg/text/Taxi5.svg
• http://srufaculty.sru.edu/david.dailey/svg/text/slate1.svg
• http://srufaculty.sru.edu/david.dailey/svg/text/colorful1.svg

One thing that SVG can do with such effects that is not so easy to do with bitmapped formats (such as jpg, png, gif, and <canvas>) is to animate these effects by adding a simple lines of declarative code. Here are three examples that illustrate the terseness and simplicity of SVG animation:

Animated effects using gradients or patterns

• http://srufaculty.sru.edu/david.dailey/svg/text/Taxi2.svg
• http://srufaculty.sru.edu/david.dailey/svg/text/flowers.svg
• http://granite.sru.edu/~ddailey/svg/rainbow1.svg

One very important note about these effects in SVG is that the text remains text.

• It is accessible.
• It is selectable by the cursor.
• It is indexable by search engines.

This is not true when we use text within a clipPath to carve a path into an image. It is better, for accessibiity purposes,  to fill text with a pattern containing an image than to carve the image in the shape of the text. Compare these two examples:

Text filled with <pattern> containing <image> ( See http://srufaculty.sru.edu/david.dailey/svg/text/belize.svg )	Image carved by clipPath containing text (see http://srufaculty.sru.edu/david.dailey/svg/text/belize2.svg )

An additional advantage, as shown, is that the text can further be styled (as by a stroke) which is not true when the text remains inside a clipPath.

Drop shadow and reflections

http://srufaculty.sru.edu/david.dailey/svg/text/Pizza1.svg	http://srufaculty.sru.edu/david.dailey/svg/text/colorful3.svg	http://srufaculty.sru.edu/david.dailey/svg/text/colorful4.svg

These are done simply by filling text with either a color or a gradient and then duplicating the initial string, below, with slightly different chroma.

On left: the use of a filter stream to produce a duplicated, blurred and offset copy. http://srufaculty.sru.edu/david.dailey/svg/text/offsetblur2.svg	On right: the use of duplication with transformation. http://srufaculty.sru.edu/david.dailey/svg/text/reflection1.svg

Texture

http://srufaculty.sru.edu/david.dailey/svg/text/burst2.svg	http://srufaculty.sru.edu/david.dailey/svg/text/chrome1.svg	http://srufaculty.sru.edu/david.dailey/svg/text/chrome3.svg
http://srufaculty.sru.edu/david.dailey/svg/text/ripples2.svg	http://srufaculty.sru.edu/david.dailey/svg/text/chrome4.svg	http://srufaculty.sru.edu/david.dailey/svg/text/chrome5.svg
fancy decoration of font using <replicate> http://srufaculty.sru.edu/david.dailey/svg/text/decorative.svg	Dash array assisted by <replicate> http://srufaculty.sru.edu/david.dailey/svg/text/porcupine.svg	http://srufaculty.sru.edu/david.dailey/svg/text/offsetblur6.svg

Distortions and warping

Text crinkled by repeated radialGradient and feDisplacement http://srufaculty.sru.edu/david.dailey/svg/text/crinkles1.svg	http://srufaculty.sru.edu/david.dailey/svg/text/wavy1.svg	Ripples in water: feDisplacement based on feTurbulence http://srufaculty.sru.edu/david.dailey/svg/text/ripples5.svg
http://srufaculty.sru.edu/david.dailey/svg/text/ripples6.svg	Stripes are one repeated radial gradient distored by another http://cs.sru.edu/~ddailey/svg/zebra1.svg

3D Effects

All of these except as noted rely on <replicate>.

feBlur together with feColorMatrix http://srufaculty.sru.edu/david.dailey/svg/text/offsetblur4.svg	http://srufaculty.sru.edu/david.dailey/svg/text/plastic2.svg	http://srufaculty.sru.edu/david.dailey/svg/text/plastic3.svg
http://srufaculty.sru.edu/david.dailey/svg/text/plastic4.svg	http://srufaculty.sru.edu/david.dailey/svg/text/plastic5.svg	http://srufaculty.sru.edu/david.dailey/svg/text/plastic7.svg
http://srufaculty.sru.edu/david.dailey/svg/text/plastic8.svg	http://srufaculty.sru.edu/david.dailey/svg/text/rainbow.svg

Animation

One thing that SVG1.1  does support naturally and easily is animation. Here are some relatively exciting effects, that, alas, displaying bitmapped versions will not do justice for them. You will have to visit the links. For each, though, you are encouraged to see how relatively simple the code is. For almost all of these, because of the use of both animation and feDislacement, you will need to use Opera or Internet Explorer with ASV.

http://srufaculty.sru.edu/david.dailey/svg/text/wavy2.svg	http://srufaculty.sru.edu/david.dailey/svg/text/ripples10.svg	http://srufaculty.sru.edu/david.dailey/svg/text/ripples11.svg
http://srufaculty.sru.edu/david.dailey/svg/text/chrome6.svg	http://srufaculty.sru.edu/david.dailey/svg/text/fire7.svg	http://srufaculty.sru.edu/david.dailey/svg/text/fire8.svg
http://srufaculty.sru.edu/david.dailey/svg/text/bubbles8.svg	http://srufaculty.sru.edu/david.dailey/svg/text/bubblesc.svg

Several of these animated effects can be seen at once at http://srufaculty.sru.edu/david.dailey/svg/text/texteffects2.htm

Pertinent to our study of accessibility, it should be noted that in almost all of the above, the text remains text. This is valuable for accesibility by at least two important audiences: the visually impaired and those searching for things on the web. Title and <desc> tags. On the other hand as text is deformed, as say by bubbles flowing throught it, how best might we convey that effect to either of these audiences? If the software that renders these images allows us to explore the SVG DOM, as many now do, then the hope of understanding what is happening is held open, but it is by no means obvious that either <title> and <desc> nor a DOM-inspector will convey the sorts of visual effects that are a part of what makes a visual pun a pun.

Case studies – what sometimes goes wrong with SVG and text.

Case 1 -- The HTML5 logo

In January 2011, the W3C announced its new logo for HTML5, together with a request for some feedback.  The image is provided under a Creative Commons 3 license allowing derivative artwork, as is seemingly encouraged by the W3C logo FAQ.

At the time, I (Dailey) was struck by one thing (other than a certain aesthetic reaction):

• It contained the letters "H", "T","M", and "L" and a geometric shape resemblng the number five, but none of those glyphs had any fall back content for accessibility; and none of the characters was rendered as text -- everything was paths and polygons.

I wrote to the HTML5 WG  a reaction centered on the above complaint, but including a few other points as well:

1. It seems counterintuitive to write  "HTML" as a series of four paths of the form:
   

   "H"= <path d="M108.382,0h23.077v22.8h21.11V0h23.078v69.044H152.57v-23.12h-21.11v23.12h-23.077V0z"/>
   

2. SVG should be accessible.  Although <desc> and <title> tags might help out in that regard. I prefer text to be text. I continued, somewhat provocatively "surely there must be a way for SVG to render text consistently across user agents!" ( I knew that some browser manufacturers had expressed their dissatisfaction with the W3C's standard here: SVG fonts, and seemed poised not to support the standard, but to offer a weaker one in its place.)
3. Do we really need so many digits of accuracy to draw an H-like shape?  The logo is drawn with three decimal places of accuracy in a viewbox that is defined as 512 x 512. For screen display we're basically talking about 1/1000 of a pixel level resolution, which is a bit of overkill even for a printed version. Is it truly the artist's intent to prescribe millipixel placement, or is this not an artifact of the software used to create the illustration?  Integer arithmetic is much more accessible.
4. The "5" is rendered as a series of four polygons, not even one shape inside a group! In fact, the four polygons are not even contiguous, being separated in the source code by the four paths constituting the "HTML."
   

    <polygon fill="#EBEBEB" points="256,268.217 195.91,268.217 ...etc."/>
    <polygon fill="#EBEBEB" points="256,386.153 255.801,386.206 ...etc."/>
    <path d="M108.382,0h23.077v22.8h21.11V0h23.078v69.044H152.57v-23.12h-21.11v23.12h-23.077V0z"/>
    <path d="M205.994,22.896h-20.316V0h63.72v22.896h-20.325v46.148h-23.078V22.896z"/>
    <path d="M259.511,0h24.063l14.802,24.26L313.163,0h24.072v69.044h-22.982V34.822l-15.877,24.549h-0.397l-15.888-24.549v34.222h-22.58V0z"/>
    <path d="M348.72,0h23.084v46.222h32.453v22.822H348.72V0z"/>
    <polygon fill="#FFFFFF" points="255.843,268.217 255.843,313.627...etc."/>
    <polygon fill="#FFFFFF" points="255.843,176.305 255.843,204.509 ...etc."/>

   
   While the two polygons on the left are meant to be darker than the other two,  that could also be done to a single shape with a mask or, more simply, with a gradient. Combining the four polygons into one really makes more sense. A suggested version 2 of the logo does this with a gradient applied from left to right. The colors should be identical to that in the logo provided, but now it is one shape that has a different fill on its left half than on its right half. It just makes more sense. I might be tempted to add that this polygon is meant to approximate the shape of a 5, so that one might understand that similarity is perceived between the shape and the curvilinear glyph.  It's quite a few hundred less characters, for one thing, and is an improvement to the geometry (I think, since vertical is really vertical now along the midline), and it has a lot fewer extraneous points. Objects which are meant to be perceived as objects should be coded as such.
5. The shape resembles a rectangle that has been creased vertically at its midline. That geometric illusion is not at all visible from the underlying code. Perhaps if the shape were rendered as a rectangle with a non-affine transform applied (to warp the shape and the 5 with it) that would convey the actual semantics of what we see much more accurately than using so many shapes. If something is a distortion of something else, then code it as such.
6. The original  file was crafted using Adobe Illustrator and left much of the residue of that program including a <switch> a <g i:extraneous="self"> and some other things that prevented it from loading in IE/ASV.  This is a common by-product of using Adobe Illustrator or Inkscape.One of the most noticeable problems that anyone who has worked with SVG files from Wikimedia Commons is the irrelevant namespaces introduced by the tool. Jeff Schiller's tool for removing the "cruft" helps with some, but not all of this.The web page  http://commons.wikimedia.org/wiki/User:Quibik/Editing_SVG_files_manually provides some tips on cleansing Inkscape or Illustrator output. Notes: the web-based editor SVG-Edit is very sensitive to these issues, and both Inkscape and Illustrator provide mechanisms for the SVG author to output crisper code for later hand-editing.
   

   ---

   
   Following my e-mail to the  HTML WG, a couple of folks in the SVG WG and I exchanged a few e-mails discussing it, and some cleaning up of the code afterward occured, though the primary accessibility issues remained. I even found a few other issued to take exception to:
   
   

   ---

7. There were coordinates in the original file's path data:  (255.778,512) and (256,480.523) that appeared to draw a vertical line but didn't.  In truth, the first coordinate should really have be (256,512), since these two vertices are supposed to align vertically to preserve the symmetry of the illustration. That 2/9ths of a pixel is really an error from the artist, I think! Rounding to the nearst half pixel. (as is done in version 2) to *enhance* accuracy and reduce file size. Vertical lines should be shown as such.  Removing precision not only reduces file size, but it can actually enhance accuracy.
   
8. Often, in this particular illustration,  if we do round to the nearest half-pixel, we find duplicated adjacent pixels: for example in the first subpath of the "5" 
   
   

    points="256,268.217 195.91,268.217 191.76,221.716 256,221.716 256,176.305 255.843,176.305 ...

   We have (256,176.305) followed directly by (255.843,176.305) -- I think this was a bit of the artist's hand-tremor or else an Illustrator artifact.  The actual polygon, in the grand scheme of adopting polygons dating back at least to Euclid would classify this shape as a decagon, rather than the octagon that it is perceived as, and I would argue was intended by the artist to be. If we were to search in some future search engines for "SVG examples concave octagons used as logos" this particular shape would never been found.  Points that are nearly identical, probably are.

9. On the issue of the classification of the n-gon as n-gons or n+k-gons, there is another issue: There are a lot of nearly or exactly collinear points along the polygons. Why include a series of collinear and ajacent points in the drawing of a polygon? I suppose if we wanted to reflect the fact that the artist waivered while drawing the shape, for subsequent animation of the history of the artist's activity, that could be handy, but I don't think most logos would be interested in glorfying the artist's deliberations here, interesting though they may be! In the version of the logo at http://www.w3.org/html/logo/downloads/HTML5_Badge.svg
   
   the top right stroke of the number 5 is drawn as
   "M255,94 L255,129 255,150 255,150 392,150 392,150 392,150 393,138 396,109 397,94"
   This could more easily be drawn as:
   "M255,94 255,150  392,150 397,94z",
   a quadrilateral rather than a decagon, by eliminating redundant and collinear points. The inclusion of adjacent collinear points in a path or polygon (such as "1,2 2,3 3,4") should be avoided by authors and the creators of tools for authors, unless those points truly have meaning.Otherwise, they distort the meaning.

10. It makes more sense to organize the sub-polygons of the "5" in an order that represents their drawing sequence. By giving each of the regions a different fill pattern (below) you can see they are presented in the order upperleft, lowerleft, lowerright, upperright, rather than a stroking order which would be upperright, upperleft, lowerright, lowerleft. Trying to "feel" the shape of the "5" would be easier if it were rendered in an order matching its shape as stroked.
    

    Current order of appearance of polygons	Improved order of appearance of polygons

11. Note how the left half of the shield and the left half of the 5 are both darker than their mirrors on the right. If we try to reverse engineer the artist's intention, the lighter colors on the right side are meant to harmonize. That is it is as though a brighter light is hitting the right half, or as though the shape has been bent in three space. To do this, and preserve exact color values one would need a filter, since neither opacity (which I've used) nor a mask will do what we want. But, a suggestion version 3 is "similar" in appearance and, arguably, more accurate in semantic intent. Using filters though would not work across all browsers (clearly a show stopper), so I've not tried. The advantage to overlaying a semi-transparent shape over both, is that if the W3C wished to calibrate (as you seem to indicate) the colors of the left with the right, I think this would be an easier way, perhaps to yoke the two. Sometimes the accessibility we wish to provide is to future artists wishing to make derivative work.

12.  (version 4). Is there really no way to get fonts to display consistently across browsers? In version 4 I came pretty close using style="font-family: Arial Black, sans-serif" kerning="3" font-weight="bold" font-size="96px" and it looks pretty good in Opera, FF, Chrome. (Not in IE+ASV and I can't see IE9). I've overlayed the text in transparent red atop the black polygons so the differences can be seen. Clearly the M in HTML is different than any standard fonts I could find. So we may be stuck with polygons. On the other hand wouldn't it make more sense (in the grand scheme of accessibility) to draw the paths as glyphs within a font and then use the font inside a text tag. Then we would *know* what the shapes of the glyphs HTML are supposed to render. Where is this discussion with WOFF versus SVG fonts? every one I have heard speak to the issue says that SVG fonts are infinitely preferrable. It would seem that from the accessibility point-of-view this is absolutely true.

13. As an example of SVG, the logo really ought to be drawn using coordinates that scale to the size of the screen. Changing the
    

    <svg version="1.1" xmlns="http://www.w3.org/2000/svg" width="512px" 
    height="512px" viewBox="0 0 512 512">

    
    to
    

    <svg version="1.1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512">

    
    as seen at http://cs.sru.edu/~ddailey/svg/HTML5logo1a.svg would help here, but there is a bigger issue. It is somewhat difficult to scale fonts relative to the screen currently within SVG. We may define a viewBox (which is needed to allow paths to be drawn in relative coordinate spaces) and from this, our fonts will also scale. But without script the only control we have over the actual rendered width of a string of text is through the use of the textLength=n and lengthAdjust="spacingAndGlyphs". The two problems here are that not all browsers support this, and if one does use it then one sacrifices kerning! Advice for authors: consider how important are aspect ratio and scaling to differently sized and shaped devices. Advice for implementors: improve support for text styling, decoration, alignment. The spec writers too have some responsibility here since the spec is not always clear on how alignment, glyph measuring, kerning, and styling are supposed to be handled. (see the earlier illustration of top aligned text and a the one of decorated text).
14. If we agree to simplify the "5" to a single path (rather than five disconnected ones) then should we consider the differences in accessibility that result from drawing its outline and then filling it versus thinking of it merely as a stroke? Setting the miter of a stroke, though is probably not  flexible enough though to accomodate the artist's intention to have the shape of the "5" parallel the shape of the badge. A bit of play with these concepts by backtracing a part of the stroke can be seen at http://cs.sru.edu/~ddailey/svg/HTML5logo1c.svg . stroke-linejoin="miter"  and stroke-miterlimit=number are simply not flexible enough to allow the sorts of shaping of the extent of stroke at the  given vertex of a path. If the angle  of the end points of a stroke could be adjusted

Now I should point out, for sake of clarity, that the HTML5 logo is not at all unusual in the sorts of accessibility issues it raises. But the questions of accessibility are rather different. It is not a question of which words to use in a alt attribute to describe an image, though that is the easy part of it. It is a question of how we might provide access to the geometry, the styling, the reshaping, and the semantic gist of the image through the markup itself. In fact, most SVG "found" on the web is far less comprehensible from the point of view of recognizing where multiple objects become one, where clip-Paths provide semantics (as when the shape of text is used to clip picture), when line segments are really vertical, n-gons are really n-k-gons, and when differences in hue are actually shadows thrown by an unseen shape (even though the markup suggests otherwise) .

Suppose, for purposes of accessibility, we wished to replace the paths in the HTML5 logo [1], by actual characters in a font.  We not only  want the text to be accessible to screen readers but to selection by the cursor, indexing by search agents, and restyling through menus of assistive fonts that address various different accessibility needs (e.g.,  Braille, TexturePath(future) or the like).

While <desc> and <title> might tell someone what the letters are, they don’t help with most of these purposes.

The two natural solutions would be SVG fonts and WOFF both of which are standards supported to some extent (though only SVG fonts are currently a recommendation I think) by the W3C, but neither of which, yet has univeral support by SVG viewers for both mobile and browser environments.

A WOFF solution (using a WOFF font for the characters of the string "HTML5" can be seen at this location http://cs.sru.edu/~ddailey/svg/HTML5logo5.svg . It renders almost the same as the original W3C version (in all browsers but Safari -- see comparisons of the original and the WOFF version at http://cs.sru.edu/~ddailey/svg/HTML5logo4.svg as seen across browsers at http://cs.sru.edu/~ddailey/svg/HTML5WOFF.png )but is arguably much more accessible. To begin with, its characters can be selected by dragging the mouse over them (in most browsers)

Case 2 -- the uncopyrighted symbol

Which of these: http://granite.sru.edu/~ddailey/svg/pd5.svg is better, in terms of accessibility versus appearance?

1. The first (red) has four concentric circles and three rectangles. Its shapes are filled with colors defined by hex codes. The "slash" is actually two rectangles, one white and one red, with the white one present apparently, to separate the slash from the shape underneath it which is actually two concentric circles, one red with a smaller white one inside. The outer red circle is interrupted by an "invisible" white rectangle (visible only because it interrupts the red circle).This is the Wikipedia version . It has gone through so many iterations that Wikipedia has frozen it to prevent further tampering.
2. The second (green) has one circle, one line and the letter "c" (which is more "as we view it"). The problem with the second is that despite it making some good sense semantically, it may render differently in different browsers *because of the letter c*. All five environments tested show it almost identically, but is that sufficient? Unless we send our own font definition, there seems to be no agreement within the general community of web standards that any font family should display the same way!  Note that the ends of the C are not parallel in #2 as they are in the Wikipedia version.
3. (purple) -- There is a unicode character (&#2298) that consists of a circle with a line through it. This composition is drawn as follows:
   <text x="35" y="130" fill="inherit" stroke="inherit" stroke-width="2"
   font-size="250px"
   font-weight="bold" font-family="Arial, Times, Times New Roman, Trebuchet
   MS">&#2298;<title>Unicode symbol for circle with diagonal
   line</title></text>
   The author tried to find a standard font that supported it, but except for the Adobe viewer (which seems to understand all fonts ever created or imagined) no browser other than ASV actually seems understands the character even though it may be installed in the system fonts generally available to many applications. It does, however beg the question: are we negating copyright, or negating  "C" ? Since there is a negation symbol, does it not stand to reason to use it?
4. (blue)From the desc tag associated with this drawing: "This symbol consists of the copyright symbol, &#169; with a line through it. The copyright symbol is represented by the letter C inside a circle. A circle with a line through it generally means "do not participate in  whatever action is depicted inside the circle".
   So, a line over the character would, because it contains a circle, imply negation of the claim of copyright.
5. (orange) In this one, instead of drawing a "line" we have placed the text "/" meaning "slash" over top of the C.
6. (black). Here we take the copyright symbol and surround it by the "don't" symbol. Two circles, but no problem of "scope of negation".
   

Questions:

1. Do we really want our uncopyright symbol to render identically across browers? A related question is: do we want it to, as do its ancestors, the copyright symbol,  and the circle-negation , to adjust to the typeface used in the same context. Wikipedia's uses rarely involve using the symbol in the midst of running text, in part, because other symbols relating to intellectual property (R, C, TM) have a longer tradition of usage. The origins of the need to uncopyright things, probably began with the Berne copyright act, when suddenly authors found themselves owning copyrights they did not necessarily want.
2. Do we want our symbol to be able to inherit stylistic attributes of the surrounding text (like serifs, italics and font-weight)?
3. Should the endpoints of the C be parallel as shown in Wikipedia? Probably not. The symbol historically originates with US law and is defined as the letter C with a circle around it.. The C in this version is 
   created by
   <text x="40" y="150" fill="inherit" font-size="200px" transform="translate(-8,0) scale(1.08,1)"
   font-weight="bold" font-family="sans-serif">c</text>
   The translation and scaling are provided to make the c glyph "as parallel as possible" to the surrounding circle, though this is clearly a bit quixotic given the nature of default font substitutions for different browsers and end-users' system fonts (which vary in a statistically significant user-by-browser interaction).
4. Since there already exists a Unicode character for the copyright symbol copyright, is that how we should begin in our definition of not copyrighted.
5. Are we negating copyright, or negating  "C" ?
6. Do we really mean "not copyrighted" or do we mean "don't you dare copyright this?"

Not-copyright: conclusions:

The standard and familiar symbol for "public domain" or "uncopyrighted" is a bit of a visual pun. The two circles, one representing the circle from the copyright symbol and the other representing the circle from the "don't" symbol, have been somewhat whimsically merged into a single symbol. This leads to ambiguity in the interpretation of the symbol. Do we mean "do not" copyright (as in copyright is prohibited), or the weaker version "not copyrighted." Or do we mean that the visual redundancy of the two concentric circles (one part of "don't and the other part of "copyrighted") can like morphophemic conditioning in Navajo, be syntactically transformed into a single spatial repetition of the same glyph? If this is the case, it speaks to a rather rich spatial morphophonemic theory, which in a very real sense, we would have predicted from the beginning!

The author's disagreement with the existing Wikipedia symbol has several components: the use of two circles to describe one is semantically inaccurate; the use of a matrix transform on a rectangle to describe what is more semantically a slash (or perhaps a line). Rotation about the center of the circle is really what is happening rather than a matrix transform. And I'd have to disagree about the semantics of the "c" not meaning copyright. The copyright symbol originated, we believe, in US law and is defined there as a c within a circle (See US Code Title 17 section 401) . We do not believe that section of the code has changed in the past 100 years though the required use of the symbol was dropped in the US when the Berne treaty was adopted. The symbol is in frequent use througout Wikipedia, however, has come to emphasize the interplay between the shape of the circle and the shape of the glyph inside it. Interestingly, when the Unicode version of the copyright symbol is set in a serif font, the close geometric interplay between the circle and the c is lost. Running a slash through a font that may appear in unpredictable locations is likely to cause visual confusion, since relevant visual cues may be occluded by the slash. 

I think that I would probably be happiest if one were to define a glyph (SVG allows us to do that) corresponding to and used for � and then use a properly defined geometry rather like what the Wikimedia symbols has done. There is still the nagging issue that the outermost circle means two things: part of the copyright symbol and part of the negation.

The font-designers I know advocate building separate italics and boldface versions of each glyph rather than relying on the browsers font-layout engine to apply its slant algorithms to a given glyph to produce italics, but I don't know how hand-made glyphs respond to font-styles since so few browsers actually support SVG fonts yet. (Only IE+ASV does it completely, though Opera handles paths). Clearly if the symbol is only geometry then it would be unaffected by the surround. It seems as though the Wikimedia symbol is being thought of as a symbol for visual works rather than as a mark of attribution (like copyright) that would have accompanying text: like copyright 2010 by so-and-so. What the equivalent utterance for PD works would be is slightly unclear : uncopyrighted 2010 by so-and-so?? In one of my many digressions on copyright law, I talk about inheritable uncopyrightability as in gnu licenses, and it seems like the mark in use in Wikimedia bears possible ambiguities of meaning simply "not copyrighted" or, more strongly: "never to be used as part of a copyrighted work". Hence the flirtation with the semantics of "don't" borrowed from the use of the circle with a line through it!

Here's another example that I did replace at Wikimedia. I took the original from 5kb down to 895 bytes, and made the semantics of the paths a lot closer to what is really meant than the rather lengthy series of bezier cubics used to make a similar shape. Discussion and history may be seen at http://commons.wikimedia.org/wiki/File:Publicdomain.svg 

Case studies: conclusions

The topic borders on some fairly fundamental issues of SVG semantics.  In geometry,  do we separate presentation from semantics and if so, how? Consider the two halves of the pseudo-glyph 5 in the HTML5 logo. The semantics *is* a 5, but what form of presentation language would style it into four differently colored paths? That would require, I think, a more powerful theory of presentation than CSS was intended to be. Separating the x,y coordinates from everything else, would be an obvious course of action, but then what of feDisplacement or transform which serve as modifiers to the geometry.

Once we have understood a complex group of paths (through whatever assistive technology is available to help us understand it) , then is a reuse of that group, via a transform, not intrinsically more understandable than recasting all the objects with new sets of coordinates? <use> is a powerful tool for the author who edits by hand. In many drawing programs, though, it is easier to duplicate and re-set coordinates for sake of not having to carry chains of transforms. For the intelligent screen reader, might it not be simpler to say "two copies of the same thing, one reflected about its left edge" than to re-read a second list of coordinates? By the same token, is not a <replicate> intrinsically more understandable than a zillion <uses> differing from one another by infinitessimal amounts on plenitudes of variables?  Accessbility, also means, cognitive accessibility and all the more so when visual impairment may be present.

In SVG as we apply modifiers of objects: gradients,  filters,  transforms,  patterns, clip-paths and  masks, then thinking of geometry as somehow distinguishable from presentation is of limited utility. Modifiers modify meaning, and in graphics, appearance is meaning. Texture is just as tactile as shape if we render our shapes in another modality and is not, as in HTML, some sort of presentational attribute left to the responsibility of the public relations department on the 23rd floor of the building.

The problem at hand is given markup that represents some semantics involving meaningful, alphabetic characters, how best to render that appearance in SVG given an infinite number of ways that superficial are bitwise identical? There are many aspects of the underlying code associated with a shape that might ultimately affect accessibility, depending on the audience we might wish to reach. While a screen reader which might attempt to convey aspects of the geometry of a shape to someone, a square might be drawn as a rect, a path, a polygon or a square unicode character. They might all look the same, but have different underlying "meaning" in the sense of geometric reasoning.

Problems caused by transformations

Often times, graphics are used to make text appear exciting or flashy creating accessibility issues for the viewer. In such instances the path tag is employed by both SVG generators and human authors  instead of the text tag since the text tag is quite limiting.  Even if the author drew the graphics with geometric shapes, the problem still exists; to the human reader and the automated screen reader, the SVG code is unintelligible.

Another problem that often occurs in SVG code is the use of decimal values.  The geometric values of x and y coordinates could appear as (98.734, 30.123002) and a second point in the path could be (27.63, 30.123). Did the author mean to make a vertical line or not? At what magnification level would the line no longer be straight? Magnification is a necessary tool for the visually impaired.  In addition, at what decimal precision does round-off take place when transformations are applied to the paths or geometric shapes.

Sophisticated screen reading software for processing svg to describe the graphics specified by the code could be developed.  The developer would need to modify coordinates used by some svg programmers when decimal places are used. For example the x, y pairs (3.0, 5.112001) and (12, 5.112) would appear as a line on a monitor, however, the software developer would need to modify the y coordinate in order to determine that the pair of points is a horizontal line.

The SVG 1.1 specification for text [REF3] does not mandate the use of the desc, title, and text tags The transformations in the svg specifications describe the matrix operations at a detailed enough level so that the various svg interpreters (opera, firefox, and IE) all perform the operations similarly, but not identically.

Experimentation on Firefox 6.0, Opera 11.5, and IE 9 was performed to determine how each browser handled transformations.  For each browser, a simple rectangle was rotated 50 times at 45 degrees and the coordinates of its BBox were tracked.  Firefox use 8 places of precision, whereas Opera and IE each use 14 decimal places. Of the three browsers, firefox is the most internally stable; after a complete 360 degree rotation(8 transformations at 45 degrees), all 8 decimal places are the same.  Curiously, Opera and IE (both using 14 decimal places) require two complete rotations (720 degrees) before their 14 decimal places are the same as 0 degrees.
The table below shows the x values for a complete rotation of a recatangle:

Degrees	Firefox 6.0	Opera 11.5	IE 9
0'	197.02343750	197.02305603027344	197.0230712890625
45'	224.94921875	224.9499969482422	224.9499969482422
90'	196.81250000	196.81089782714844	196.81092834472656
135'	199.80078125	199.79998779296875	199.8000030517578
180'	196.80859375	196.8109130859375	196.8109130859375
225'	224.94921875	224.95001220703125	224.94998168945312
270'	197.02343750	197.0230712890625	197.02305603027344
315'	200.10156250	200.10000610351562	200.10000610351562
360'	197.02343750	197.0231170654297	197.0230712890625

 When examining IE and Opera’s values, if only four decimal places are used, then 0 degrees is the same as 360 and 720 degrees (and for all 8 intermediate rotations). Moreover, when looking across browsers, the four decimal places for the first 23 rotations for both IE and Opera are identical. 

At three decimal places, IE and Opera are identical for all 50 rotations . However, they differ from firefox in the 3rd decimal place. All three browser with 2 decimal places of significance are stable and identical.

Things SVG can't yet do

Many relatively small issues of SVG implementation by browsers have been discussed thus far. The primary limitations other than inconsistencies of browser support seem to be in areas of non-standard alignment and textual warping. These effects are commonplace in the real world but are simply not to be found in the SVG specification (or CSS or HTML for that matter) at present.  We believe they are important for art, science and geography and encourage their adoption in SVG 2.0.

The examples of calligrams, shape poems, 3D effects, glyph warping, and dual-curve alignment are the main areas of concern.

Israel Eisenberg's response to this topic on the www-svg@w3.org mailing list this summer and particularly his examples at http://owl3d.com/svg/tests/boundText/ were highly instructive.

Dual curve alignment (from http://owl3d.com/svg/tests/boundText/2curves.svg )	Stretching a glyph (animation) (from http://owl3d.com/svg/tests/boundText/2curves_B.svg)	Curvilinear Typesetting in SVG (from http://owl3d.com/svg/tests/boundText/circle_text_ar6.svg)

The notion that the <textPath> could be defined so that text flows, is aligned to and warps according to two curves rather than one, was the premise of the question that stimulated at least some of this discussion. Ultimately, the question arose from experiments with top-aligned and dual-curve alignment seen earlier in this paper, posted variously to svg-developers during the first half of this year.

One additional category of typestting that sort of spans the categories of text flowing into a shape and issues of text measurement has to do with legibility (another form of accessibility) and text flow. In svg-developers Dailey posed the following question.

The concept of "how best" to write something got me wondering about the following. Using an alphabet or a syllabary (like most of the languages of the world excepting Chinese, Japanese, Mayan, and a few hundred others) how much "space" does it take to convey our meaning.* Here's the question: if we relax the rules of English orthography just a bit, so that instead of writing from left to write, we write from left to right, or downward, or inward (by allowing glyphs to be "inside" one another) , can we write legibly in less space? http://granite.sru.edu/~ddailey/svg/canonical.svg This link shows a way of packing letters into a space under the relaxed rules of right-or-down-or-inside. If we confine legibility by some empirically defined threshold on the minimum size of a glyph, then if we allow physics to constrain the two dimensional placement of our glyphs, subject to rotation scaling and translation, to pack tightly, then can we find ways of expressing English (or another language using some alphabet) using less space than by writing simply unidirectionally?

Wrap-up

We have seen lots of examples where artists, illustrators and semanticians have had to resort to bitmapped graphics or to "inaccessible" markup in order to convey the intended meaning of text combined with geometry. It is an area of long-standing fascination to many cultures that use completely different styles of writing.

The question of what it means for graphics to be accessible is an interesting one. In the context of HTextML the concept of how to ensure accessibility has generally been asked about how to provide accessibilty to nonText (typically graphics). Hence, it is fitting, to some extent, that in the context of SVGraphics, the issue of ensuring accessibility to Text objects becomes an issue. The degree of inconsistency in support for parts of SVG 1.1 is rather remarkable. That the "acid tests" created by representatives of the implementers' community have failed to examine more subtle aspects of SVG support is unfortunate. It is encouraging that CSS3 text handling [REF4] brings greater flexibility to text handling for both HTML and SVG, but the separation of appearance and meaning makes less sense when the meaning is geometry as with SVG.  The place to handle uncommon geometric distortions of text, as with the many effects shown in this paper seems to be SVG rather than CSS, unless CSS wishes to take on text-path, glyph definition, glyph distortion,  dual curve alignment, flow into shapes and other various extensions that would seem to fit more comfortably in the SVG model, where DOM and complex modifiers (pattern, gradient, filter, clipPath, mask, animate, use, textPath, and transform) already exist.

Several recommendations follow rather directly from our analysis:

• SVG programmers should thoroughly document their code for accessibility purposes by using desc and title tags, even though the use of these tags neither tells the whole story nor is "enforceable."
• Artists will continue to create these "Graphico-Textual" effects and if there is no mechanism to do it in SVG, then it will continue to be done using bitmapped graphics, do the detriment of accessibility to many audiences.
• The SVG community should advocate for the adoption of more advanced text handling methods within the standard, else the proliferation of inaccessible logos, signs, puns, and diagrams will continue.
  
• Tools that generate SVG could prompt the user for the appropriate accessibility data and generate tags automatically.
• SVG should improve support for text styling, decoration, and alignment
• SVG should provide a glyphToPath() method that exposes glyph geometry
• getExtentOfChar should provide a bounding box of each glyph separately rather than as implemented in most browsers and be given full status: namely the ability to apply transforms, clipPaths, filters, etc. 
• text within clipPaths as applied to other content should be selectable 
• SVG fonts provide better accessibility than WOFF since both the geometry and the message are available to the audience. 
• Authors should use SVG fonts or WOFF fonts to draw paths as glyphs thereby allowing the use of the text tag.
• Removing precision not only reduces file size, but it can actually enhance accuracy.  Unless needed for being able to zoom in on high resolution maps or the like, the mathematical precision should be kept to levels that are, in fact, meaningful. Otherwise geometric meaning is obfuscated.
• Objects which are meant to be perceived as objects should be coded as such, even though the appearance may be the same.
• If something is a distortion of something else, then code it as such -- it makes more sense.
• Points that are nearly identical, probably are. Drawing programs should resist the temptation to interpret an artist's hand flutter as meaningful. 
• The inclusion of adjacent collinear points in a path or polygon (such as "1,2 2,3 3,4") should be avoided by authors and the creators of tools for authors, unless those points truly have meaning.Otherwise, they distort the meaning.
• Sometimes the accessibility we wish to provide is to future artists wishing to make derivative work.
  

Also it is suggested that svg authors limit the number of decimal places they use when creating x,y values to two decimal places. Two decimal places permit a magnification of 100 before the svg object could appear differently.  Given current screen hardware resolution, two decimal places is reasonable. Of course, interpreters could get remove unnecessary decimal places (or some level of precision keyed by viewBox) Likewise, tools that generate SVG should look for hand tremors - points that are nearly identical, probably are.

While the W3C seems to have backpeddaled to some extent (allowing the debate over retracting the SVG fonts recommendation in favor of the weaker WOFF support to reach ) on its support for text within the mobile and web environments, it is clear that support for the Graphico-Textual world must be addressed. It should happen soon before we have another rash of browser wars with some two of (FF, Opera, Apple, Google, and Microsoft) squaring off agains the other three in a bid for domination of the Graphico-Textual world.

Overall conclusions include:

• At least in the arena of SVG, the separation of form, semantics and behavior as CSS, markup and script, is appealing, but in some cases, makes very little sense.
• Enhancing accessibility in the context of SVG is a quite different proposition than in HTML (since graphics are different than text)
• The communities that need this access are diverse. We include here the visually impaired individual, the student of geometry, the visual resources lbrarian (using search engines to look for shapes and effects), the translator into another language and the artist who wishes to animate another's open source contributions.
  
• Tools for drawing should support high levels of interactivity between the drawing and its code. And interface that allows simultatneous viewing and editing of both is encouraged.
  
• What is it that makes the geometry of a written word special? Many of the effects considered here fall into the category of visual puns. The question of how to convey a visual pun is complex.  We feel that the realm is large, thorny and at the same time fascinating. 
• The questions of how meaning and geometry relate are non-trivial and we should not expect the same solutions that have been tried within the HTML world to fit these complex issues.
• SVG holds more promise for addressing both the typesetting urges for geometric expression than other technologies and the public's need to access both the geometry and the text of messages is high.