Re: font formats and SVG2

John Daggett:
> Dr. Olaf Hoffmann wrote:
> >>Can someone explain what the features are that are not offered
> >>in TrueType fonts?
> >
> > I think, the possibility to embed SVG fonts within a graphics
> > (SVG document) is an important feature for authors, as soon as
> > this is widely implemented. The glyphs can be created with
> > features from SVG, no need to learn yet another format not much
> > related to the graphical problem, the authors has, if just a
> > few glyphs are needed for a logo or something like that. SVG
> > fonts help to keep things simple for authors, especially for
> > those not very interested in creating complete fonts for
> > general use, but just some glyphs for a special purpose.
>
> Taking SVG-defined outlines and generating a font via FontForge
> is a *trivial* process.  

Well, for general usability I think it is important as well to be able
to do it without specific software - this is the advantage of an
XML-format to have always the complete control on how to create
the documents.

> Converting these to OpenType allows them 
> to be used as input to *text* rasterizers (e.g. DirectWrite,
> FreeType, ATS) as opposed to purely graphic renderers.

Sure, nice tool, if you need it. Often you need only the glyphs
as SVG path data (usable as SVG font) to get what you need.
Everthing else is superfluous work, wasting time with needless
work for the intended task.

> Without the use of a text rasterizer, the results will not be
> subpixel antialiased, which typically includes rasterization
> techniques tuned specifically for text.

Well keep in mind - SVG - scalable vector graphics, it has no
pixels at all, only a user coordinate system. 
Antialiasing etc is only a question of presentation quality and
applies to all graphical shapes in the document. 
If the quality is sufficient for the graphical shapes, it will be
for glyphs of similar size as well - if not, well the presentation
quality of viewers needs to be improved (once one has 
a presentation resolution below the resolution of the human
eye, the problem will be solved anyway, today this applies
typically for printers, not yet for monitors).

>
> > If the glyph information is directly embedded in the SVG
> > document, it is simply possible to provide standalone documents
> > with predictable behaviour for the presentation of the glyphs.
> > To assume that referenced external fonts in another format are
> > always available is risky and I think it will not be acceptable
> > for some designers with a quite detailed opinion about the
> > appearance of their graphics and how to control this on their
> > own.
>
> By this argument, SVG should define a raster graphic element so that
> images do not need to be referenced externally.
>

Well it has pixel based filters, if it matters one can generate with 
several tools a vector graphic from a raster image and one can embed 
the raster image using the pseudo-protocol 'data:...'.
Authors have the choice, what the best soltution for the
specific problem is. It is always good to have the choice instead
of being forced to use a suboptimal solution and to work around
all the problems of such a suboptimal solution ;o) 
In general SVG is advanced enough to work around any 
limitation - but the result is typically a much more complex
document with much more source code and often less
accessibility.

> > A detailed control about the appearance of a glyph it typically
> > not so important for the author of such text documents as for
> > some text within an SVG document with close relation to other
> > graphical content.
>
> What detailed control are you thinking about here, specifically
> in the context of SVG 1.2T Fonts?

I think, this is already explained by other replies.
But indeed, the mobile variant provides only limited access/control,
for example no animation, but this is only intended for devices
with low computational power. If such devices are the target
for the author, the limited control will still be much better than no
control at all ;o)

>
> I think it would be far better to consider ways to better
> integrate OpenType fonts in SVG, such as providing API's to
> access glyph path data in OpenType fonts.  I think this would
> open up a *far* wider set of use cases for authors who want to
> modify glyphs from a given font as part of a design than the one
> you're suggesting.
>

This sounds like a good idea.
I'm not a font expert, therefore I do not know, how this format
is contructed, but I think the basic requirements for SVG integration
and complete control sound something like this:

1) XML format (to allow simple access to the content)
2) SVG syntax for path data 
     (to allow simple definition of glyph shapes,
       animation, styling etc)
3) Meta information with RDF
     (often authors want to provide information about rights
      and origins of their work, this has to be accessible without specific
      tools)
4) Semantical (meta) information with DocBook, DAISY, LML or XHTML+RDFa
     (useful to explain the purpose and intention of the font idea)
5) If required hyperlinking functionality with XLink
6) SMIL/SVG approach for animation

Surely there are some more requirements, we can collect ...



> One underlying argument I keep hearing is that SVG Fonts provide
> an "all-SVG" workflow.  That might be useful in the context of an
> SVG-only renderer but as part of an integrated web platform for
> graphics, it's redundant.

See above, with an advanced XML format or an extended SVG font
variant I'm sure all needs can be satisfied easily.

>
> I think it's best that SVG2 remove SVG font objects entirely. 

To extent it looks like the better choice. As far a I know, currently
there is nothing that competes for SVG content.
But surely, with an XML standard format for fonts, that can be
embedded and is completely compatible with SVG there is
a chance for an alternative.
Because older viewers only interprete SVG fonts (partly), however
removing is no option anyway.
For example on my current Linux systems for the still pretty good
Adobe plugin it is the only way to display SVGs containing text 
by using an embedded font, because obviously Adobe forgot to
embed at least one default font and the plugin obviously does not
like or find the fonts available on the computer (presumable some
kind of free font format compatible with the Debian licence conditions).

> The 
> use cases just aren't strong enough to justify the ongoing cost
> of implementation/testing this mostly redundant feature.
>

I think, the use cases for yet another external font format for
SVG are not strong enough to risk backward incompatibilities
with already existing viewers - it causes only unnecessary problems
for users of older viewers with not much benefits for users of newer
viewers, causing a lot of work for authors to provide a document 
sufficient for old and new viewers.
If a control of the font does not really matter, one simply can
write font-family="sans-serif" - there is no urgent need for an 
external font format different from SVG fonts.
Of course, as an option for a larger amount of text in SVG and
expecially in XHTML+CSS it is already a progress to be able
to reference a font in a format, that is widely interpreted,
but to meet all needs, we need an XM format as suggested
above to replace all these workarounds. And SVG fonts are
a good base for this already, because they provide already
all basic features mentioned above. One 'just' has to add
a few more features to address the requirements for an
optimal display of tiny glyphs on low resolution devices -
you should know much better than me what they are and
how to add this ;o)

Concerning SVG, the question is not SVG fonts or another
external font format. Indeed the practical question is
more: Are SVG fonts usable or have I to work around
limitations using arbitrary path data, forgetting about accessibility
or doing a lot of 'brainfuck' to combine arbitrary path data with
advanced meta information to provide accessible documents?
External font formats will often not do the job and are no alternative
for major SVG use cases, therefore we can forget about them, 
if we discuss about SVG fonts - yes or no.
To have no SVG fonts means problems for SVG authors.
To have additionally an external font format available is a nice feature
with several use cases as well. But this should not be mixed up,
because as long as the font format does not meet the requirements
mentioned above, SVG fonts and other external fonts  formats
are almost independent questions.

Olaf

Received on Thursday, 3 March 2011 10:32:38 UTC