Re: SVG text questions

Raph,
These are all very good questions. The SVG working group is just starting
to tackle text/font questions, so we might have better answers in the
coming weeks. I'll take my best stab at responding.

At 10:54 PM 6/8/99 -0700, Raph Levien wrote:
>Hi SVG people,
>
>   I'm reading the SVG spec trying to get a handle on it, and I find I
>have a number of questions. The answers are not immediately clear to
>me from reviewing the spec and supporting documents. I realize it's
>very much a work in progress. Also, no doubt some of these are just
>because of my thick head. But here goes:
>
>* The spec says that SVG inherits all text properties from CSS2. Does
>  this include justification (the 'text-align' property)?

If SVG is embedded within other XML, it will inherit *ALL* properties.
That's how CSS works.

The relevant questions are which properties will SVG support and what
behavior does it apply to each property. The SVG working group is working
on these questions and doesn't have any answers yet.

My personal opinion is that 'text-align' should be supported, with 'center'
meaning that the horizontal center of the given <text> element should align
with the current text position (i.e., the value of attributes x and y on
the <text> element).

>
>* Does an SVG implementation ever do line-breaking of text?

It doesn't look like SVG will do any line-breaking. If you want
line-breaking of text, then embed some XHTML or other CSS-formatted or
XSL-formatted XML within <foreignobject>.

>
>* If a font contains kerning and ligature info, does an SVG renderer
>  apply these transformations?

My best guess is that the answer will be 'yes' but I'm still doing my
homework. I believe an SVG processor, just like a CSS processor, should
take advantage of any intelligence built into a font.

Note that SVG will provide an 'altglyph' facility so that authoring
products can precisely control which glyphs are used and thus override any
automatic font features.

Once again, the whole are of text and fonts is complex and we are just
beginning to work through the issues.

>* If yes, and the font is in Type1 format, and if the font is
>  specified by download, how does the SVG renderer find the
>  corresponding .afm (font metrics) file?

I don't think current W3C standards such as CSS address this issue directly
and I'm not aware of any relevant de facto standards.

Adobe is aware of the desire to post Type1 Web fonts and is working through
solutions. Stay tuned.

>
>* How does one specify a precise font in any other way than by
>  downloading? In particular, how would an SVG document specify the
>  difference between Adobe Times (in Type1 format, say), and Monotype
>  Times (in TrueType format, say)?

You can provide a 'hint' about what type format a given font is, but I'm
not sure that all implementations will do what you want and (for example)
only use the Type1 font.

I think Web fonts are the way to go if you want to ensure that the correct
font is used. System fonts have their place, too, but probably should be
avoided if you have precise text needs.

>* If the precise font is specified by download, and the renderer
>  implements CSS2 "intelligent matching", is the precise font to be
>  ignored in favor of the matched font?

As I read the CSS2 spec, if you put the precise font in the font list ahead
of something which would start off the intelligent matching algorithms,
then the precise fonts would get priority.

Incidentally, I believe that font selection is done on a
character-by-character (or is it glyph-by-glyph) basis. Thus, if your first
character is found in the first font in the list, then use the first font
for that character. But if the second character is only found in the second
font, then use the second font for that character.

>* Assuming that font matching takes place and that the font used in
>  rendering is subtly different than the font used in authoring, what
>  is the expected behavior? The left side aligns correctly, but the
>  right side may be incorrect (i.e. more or less the PostScript way)?

That is what I would assume. Just like PostScript, you can either do:

   <text>I just hope that text spacing matches what I need</text>

or

   <text>I </text>
   <text x=...>j</text>
   <text x=...>u</text> 
    etc.

With the latter case, gzip compression on the SVG file would be highly
recommended.

>* What are the semantics of the text-shadow property when there are
>  multiple text elements sufficiently close that the shadows overlap?
>  Is each text element rendered on its own alpha-transparent canvas,
>  or do all the foreground glyphs get grouped over all the shadows?

First, we haven't addressed the issue of whether text-shadow would be
supported in SVG. (I would recommend that SVG should support it.)

My assumption is that each text element would be rendered individually and
independently -- no automatic grouping.

>* Is there any way for the creator of an SVG document to specify text
>  that will (a) be rendered with the precise metrics intended and (b)
>  will render correctly on all conforming SVG implementations?

This was one of the requirements from the SVG Requirements document.
Somehow or other this will be possible.

>P.S. I don't have a webpage yet about the planned Gnome SVG
>implementation. We're going to be using the Gnome Canvas as the
>rendering engine. This canvas fully supports antialiasing and
>transparency, and we're going to be extending it to support the full
>generality of the SVG imaging model (a Small Matter of Programming :).

Sounds great!

>
>More info about the Gnome Canvas can be found at this link:
>
>http://www.gnome.org/devel/canvas/
>
>Incidentally, there are a couple of references to "commercial
>implementations" in the SVG spec (section 13.4 and some of the
>conformance language). A better phrase would be "high quality
>implementations", in my opinion.

This is a good suggestion.


Jon Ferraiolo
Adobe Systems Incorporated
Member SVG working group and editor of the spec

Received on Wednesday, 9 June 1999 13:47:35 UTC