Re: [SVG] Experiment and proposal

"Fred P." <fprog26@hotmail.com> wrote in message
news: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.

No, words are words, they're very different from images, and very
importantly so, letters are just images certainly, but words and sentances
are not.

> Therefore, does this means that you consider
> Flash, PS and PDF are also file formats only for images ?

Pretty much so yes.

> GIF/PNG can also be used to display text.
>
> For instance, I could send you an image of this email instead. =P

You would not be able to know that I could read it (you have no knowledge
that I am able to see, or that I don't need to pass this text through a
language translator) and that is the very reason why I don't believe SVG is
appropriate for text layout - you can layout text with it easily into
something that visually looks readable to you, but makes no sense unless my
user stylesheet is similar enough to yours.

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

Exactly what tabular data would you wish to add with these images?  Or are
you intending to use the XHTML table element as a way of simply laying out
text? something which is not defined for.  I agree that certain layout tasks
in SVG are harder than need be and a simple grid where the ability the
layout elements
relative to each other (rather than having to calculate bounding boxes when
authoring) but that's distinct from tables - and has recently been discussed
in the SVG-developers mailing list, and hopefully been discussed within the
working group.

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

Because accessible text document authoring, and accessible image document
authoring are distinct beasts, and creating some huge single mark-up
language to attempt both jobs is ridiculous.  A viewer that can do both -
that would be great, but tough I think, especially well (solving the human
interface to such a system is tough enough I think).

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

I use the data: uri scheme, what else would I use?  It's trivial, it's
efficient, it's well supported and relies on some established technology,
the suggestion of creating points of colour etc. is IMHO utterly ridiculous.

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

if it's lines and stuff - how's it a bitmap?  Surely a vector drawing would
be appropriate.

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

I still think you need to explain why you want to do this, not how.

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

Odd, the whole enjoyment of being able to scale SVG images is that I don't
have to fight with squares all the time, I'm still struggling to see why you
want to introduce them.

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

Well one rect would be pretty dull, I don't see how it's "terrible" though -
what sort of problems do you forsee?

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

It's well defined in the CSS specification.

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

They weren't mentioned in the post I replied to, and your subsequent message
with them was not available when I was writing my reply, so no I didn't, I
am glad you have since fixed the oversight (not having internet access I
cannot now either, I'll certainly look when I next see some bandwidth.)

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

Certainly going from SVG to raster is sensible now - I'm struggling to see
the motivation of converting rasters to SVG.  If they're diagrams
describing specific things then your own XML format with efficient semantics
that you can then programmatically convert into SVG would be the way to go,
especially as that is more likely to leave the semantics of your diagrams
intact.

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

Yes, and for the images it's great, for the interface part, it's far from
there.

> My point is that SVG features
> should be fix such that we could move on from DHTML to SVG for web
> applications.

HTML is an accessible way of creating web applications, efficiently authored
DHTML is still generaly accessible [*]  but SVG applications are not, it
does not contain the semantics to do it.

> My point was that if an HTML document contain this
>
> <EMBED SRC='file.svg.php'
>             NAME='svgEmbed'
>             TYPE='image/svg+xml'
>             width='200'
>             height='200'
>             PLUGINSPAGE='http://www.adobe.com/svg/viewer/install/'>
>
> 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.

Well, I don't know much about embed, It's not in any of the HTML
specifications I
use, but in general the HTTP level is authorative on the content-type, I
also believe there's very good reasons for this, so a browser should be
ignoring your type and using the authorative server version when it's
different (presumably using the advisory type to decide if to even bother
downloading.)

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

Certainly, I have lots of forms returning SVG without problems, the forms
at: http://jibbering.com/rdf/codepiction.1  for example.  They're ASP, but
I've
seen others use PHP and similar.

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

My standalone SVG viewer has HTTP capabilities, my browser has no plugin -
you seem to have a very narrow view of web browsers, you'll be saying next
because my HTML browser is a line mode browser, I can't view GIF images
either.

Even then, you've not addressed the fact that all the major browsers enable
you to block a meta refresh, and in that situation would a 30* approach not
make more sense?    This is I think an irrelevance anyway, as the problem
you have doesn't seem to exist for anyone else.

>>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.
>
>Again did you bother looking at the entire mailing thread?

The entire thread that was available at time of writing certainly, I feel
the complaint is justified, or is commenting on SVG not open to those
without permanent high bandwidth internet connections?

Jim.

[*]  Most people are pretty bad at this, but that's because most people
couldn't care less about accessibility as they don't realise it's an issue,
it also depends exactly what you're doing.

Received on Thursday, 17 April 2003 04:11:05 UTC