SVG Font criticism

Dear SVG working group,

   I just had the chance to review Chapter 13 of the Aug 12 SVG spec
(Fonts). I am concerned that a completely new and somewhat rough-edged
new capability was slipped into the spec for its "Last Call." My
understanding of Last Call is that it was a time period to consolidate
technical issues for which there had already been discussion. This is
obviously not the case with the font changes. I believe these problems
derive directly from the W3C's policy of holding working group
discussions confidential.

   Now with the obligatory W3C process bashing out of the way, I'll go
on to a technical criticism.

   I think specifying a font directly in the SVG file is a good thing.
Obviously, fonts specified in this way are far more likely to work
correctly across different platforms. However, I have a number of
criticisms of the font format itself.

   First and foremost, the lack of hinting represents a significant
step backwards in functionality, especially compared to existing
unencumbered solutions. I also would like to call attention to this
language in the spec:

   SVG fonts contain unhinted font outlines. Because of this, on many
   implementations there will be limitations regarding the quality and
   legibility of text in small font sizes. For increased quality and
   legibility in small font sizes, content creators may want to use an
   alternate font technology, such as fonts that ship with operating
   systems or an alternate web font format.

   I apologize for using technical language, but this is sheer
bullshit. Using an "alternate font technology" brings up the same
conformance issues as earlier drafts, and invites an interoperability
nightmare. More honest language for this draft would be:

   SVG fonts contain unhinted font outlines. Because of this, on many
   implementations there will be limitations regarding the quality and
   legibility of text in small font sizes. There is no way to create
   conformant SVG files using higher quality hinted fonts. For
   increased quality and legibility in small font sizes, content
   creators may want to use an alternate format other than SVG.

   This kind of thing really calls into question for me the working
group's goals. Is the goal to completely specify a file format for
best-practice quality graphics, or to provide a half-working kludge
that really requires proprietary enhancements to deliver its full
potential?

   The Adobe charstring format dates back to 1985, and has acquired a
large body of knowledge and font design tools. Over its evolution, it
has acquired the features needed for rendering a wide range of
scripts, including high quality CJK font rendering. In addition, there
are no known intellectual property constraints, and many excellent
free tools exist to parse, generate, and manipulate charstrings.

   It is most ironic that a free software developer is pushing Adobe
technology on a specification, but that is exactly what I'm doing
here. The <glyph> element should be allowed to include hex or base64
encoded type2 charstring data (the difference is basically a 50%
difference in uncompressed file size, either way probably much more
compact than svg path syntax).

   My other major criticisms have to do with i18n. Specifying glyphs
in terms of unicode sequences and using longest-match semantics for
choosing ligatures makes sense, but is obviously inadequate for
complex scripts. This is not to say that complex scripts are
impossible, just that they will generally be rendered a character at a
time using the altglyph property, explicit x,y positioning, etc. This
criticism also applies to placement of diacritical marks.

   The major consequence of this is that in many scripts, SVG text
will basically be uneditable, as well as hugely expanded in file size.

   Incidentally, "internationalization issues need to be addressed"
doesn't exactly sound like Last Call language to me either.

   I think "isolated" is more usual terminology than "standard" as a
value for the "arabic" attribute. Calling this attribute "arabic"
may not be wise - Syriac (in the Unicode pipeline) has exactly the
same structure of contextual forms.

   I do not understand the value in tagging the locale for glyphs in
the han range. To mix different CJK languages, it makes the most sense
(to me) to simply use different fonts, subsetted as necessary.
Similar issues exist for the Arabic and Cyrillic locale variations,
but only the "han" attribute exists.

   The exact interpretations of some tags are quite badly
underspecified. One can easily imagine that the "arabic" contextual
forms are to be interpreted according to the Unicode rules, but
nowhere is this explicitly stated. Do other sets of Unicode rules also
apply, for reordering in complex scripts, for example? For composition
of Korean Hangul? This needs to be very explicitly stated.

   Unicodes should be specified in hex, not decimal, as this is the
standard for interchange, and because Unicode ranges are generally
aligned at power-of-16 boundaries.

   I will have more criticisms of the SVG spec later, but wanted to
fire these off now due to the limited time frame of the "Last Call"
period.

Raph

Received on Saturday, 14 August 1999 18:57:12 UTC