Re: [SVG] Experiment and proposal

"Fred P." <fprog26@hotmail.com> wrote in message
news:BAY2-F53R6rHCkaQMP90000007f@hotmail.com...

I would appreciate it if you didn't combine messages into a single message
so we can maintain threading etc.

> >(I created
> >an example for a related
> >problem: http://jibbering.com/2002/8/text-mixup.svg )
>
> Can be resolve in XHTML easily:

Actually it can't other than in the purely visual sense, on some visual
browsers, but SVG is a fixed layout mechanism, it's whole idea is that
you get repeatable fixed behaviour between viewers, so (in all important
respects) you get identical rendering minus minor changes due to
device capabilities.

> <table border="0">
> <tr>
> <td>The</td><td>Cat</td>
> <td>Sat</td><td>On</td>
> <td>The</td><td>Mat</td>
> </tr>
> <tr>
> <td></td><td><img src="cat.png"/></td>
> <td></td><td>
> </td><td></td>
> <td><img src="mat.png"/></td>
> </tr>
> </table>

The images, and the words are no more, in fact a lot less related in the
above mark up, than they are in my pure SVG markup which exhibits the
problem.  In SVG position has meaning, so if a picture of a cat is below the
word cat, that's meaning.  In HTML tables this is not the case, nowhere do
you specify that the second row are pictorial representations of the words,
or indeed that they are related in any other ways - you're also of course
missing a lot of other markup that most people would require in their table
markup (headings/summary's etc. required by most peoples accessibility
specs.)

> That code would scale and FIX your problem easily.

It could create an acceptable visual rendering, accept of course the TR, TD
and TABLE tags have no visual rendering specified so the results are
actually wholly unknowable in a browser.

> Table have been used since years to layout text,
> why shall that change?

Because it's been shown to be extremely inefficient, and has particular
accessibility issues, making it inappropriate for web use.

>>XHTML has very few layout semantics, and none in its strict versions,
>>it'snot a language for layout, it's for marking up text.
>
> Well you only need table and div that's about it.

Table has no layout semantics, it has table semantics, it is not a layout
element, we have a DIV in SVG it's called G, and can be easily positioned.

>>your scripts are an authoring tool, it would seem appropriate that they
>>do the calculations, if your elements are kept to a reasonably fixed size
>>then the calculations are trivial, if not then you do have a more
>>complicated problem.
>
> Their are not, but why should I make complicated approximation
> when a viewer is more capable of calculating that then myself,

An SVG viewer is not more capable, it's not a dynamic layout tool, it's
whole design is based on achieving identical rendering, deviation from this
may be attractive, but it's certainly not an existing feature of the spec in
any way.

> how can I assume that the text delta is 5,15,20,60 pixels
> or less or more the distance between stuff, etc.

You don't assume it, you specify the textLength, and other sizes.

> Do you see people doing that in HTML, no.

HTML has no layout semantics...  in CSS (which I assume you're really
discussing) I see a lot of people precomputing bounding boxes, and meeting
many positional problems.

> So why should you calculate such stupid things in SVG,
> it doesn't make sense, at least not to me.

I'm still not sure you've fully appreciated SVG's aims - the key one being
_identical rendering_.  You also introduce huge difficulties in authoring
due to the painters model features of SVG (to put something on-top of
something else, you have it later in the file) with dynamic layout this is
going to be near impossible, unless instead of a grid we get a 3d
structure. *

>>Yes, this is quite normal and currently well supported,
>>look at the viewbox attribute.
>
>I'll look into it.
>If you have an example at an URL, please provide it.

I strongly recommend you read the specifications, whilst occasionally
confusing to the point of misleading, and many times difficult to read, they
still tell you everything you can do with SVG.

This circle, scales nicely to the size of the window:

<svg viewBox="0 0 10 10">
 <circle cx="5" y="c5" r="4"/>
</svg>

>>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.
>
> Well, if letters are images,
> a set of letter is also a set of image
> and therefore, an image. =P

No, a collection of images clearly has meaning beyong the individual images,
Doug has rightly corrected me in that letters are not simply images, only
the
images used to symbolise those letters are (the glyphs)

> >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.
>
> The stylesheet is defined within SVG,
> so it doesn't make sense.

So you also need to read the CSS spec, a USER stylesheet will always
override an author stylesheet, you cannot overcome this.

> Also, an SVG document could be
> translated by some XML babelfish anyway.

That is a near impossible task (it could only realistically achieved by
rasterising the SVG image, and then using OCR to read back the text - it
would require significant processing overhead, and be extremely
error-prone.)

> transparent table are used for layout since decades,
> look at the HTML code of any website!

You're confusing usage with defined for, it's never been defined for that
(HTML is simply not about layout, it's purely about semantics.)

>>in the SVG-developers mailing list, and hopefully been discussed within
>>the working group.
>
> Is there a way to join the group with a Yahoo account?
> I forgot how to do it.

Since it's a yahoogroups mailing list, it would seem odd not to be able to,
I however read and post through the nntp interface provided via
news.gmane.org

> >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.
>
> I don't think so. It would be very nice to have.

It would be nice to have all sorts of things, most of them like the above
are not practical.

> Even Adobe was planning to had <table> mark-ups
> announced in the svg-developper Yahoo mailling list.

No, they suggested a grid may be included, even that I believe is going to
be difficult to specify.

> >><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?
>
> Well, any graphics in pixel designed size
> will look awful on any such device.

Can I ask you again, to please look at the definition of a pixel in the CSS
spec - a hint for you, it's got nothing to do with single picture elements
on the device showing the image.

> I'm from low-bandwidth too, 56kpbs ?
> You got what a 2400bps or 14400bps modem?

I live in the developing world, my single largest expenditure every month is
internet access, I generally share a 56k modem or 64k isdn line with 6-20
other people, the links to the US are also long and through some heavily
loaded routers. 1st world 56k would be a blessing.  If it wasn't for the
cost of my 9.6k GSM connection being simply out of the question, I would
consider using it for the faster downloads it would provide.  [**]

> Have a vectorial image with bitmap 'supplement' where both would scale,
> so you can mix both easily, currently it's very costly and tedious
> to encode such supplement.

No, as we've discussed, this is already provided for in SVG!  data: viewBox
etc. etc.

> It would be nice the have an easy to use, easy to develop,
> 'scalable vector graphic' web applications,
> generated from a database backend for industrial usage.

and the moon on a stick?

> >[*]  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.
>
> Yes, DHTML doesn't work in Mozilla or Netscape or others. =(

Of course it does, Mozilla is almost as capable as IE6, and in many ways
superior to it, Opera 7, Konquerer, iCab are also extremely capable.

>>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.
>
> Any URL or source code?

See SVG developer posts, particularly my whiteboard.

> >>>it was the case, a 30* response
>
> What do you mean by a 30* response?

HTTP response codes in the region of 300-309

>>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
next
>>saying because my HTML browser is a line mode browser, I can't view
>>GIF images either.
>
> What's a line mode browser? Something like lynx or cellphone???

Yes, they are both examples of line mode browsers (although I understand
many cellphones also display SVG of course, but many are line mode
browsers.)

>>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.
>
> Well, if it happens to me on different computers
> then it will happen with different people also.

By using a 30* response at worse, or more likely and simply - looking at
your code and a PHP manual (or posting to a PHP group) for the correct way
to achieve what you want.

Jim.

* In fact, this is an interesting problem in itself, I'm going to be quite
interested to see how painting on top of something laid out in a grid is
going to be possible, in fact I'll post about it.

** Live is of course not quite accurate, I travel through.

Received on Sunday, 20 April 2003 06:01:13 UTC