Re: Type in SVG: final form only?

SVG does indeed support "text" (as Eric calls it), at least at the one line 
level.

An SVG implementation has to have a good number of layout capabilities. It 
must support left-to-right, right-to-left, top-to-bottom and bidirectional 
text for both horizontal and vertical text progressions. It has to do 
start/middle/end alignment (the 'text-anchor' property). It SHOULD do 
ligatures and support automatic kerning. It also must support 
text-on-a-path. Thus, an SVG implementation needs quite a bit of 
intelligence to do client-side glyph positioning.

In summary, SVG allows you to work with either "text" or glyphs. With the 
'altGlyph' mechanism and the per-character positioning features, SVG does 
indeed allow for precise glyph positioning, but the recommended direction 
for most situations would be work with "text" rather than "glyphs", and 
allow the underlying implementation to do the proper character-to-glyph 
mappings. By sticking with characters as much as possible, then you get 
increased accessibility, better searchability, the ability to copy/paste, 
easier manipulation from the DOM, increased readability in text editors, 
and an easier ability to apply other XML tools to the content.

Jon Ferraiolo
SVG Editor
Adobe Systems Incorporated




At 02:38 PM 9/12/00 -0400, Leonard Rosenthol wrote:
>At 10:37 AM -0700 9/12/00, Eric Muller wrote:
>>A bit of background for the question: In my (personal) opinion, one
>>needs to distinguish very strongly between "text" and "positioned
>>glyphs".
>
>         Agreed.
>
>
>>When dealing with documents that will eventually include type in their
>>presentation, there has to be a layout engine at some point. In the
>>case of HTML, it is in the HTML viewer, and one can argue that HTML
>>supports only text. In the case of PDF, it is not in the PDF viewer,
>>i.e. PDF supports only positioned glyphs.
>
>         Actually, PDF supports both positioned glyphs and text, since you 
> can choose to use a PDF operator that simply says draw this text starting 
> here "(this is some text) Tj" as opposed to explicit individual glyph 
> positioning.
>
>         And because of that, a given PDF rendering engine can choose to 
> do things like subpixel positioning (for improved anti-aliasing), or deal 
> with font (and/or glyph substitution issues).
>
>
>>It is clear from the SVG requirements and recommendation that SVG
>>supports positioned glyphs. The question is: does SVG support text?
>
>         Yes, exactly like PDF does, in that you can have both.  Also, 
> since SVG supports text decorations (underline, overline, strikeout) and 
> text alignment (left, right, center), those definitely are more "text" 
> than "glyph"
>
>
>>Does the SVG recommendation essentially implies that every SVG viewer
>>include a text layout engine? I carefully read the SVG recommendation
>>and could not conclusively conclude one way or the other.
>
>         I don't know that it implies it, but in practice I suspect you 
> need one.  HOWEVER, it can be a very simplistic one since you don't have 
> to worry (in standard SVG) about things like line wrap. But since you do 
> have to worry about alignment and such, you do need one.
>
>
>>Another way to ask: when an SVG viewer sees <text>act</text>, can it
>>decide to render the characters "c" and "t" using a ligature glyph
>>"ct" if there is one in the font? Can it determine the position of
>>this glyph by doing optical kerning with the "a" glyph?
>         I don't see why not.
>
>
>Leonard
>--
>----------------------------------------------------------------------------
>                   You've got a SmartFriend in Pennsylvania
>----------------------------------------------------------------------------
>Leonard Rosenthol                       Internet:       leonardr@lazerware.com
>                                         America Online: MACgician
>Web Site: <http://www.lazerware.com/>
>FTP Site: <ftp://ftp.lazerware.com/>
>PGP Fingerprint: C76E 0497 C459 182D 0C6B  AB6B CA10 B4DF 8067 5E65
>

Received on Tuesday, 12 September 2000 15:19:50 UTC