Re: Identical rendering? [was Re: SVG 1.2 General feedback]

On Tuesday 03 December 2002 6:51 pm, Thomas E Deweese wrote:
|  >>>>> "LR" == Leonard Rosenthol <leonardr@lazerware.com> writes:
|
|  LR> At 4:18 PM -0500 11/21/02, Thomas E Deweese wrote:
|  >> >>>>> "VP" == Vadim Plessky <plessky@cnt.ru> writes:
|
|  VP> Than talk to Adobe to switch their ASV from closed-source
|  VP> implementation to FreeType.  And ask Batik guys to use FreeType,
|  VP> too.
|
|  >>  Does FreeType do stroking and dashing of outlines?  Typically this
|  >> isn't needed for rendering text but is needed for svg.
|
|  LR> 	What FreeType will do in this case is return to the caller the
|  LR> vectors that make up the glpyh and you can do then do your own
|  LR> stroking/dashing.
|
|      Then I turn the results into pixels how?  Getting access to the
|  glyph vectors is the easiest part of the whole thing.

I don't think that "getting access to glyph vectors" is an easy task.
Just count number of different font formats and necessary backends (PS Type1, 
PS Type3, CFF/Type2, OpenType, TrueType, Speedo, PFR. Have I enumerated allof 
them?)

As about "turning vector paths into pixels"  - FreeType has very good 
rasterizer with advanced anti-aliasing, which produces superior results 
(comparing to competitors, like Microsoft, Apple or Adobe)
It has analythical algorithm equvivalent in quality to 64x oversampling.
(for example, OpenGL or GhostScript have just 4x oversampling)

|
|      You could have two rendering paths one that is used strictly for
|  simple text (solid fill, etc) that uses FreeType and a totally
|  separate rendering path for stroked, dashed, pattern filled text (and
|  objects) but this adds to bloat, and makes any reasonable description
|  of 'Identical rendering' at least twice as complex (one text rendering
|  description and one - non-text rendering description).

I guess leonard can tell a few words how it's solved in ImageMagick.
It seems to me that there are indeed two separate rendering paths in IM.

|
|      I guess the point I'm trying to make is that text rendering is one
|  part of an SVG renderer.  So perhaps FreeType is part of the answer
|  for Vadim's All-Singing-All-Dancing SVG implementation, but there is a
|  lot more involved than just text rendering.

Question is wether current SVG specification and available SVG renderers (if 
you mean under "specification" and "renderers" complete, W3C-compliant 
implementation) is the right way to go.
I haven't cheked SVG Mobile profile yet, it can be that Mobile profile is a 
way out of existing bloatness.

So far, I received quite good perception for an idea of SVG icons, and results 
are *feasable*, you can touch/check out those icons.
I still have to find other possibilities to utilize SVG (I do not speak about 
*niche markets* here, like cartography/GIS, I am interested mostly in mass 
market)
Idea of using SVG on mobile phones (instead of HTML) is quite promising, too.
But it seems major mobile phone manufacturers have different opinion on what 
should be inside mobile.
Idea of replacing PNGs (or GIFs) on web sites with SVG is not coming through, 
even webmasters of Linux-related websites are opposite to this idea
(unnecessary problems, double-work, etc.)

To answer question *how* we should compare rendering, we need to *identify 
markets* first. Than we can come out with ideas how to proceed with 
comparisions.
So, let's start from identifying potential markets first.

-- 
Best Regards,

Vadim Plessky
SVG Icons * BlueSphere Icons 0.3.0 released
http://svgicons.sourceforge.net

Received on Tuesday, 3 December 2002 11:49:56 UTC