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? 

Best approach will be typically to use utf-8 encoding, because this
contains most of these things.
If you find the letter, symbol, character on your keyboard or if you can 
copy it, no further efforts are necessary from the markup point of view.
If you can't do this, you still can use the unicode numbers in the
same way as you used entities in HTML, for example:

<text>&#931;(&#926; - <tspan 
text-decoration="overline">X</tspan>)&#178;</text>

Not sure, if there is a unicode for an overline or how &#8254;
works (is the same as HTML &oline;) - one has to look into
the unicode specification, if this is intended to create something like
a ligature.

Fortunately I have a german keyboard, therefore üöäÜÖÄß, èéêñ etc
are no problem, for others I have to look into a unicode table or a
tool that provides the same information.
Because this is laborious, I prefer the entities defined in HTML as
well compared to unicode numbers, but often even in XHTML only
the numbers work for viewers, the same for MathML.

Of course, at this point you just have identified the proper characters.
This does not mean, that a glyph is available for this character in a font 
in the viewer. To ensure this, in doubt you have to provide your own fonts,
that have glyphs for all the characters you need.
(SVG fonts are not optional for 1.1 full or 1.2 tiny, therefore currently
the best choice, however, because many viewers have bugs or
gaps, it might be a good idea to provide the fonts in other formats
as well).


> Is there a simple "how-to" document somewhere that 
> addresses these issues? 

I would be interested too in such a document, that provides a more
comfortable and intuitive approach to find the right characters and 
a reliable simple way to provide proper glyphs as well ...

> 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.
>

Well, viewers have many bugs and gaps ...


> On a related topic, for explaining to others, it would be nice if I
> understood: what is the current status of SVG fonts? 

It is still part of SVG 1.1 and not optional, therefore I think nothing
has changed in the past 10 years. I think, the current 1.1.2 draft
only removed minor issues or improved the defintion of some
issues, only minor changes.
On the other hand - up to now, there is still no complete implementation
of SVG 1.1 available, as far as I know, and what is implemented has
often bugs and gaps as usual ;o)

> Has WOFF eroded all resistance? 

I think, it is yet another font format, that does not cover everything you
will need for the specific needs for SVG documents, however if widely
interpreted by many viewers, this can be quite useful for normal text
decoration in (X)HTML for example or larger amounts of text without 
advanced requirements in elements like textArea.

There was already a discussion about this in this list - clearly WOFF does
not cover many requirements for a font format helpful and simple for
SVG authors.
Well, still some do not realise, that WOFF cannot be a replacement
for SVG fonts - or if it is extended to provide the same functionality,
it will be more an extended version of SVG fonts than of WOFF ;o)

>
> 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
>

For accessibility it is not necessarily a difference between SVG fonts and
WOFF, for both you still note the characters as unicode, only the glyphs
are provided in a format specific way, this means, the content information,
the character itself is accessible, the related glyphs are path data or for
SVG fonts in general (animated) graphical shape or something even more
complex like a foreignObject.
The main problem occurs, if WOFF does not cover the needs of an author
or an author knows already SVG and does not want to care or to learn to
use yet another format. If there are too many viewers having a bug, not 
interpreting SVG fonts and only WOFF, such authors will start to provide
simply arbitrary SVG paths directly instead of SVG fonts or WOFF.
Obviously arbitrary path data are not accessible, this is the main problem,
if implementors interprete WOFF instead of SVG fonts and not just 
WOFF as an optional other font format additionally to SVG fonts.
Ignoring SVG fonts can cause accessibility problems, not the additional
interpretation of WOFF, what can be pretty useful as well for many
use cases (not necessarily in SVG documents, more for (X)HTML+CSS).

Olaf

Received on Wednesday, 27 April 2011 13:29:47 UTC