W3C home > Mailing lists > Public > www-svg@w3.org > April 2003

Re: [SVG] Experiment and proposal

From: Fred P. <fprog26@hotmail.com>
Date: Tue, 15 Apr 2003 14:39:55 -0400
To: www-svg@w3.org
Message-ID: <BAY2-F91MjtLIX8I4JH000bb488@hotmail.com>

>>3. Provide XHTML <table> layout in SVG
>>      Letter by letter, word by word fixing is tedious

>SVG does not make a good mark-up language for marking up text,
>it's a markup language for images after all,

Only images? =P
Sorry, but what a narrow mind of yours.

Text is just one very specific kind of scalable images.

Therefore, does this means that you consider
Flash, PS and PDF are also file formats only for images ?
GIF/PNG can also be used to display text.

For instance, I could send you an image of this email instead. =P

>tables are certainly not the sort of priority
>where early versions of SVG need it.

Well, I don't think that including XHTML DTD of table inside SVG 1.2
could be considered difficult in any sort of way.

Why making it so difficult to display text and images that scales?

One of the advantage of PDF is that you can ZOOM IN and still
see beautiful images and text. Why not having a SVG document
that can do something completely similar ?

>It can of course do it, but it's
>rather verbose - of course any rendering quality in SVG is generally
>superior to anything I've seen in raster based renderings.

>>5. Even though SVG is for Vector graphics, it's very tedious to obtain
>>    the same effect than bitmap drawing effects at pixel scale.
>>     Provide something like: D x y  =>  Print a Dot at (x,y)

>EEK?  Why would you want to do that

Because currently, there's no way around to do it efficiently.
Since there's no concept of a JAR file equivalent,
if you wish to send someone a SVG standalone document
containing few bitmap images, how do you proceed?

This way, we could draw lines, dot, lines, square, dot, lines in one PATH 
statement for one color.
and therefore, convert easily and space efficiently bitmap files.

Currently, a bitmap must be converted into dots like this:

<path style="fill:#000000" d="M1 1 l0 1 l1 0 l0 -1 z"/>
instead of
<path style="fill:#000000" d="M1 1 D0 0"/>

3 dots:
<path style="fill:#000000" d="M1 1 l0 1 l1 0 l0 -1 z M1 3 l0 1 l1 0 l0 -1 z 
M1 5 l0 1 l1 0 l0 -1 z"/>
instead of
<path style="fill:#000000" d="M1 1 D0 0 D0 3 D0 5"/>

>- You've also not mentioned how big a DOT, which would appear to me to be 
>one of your problems - you're thinking
>of SVG not in it's abstract mark-up, but looking at what one particular
>implementation does on a particular output device.

Normally, as far as I'm concern a dot is a pixel;
or more generate 1x1 currently user-defined units.
However, specific viewer could scale them as appropriate.
You could also provide CSS "dot-size: 1px;"

Think of a dot like a "square" circle of radius 1,
where (x,y) is the center of the square.

Something like this:

|          |
|     .    |
|   (x,y)  |
|          |

>It seems not to matter to you that you might be viewing the same SVG 
>document on a 3" screen, or
>projected onto the face of the moon - what exactly does a pixel mean in 
>those situation?

Anyway, if you say something like:
<rect x="100px" y="40px" width="100px" height="60px" class="myBox"/>

It's gonna look terrible to view such picture
on a cellphone screen or on the surface on the moon.
Don't you think ?

I return you the question:
On a current SVG 1.1 viewer: what exactly does a pixel mean in such 

Therefore, your argument doesn't hold at all.

>>Even with lines, bezier curves, it never looks as good as the original
>>picture and the shadow doesn't scale well when make bigger.

>I think you might need to show screenshots or something here, odd diagrams
>are certainly inpenetrable to me.

Hmmm... Did you even take the time to look at my screen shots... ?

http://j2k.sourceforge.net/svg/attribute.gif (The original image)

http://j2k.sourceforge.net/svg/box3.gif   (The pixel zoomed image)
http://j2k.sourceforge.net/svg/box4.gif   (The approximated SVG image)

http://j2k.sourceforge.net/svg/5.svg      (The SVG image for box4.gif)

>>    Space is not an issue, it might be for 640x480 gif image to be
>>converted in SVG perhaps.

>Converting images doesn't sound like an efficient way to go - create SVG

Well, maybe that SVG is currently not wide-spread and that people would wish
to convert their existing database of images in SVG format?

Remembers me a senior consultant at Microsoft who told us:
"Why do you wish to convert your 2 TB database of high quality image files
stored in OLE DB BLOB format containing 10 years of product specifications 
just recreate them on our new SQL Server 2000!"

Maybe we don't want to recreate them, we first need to convert them
start an existing base of document and then create SVG for future,
this is a normal practice in the industry.

>>In fact, if SVG provided the same kind of support than HTML for
>>forms and text display,
>>it could even replace HTML/XHTML altogheter,

>That would be a disaster it's a lot less accessible, and is primarily a
>visual mark-up language, it certainly doesn't want to be a replacement of
>HTML - however as an environment for creating applications it would
>certainly be useful - and undoubtedly better than the current situation 
>people creating their own boxes.

Exactly, my point is to show that SVG can be used to create application
requiring a lot of graphics to be generated on the fly.
DHTML can do this but very inefficiently and doesn't provide all the filters
and other cool stuff that SVG can provide. My point is that SVG features
should be fix such that we could move on from DHTML to SVG for web 
It would certainly be faster and more scalable than slow Java applets.

>>    the browser won't recognized that PHP generates an SVG document, even
>>though it does!

>This is simply your own lack of experience, whilst you may have a fair
>complaint that no registered mime-type exists for svg, you certainly don't
>have any right to complain if you don't use it.

Well, it has image/svg-xml on SourceForge server instead of image/svg+xml,
but that I have no way to change that around, since I'm not the sysadmin.
My point was that if an HTML document contain this

<EMBED SRC='file.svg.php'

and that the file.svg.php produce an EXACT copy of a SVG document,
why it doesn't work? If you have a work around please simply provide it.

>>    One of the problem with PHP/ASP/JSP is that whenever a document is
>>    then embedded inside an HTML, the file is not flushed to disk;
>>    one must use special tricks, like using a

>I don't find that a problem with ASP technologies, and whilst I don't use
>PHP or JSP, I can't really imagine that the problems genuinely exist - more
>likely isn't the problem simply your own experience in the languages?

There is no fflush equivalent in PHP4 that's for sure.
Again, did you try to 'submit' a form in ASP?
since that's where the bug occur in PHP.

>>    <META HTTP-EQUIV='Refresh' CONTENT='0; URL=<?php echo $PHP_SELF
>>."?op=display_svg_file"; ?>'>

>With meta refresh regularly  disabled this would seem very silly - even if
>it was the case, a 30* response would seem a much more sensible route (as
>this doesn't require an HTML agent involved, something that's unlikely with
>many excellent SVG viewers having NO HTML capability.)

No but your browser has a SVG viewer plug-in, it's for a web application,
not a stand-alone SVG document, while the stand-alone SVG document could be 
upon a 'SAVE' button let say.

>>Hope this elucidate some problems faced in an industrial/professional 
>>usage of SVG.

>I find it rather sad that you chose to post 47K of content, most of which 
>languages wholly off-topic, and better expressed simply by giving
>appropriate urls to the list.

Again did you bother looking at the entire mailing thread?


Sincerely yours,


MSN 8 with e-mail virus protection service: 2 months FREE*  
Received on Tuesday, 15 April 2003 14:40:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:46:55 UTC