Re: [Devel] SVG & Fonts

[Vadim Plessky]

Hi David!

On Wednesday 20 November 2002 8:19 pm, David Turner wrote:
|  Hi Vadim,
|
|  Vadim Plessky wrote:
|  > |  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.

I hope we would change this proportion in favour of Linux.
With Xr/Xc/libsvg "in place", there are high chances that we would have just 
one unified API/reference implementation, reused in GNOME, KDE or any other 
X-based environment.
And I am quite confident that number of Linux Desktops is much bigger 
thannumber of people insatlled Adobe SVG plugin.

|
|  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.

I am still wondering what Microsof is planning to do with Vector Graphics.
If they decide to go with SVG - Flash woul dbe dead with next Windows release.
If they continue with Flash (part of MS IE install) - SVG has low chances to 
succeed.
If they go to market with own format - well, I am afraid both Flash and SVG 
would be in bad position.

|
|  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.

Thanks, I will check it.

|
|  > 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.

But it's better than 2.0 and 1.0.
I am also pretty happy that 'inline-block'  was "backported" from CSS3 to CSS 
2.1, so it would be posisble to create nice layout without enermous number of 
nested tables, using CSS 2.1
BTW: Tantek Celik was supporting idea of adding  'inline-block'  to CSS 2.1, 
and idea of "CSS 2.1 now, CSS3 later", so sometimes even big vendors support 
reasonable ideas ;-)
Tantek is project Leader for MacIE, MacIE and WinIE have different code bases.

|  >
|  > 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 :-)

Isn't it officially called ECMAscript?  (ecma.ch)
BTW: I think real engine behind is DOM.
You can impleemnt DOM binding to JavaScript (that's somewhat default/reference 
implementation in most of W3C specs), Java (also presnet in some specs), C, 
C++, C#, Perl, whatever.

I think Microsoft would sacrificy (in Windows .Net) JavaScript (JScript) and 
come back with C# bindings to all objects they have in MS IE.

|
|  > |  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 !!)

IIRC, Batik 1.5 is about  8MB in "sources" and about 5MB in "binary".
Yes, that's huge.
Plus 20MB for JavaRE (I downloaded IBM's Java 1.3 for Linux, but haven't 
installed it yet; I just don't have enough hard disk space at amoment :-)

|
|  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.
|
[...]
|  >
|  > 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)

Com'on, recent XFree86 is not that bad!
And I think KDrive (a-ka: Tiny-X) is very promising.
But as I don't have PDA, I haven't tried it (yet).

Also: you may want to read this article:
Making the Case for XFree86's Speed
http://www.osnews.com/story.php?news_id=1905

and compile examples linked to that page.
According to the article, XFree86 is not very bad.  But  code running on top 
of it is far away from being optimal.

|
|  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..

ok, I think I would start to work on some SVG renderer first, that I will make 
own opinion on SVG implementation / renderer internals and post my comments.
Xr/Xc/libsvg is just 100K of sources (compressed), so it wouldn't be extremly 
difficult to get familiar with sources.

What's the name of SVG renderer you implemented? Is "30 day trial" available 
somewhere? :-)

|  (i.e. not speaking out of thin air :-)
|
|  Regards,
|
|  - David Turner
|  - The FreeType Project  (www.freetype.org)
|  _______________________________________________
|  Devel mailing list
|  address@hidden
|  http://www.freetype.org/mailman/listinfo/devel

-- 

Vadim Plessky
SVG Icons
http://svgicons.sourceforge.net
My KDE page
http://kde2.newmail.ru  (English)
KDE mini-Themes
http://kde2.newmail.ru/themes/