Re: [Devel] SVG & Fonts [was FreeType gzip support completed]

[David Turner]

Hi Vadim,

Vadim Plessky wrote:
> |  This means that the really "standard" formats will be determined
> |  over time by what is best supported by the most widely used tools
> |  and viewers.
>
> So, I think "standard font format" is font format supported by FreeType.
> Should we make this W3C proposal/recommendation? ;-))
Funny :-) But the W3C is made of vendors who will most surely say
that the current situation is the best possible since it allows them
to push their own solution (at the price of interoperability).

And yes, I wouldn't be surprised if FreeType was used in more than
90% of SVG Viewers out there because it supports a sufficient number
of the "standard" formats :-)

> |
> |  My opinion is that this will be OpenType/CFF, or CEF (Compact Embedded
> |  Fonts), a variation of it that Adobe already uses in its SVG Viewer.
>
> I doubt that Adobe has _any_ power nowdays.
>
I don't agree completely. The Adobe SVG Viewer is probably the most
installed viewer, due to the number of Windows desktops in the world,
so any format that isn't supported by it can be considered DOA
(dead on arrival) for these users.

Microsoft didn't jumped into the SVG band-wagon. And given the *microscopic*
success of its "WEFT" tool to embed fonts on the web, I'm not certain they're
going to push .eot very hard too.

Besides, I don't know of any tool that is capable of producing .eot font
files, except the Microsoft ones...

> (but from developer's pointof view, I agree that we should go forward with PS 
> Type1/Type2 hinting models, not with TrueType)
Yes, fortunately, that's used by CEF, the Adobe-supported SVG font format :-)

> |  And .eot (Embedded OpenType) is, as far as I know, the proprietary
> |  format used by Microsoft to embed fonts in its Office documents,
> |  as well as its Web Font Embedding tools. As far as I know, it's
> |  basically Agfa's MicroType (i.e. loss-less compression of
> |  OpenType/TrueType fonts), and will never be supported by FT2.
> |  Just forget about it too :-)
> |
>
> Interesting.
> Do you have any links on AGFA MicroType or Embedded OpentType?
Google is your friend :-) See:

  http://www.microsoft.com/typography/fontpack/pr2.htm
  http://www.w3.org/Printing/porell.html

in case you'd like to know, the MicroType DLL is called "t2embed.dll",
you'll be able to find it in one of the system directories of your
Windows installation.

> CSS2 was too bloated and has not very good perception.
> CSS 2.1 has some improvements over 2.0 (check some threads on address@hidden 
> mailing list.
> I am afraid that CSS3, despite being modular, is also too much bloated.
CSS 2.1 is still something that requires a really non-trivial parser.

> |     - tries to be a document structure language, when it should really
> |       be a document presentation language; inducing incredible problems
> |       that can only be managed through the other W3 creations
> |       (CSS, JavaScript, namespaces, XLink, etc...)
>
> JavaScript is Netscape creation :-)
> But I tend to agree with you for the rest.
OK, but it's one of the de-facto standard for scripts in SVGs, as far
as I know :-)

> |
> |  In other words, use SVG to edit scalable images. These SVG icons *are*
> |  really cool :-). Avoid it if you want to generate large documents,
> |  unless you're ready to waste buckets of money and time mastering some
> |  un-needed complexity.
>
> Ah, you are right: SVG icons is key driving force in SVG adoption, at least on 
> Linux!..
> Making those ones is just like eating peanuts.
> I like process itself! ;-) 
My opinion is that SVG's future will necessarily be narrowed to
standalone scalable images (e.g. icons). It performs very well in this
field. For anything else, it will be a complexity and interoperability
nightmare, despite all the XML and W3C "glue" in it.

> |
> |  Anyway, I'm pretty certain that none of the available SVG Viewers today
> |  support all of the W3 specifications (with the exception of Adobe, Batik
> |  and all the TinySVG variants).
>
> And I have heard that it takes Batik around 18sec. to render simple SVG 
> drawing (SVG icon) while other renderers do the task in less than 0.5 sec.
Well, it certainly depends on the JVM being used, I wouldn't expect any good
performance out of Kaffe, for example :-) Even C/C++ SVG renderers have very
widely different performances anyway.

The key point is that Batik's code is already huge in my opinion. And we're
speaking about Java code, which means that implementing the equivalent
functionality in C/C++ will be an order of magnitude more complex
(and buggy !!)

Most implementations only provide a small part of the specification, so expect
interoperability problems with the format for a *long* time.

That's why there is something like TinySVG, many people were sick of the bloat
and wanted a simplified format to do simple things through simple means. As far
as I remember, there was already some people in 2001 wanting to split the SVG
specification into several versions because they couldn't stand the bloat
pressure.


> |
> |  There are ways to make things easier. For example, I know some people
> |  that use XSLT to translate documents into _simple_ SVG images on demand,
> |  but the machinery behind this is quite impressive. Of course, they also
> |  generate PDF documents on the fly :-)
> |
> |  Hope this helps,
>
> David, would you mind if I post your comments on SVG (and fonts) on www-svg 
> mailing list?
> I already wrote essay-like message to www-style (why PostScript fonts are 
> betetr than TrueType fonts) today, and I think some of your commones are 
> quite inetresting and would greatly complement discussion on www-style.
I generally don't like to criticize a project without being able to
provide an alternative. That's why, for example,  you don't hear me
constantly ranting about how X11 and XFree86 are massive fuck-ups,
even though I would do that everyday if I followed my instinct :o)

Feel free to post my comments if you're *really* certain that this could
change something in the development of SVG. I'm pretty convinced that
this will not. And if you do, at least put some context by specifying
that I did implement a nearly full-featured SVG viewer some years ago..
(i.e. not speaking out of thin air :-)

Regards,

- David Turner
- The FreeType Project  (www.freetype.org)