"Fred P." <fprog26@hotmail.com> wrote in message
news:BAY2-F168RgPRCjOuF1000016da@hotmail.com...
> Anyway, how are you gonna "display" visual SVG information
> being layout in tables to a blind person
> or through a speech out program or similar ?
>
> It's kinda non-sense.
No, it's not there's a lot of work done on image description, in any case,
you're being way over simplistic that the issue is only relevant to the
blind.
> Accessibility could be solved by adding more information like
> specifying that <table> is used for layout not for actual table'd data
> for blind people or speech out.
I think you need to do considerable research on accessibility, you've
already shown yourself unwilling to fully read the SVG spec before
pronouncing solutions to problems which are already solved.
>>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.
>
> It is possible already, it's just plain damn painful to achieve.
> Just work out some madness JavaScript or ECMAscript and there you go.
Actually it's not, because the user stylesheet is not exposed anywhere in
SVG, and since you cannot access this you cannot do dynamic positioning
totally safely with javascript.
> BTW, all the 'text content' is created via JavaScript on the fly, without
> any external help.
Oh dear, so it's reliant on javascript, which is a shame in accessibility,
usability, and security terms too.
> >>Do you see people doing that in HTML, no.
>
> >HTML has no layout semantics... in CSS (which I assume you're really
> >discussing)
>
> HTML has layout semantics since decades way before CSS came out.
>
> <center>
Yes, and in modern HTML, such things have been _removed_ because it makes
content inaccessible, or less accessible to modern users, the older
technologies of semantic only HTML and CSS have come to fruition, CENTER
postdates CSS
languages (although widespread take up of HTML 3.2 came before widespread
takeup of CSS)
> >I see a lot of people precomputing bounding boxes, and meeting
> >many positional problems.
>
> Why computing bounding boxes, with HTML <Table>
> the table WILL scale to the largest cell, so there's no need.
I think because most people are now aware that many countries of the world
have requirements to make their content accessible, and TABLE for layout
will generally invalidate any "best practice" defense as it's clearly
described as being inacessible.
> I read two books on SVG and some of the documentation,
> but the big problem is that SVG tutorials looks like
> a cartoonist/flash/animation approach,
Please read the specification, you've missed huge areas (data:, viewbox
etc.) books can miss stuff, and I've never seen a cartoonist tutorial, I've
seen much more in the programming side of SVG than the visual, because many
more programmers get attracted to it.
> >Doug has rightly corrected me in that letters are not simply images, only
> >the images used to symbolise those letters are (the glyphs)
>
> True, but sometimes text-selection should be prohibited temporarily or
> permanently.
> For instance, on buttons or while doing a drag and drop.
What's that got to do with anything? SVG provides such hints, without doing
anything to break the accessibility, your suggestions however do lots to
break accessibility.
> It's like having javascript disabled on a javascript heavy site...
> samething.
I have some hugely javascript heavy sites, and they degrade gracefully, as I
say many people don't have the option of ignoring such users, and there are
many good techniques to include them, the specs are also doing a lot to
support us in this.
> >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.)
>
> NOT OCR, I was talking about having a SVG picture with text not selectable
> by style-sheet let say
> and have an XML babelfish to spit out something like this:
>
> <text>Long life to SVG file format</text>
> translator EN-FR
> <text>Longue vie au format de fichier SVG</text>
That doesn't work... positioning is absolute, therefore the position of a
character of text or word in one block may have little or no relation to the
sentance - please think about it, or look at a few SVG documents.
> But what I was saying even tough you disable the text selection
> the translator could still spit out translated text.
Where did this "disable text selection" come from? I've never suggested it,
such a hint is as you say wholly irrelevant to accessibility.
> >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.)
>
> It doesn't matter if it was defined for what or for who, the point is,
> it works it's used therefore it's the new definition for it. Period.
Your assertion that it works, is unfortunate as the majority of opinion I've
seen has shown convincing argument that it does not - if you would like to
show some evidence to the contrary, I'm sure the WAI groups would be glad to
hear it - I suggest you actually do some background reading first.
> Whatever, I say is practical, I could use it yesterday to do some serious
> application stuff
> instead of using SVG for stupid cartoonist scalable animation crapt.
I do application stuff in svg (image annotation, presentations, maps etc),
SVG's can't do accessible applications yet, but it can't do a lot.
> So, it's a problem for database
> generation without gzip compression
Well doing the gzip would seem the easiest solution, after all, it's trivial
to implement in apache, and IIS 5 for example)
> >No, as we've discussed, this is already provided for in SVG! data:
viewBox
> >etc. etc.
>
> I couldn't find any PERFECT bitmap image converter to SVG.
That's because bitmaps are not vector data, SVG is.
> Anyway the following stats might prove my point:
> MSIE 5 5894 53.46%
I assume these are trillions or something, as anything else is much too
small to be from a relevant source.
> >HTTP response codes in the region of 300-309
>
> I rarely got across those code, mostly 404 and 500 stuff.
> What are those for?
Please read specifications, they really are the place to start.
> Okay, but I don't care about line modes neither,
> some other might perhaps.
So because you don't care the specs should ignore those?
Jim.