Re: [SVG] Experiment and proposal

"Fred P." <fprog26@hotmail.com> wrote in message
news:BAY2-F19mWecm9t0CI7000008e9@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, tables are certainly not the sort of priority
where early versions of SVG need it.  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 - 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.  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?

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


>    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

> 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 with
people creating their own boxes.

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

>    One of the problem with PHP/ASP/JSP is that whenever a document is
> fopen/fwrite/fclose
>    then embedded inside an HTML, the file is not flushed to disk;
therefore,
>    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?

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

> 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 in
languages wholly off-topic, and better expressed simply by giving
appropriate urls to the list.

Jim.

Received on Monday, 14 April 2003 10:50:19 UTC