RE: [Bug 12558] New: Support HTML's full set of character entities in SVG

I do not understand much of this discussion, but I'd like to. The related issues of character support, multi-language support (as through Unicode) and font consistency across browsers is something that, in teaching some recent classes to very multilingual audiences, opened my eyes to a plethora of inconsistencies in current browsers. How does one get 
Sigma( Xi - X [style="text-decoration: overline"])^^2 written as a proper formula for variance (with Greek letter and exponent) or eñe or è or Ä or '┐╕╣║' written in font-family serif in a way that will display consistently across browsers in SVG? Is there a simple "how-to" document somewhere that addresses these issues? My own experiments and those of my multi-lingual students have been hugely unsatisfying. Support for fonts that align to lines other than the baseline (like Indic), also seems quite spotty.

On a related topic, for explaining to others, it would be nice if I understood: what is the current status of SVG fonts? Has WOFF eroded all resistance? I sort of got the sense from something I read recently, that SVG fonts are not dead, but I wasn't quite sure since the WOFF-buoy seems to be ubiquitous, now, in W3C harbors.

In addition to the use case of client-side font design (that I am quite interested in), there is also the ability to squeeze text into shapes -- I use the word 'squeeze' rather than 'flow', as flowing refers more to the flow of paragraphs into non-rectangular containers. I'm talking about a very prevalent use case in advertising, logos and word art, of having the shape of the glyphs of a word, phrase or trademark conform to a non-linear baseline as well as a non-linear (and non-parallel) top-line, such as some of the examples explored here: http://srufaculty.sru.edu/david.dailey/svg/top-align.htm and http://srufaculty.sru.edu/david.dailey/svg/fontplay.htm . The NFL logo provides a simple example of what I mean. If we had access to the glyphs as paths, then we could at least, through script, squeeze glyphs into a new shape, using some simple physics. The 5 in the HTML5 logo is another example: no font-face conforms to that shape, but one could define a very 'tight' deformation that would compel the standard curvilinear '5' to  adhere completely to its polygonal container. A looser deformation might still retain the curvilinearity.

Accessibility concerns (of being able to render logos as text rather than as paths) would seem to recommend SVG fonts over WOFF. Other thoughts? I appreciate

Cheers
David

-----Original Message-----
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of Dr. Olaf Hoffmann
Sent: Wednesday, April 27, 2011 4:42 AM
To: www-svg@w3.org
Subject: Re: [Bug 12558] New: Support HTML's full set of character entities in SVG

For example Opera does not want to interprete HTML entities for
all versions of XHTML, therefore unfortunately the use of entities
in no reliable way even for XHTML. In the last century it was a good
method to be independent from the problem, that a server may
send wrong encoding information about a document, because it
does not analyse the encoding information in the document for
XML and HTML. 
To provide an extension defining the entities for every XML document
works pretty well, if needed. But of course if one starts to add the
complete HTML list of entities, documents get pretty large.
Therefore it is typically better to paste and copy such chararacters
not directly available on the keyboard, because typically one has
not the ability to keep in mind all unicode numbers to use them
instead. This is not very friendly for authors, but there seems to
be currently no alternative.
And because SVG tiny 1.2 for example has no DTD anymore -
and future versions of SVG may have no either, it can be difficult
to define this - and even if this happens, this does not mean, that
viewers care about such definitions, as can be seen with the
XHTML DTDs and Opera for some versions of XHTML.

Olaf

Received on Wednesday, 27 April 2011 12:11:26 UTC