- From: Fred P. <fprog26@hotmail.com>
- Date: Tue, 22 Apr 2003 03:28:57 -0400
- To: www-svg@w3.org
- Cc: Jon.Ferraiolo@adobe.com
Still, I still think that XHTML should be allowed
via xmlns in svg, especially by the commonly used Adobe SVG viewer.
Refer to http://groups.yahoo.com/group/svg-developers/message/27747
>> >(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.)
I agree it may be annoying for a blind person to have speech out,
but that's quite a minority, worst case simply put it:
summary === "layout"
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.
I hope Adobe SVG Viewer will support something like:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20001102//EN"
"http://www.w3.org/TR/2000/CR-SVG-20001102/DTD/svg-20001102.dtd">
<svg width="300" height="300"
xmlns:xlink="http://www.w3.org/2000/xlink/namespace/"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<xhtml:table><xhtml:tr><xhtml:td>
<text>hello</text>
</xhtml:td></xhtml:tr></xhtml:table>
</svg>
that would be enough for most of us,
with all border, CSS and table attributes.
This would mean I could create a web-based Word 2000 clone
inside SVG using SVG graphics, <text>, <table> and pure javascript!
>>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.
worst case scenario ensure a viewbox or similar inside <TD>
>>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.
Inappropriate for web use let me laught.
Tell me a single non-trivial non-stupid non-completely-flash
web page where <table> are not used anywhere for transparent text layout.
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.
something like <table layout='true'>
or simply detect <table border='0'> that's quite a good hint!
>>>XHTML has very few layout semantics, and none in its strict versions,
>>>it's not 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.
<div> I agree is not needed.
>>>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.
It is possible already, it's just plain damn painful to achieve.
Just work out some madness JavaScript or ECMAscript and there you go.
Basically, you are asking me to produce some good damn crazy JavaScript
to fix the problem instead of having the SVG browser doing the layout.
BTW, all the 'text content' is created via JavaScript on the fly, without
any external help.
i.e. Someone type KeyPress/KeyDown or use MouseMove,MouseOver,MouseOut
SVG is dynamically authored on the web live,
the only external help is to load/save the file back to database via
PHP4.
Howerver, since it's only client-side JavaScript, it's quite damn
blazing fast tought
and the server has little to do.
>>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.
Not textLength.
/\
||
||
\/
How do I know how big is this height?
How do I know how much space I need between words to make it text-justified?
>>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> <div align='left'> <div align='right'> <div align='center'> and
transparent <table>
You don't have perhaps justify or 1.5 interline, probably new version of CSS
has it, I'm not sure of that.
I couldn't find any of that few years ago tought.
The following works on Netscape4 but does NOT work on IE5.5
<FONT FACE="Arial" style='text-align: justify;'>In order to deliver the huge
amount of calculation and processing power required, the control system must
be able to support different kind of micro-processors. It must also be able
to support different kind of data bus, address bus and control bus, so that
all these components can interact with one another.</FONT>
>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.
>>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_.
Yes, this is something cool, but you will get identical rendering on bitmap
too.
And scalable rendering on standard HTML.
>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. *
No, even with layers it doesn't matter and works well,
since the viewer move the entire thing not just one layer,
while you can move one layer in between like the w3c svg testbench.
>>>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.
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,
I'm trying to do some 'SERIOUS' work using SVG, not funny stuff.
>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)
True, but sometimes text-selection should be prohibited temporarily or
permanently.
For instance, on buttons or while doing a drag and drop.
You don't want a user to highlight text on a damn button or picture,
this is a side-effect glitch, not a feature.
>> >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.
Might be the case, but if someone does this then the page won't work,
and it's not my problem; therefore, I don't care.
It's like having javascript disabled on a javascript heavy site...
samething.
>>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.)
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>
But what I was saying even tough you disable the text selection
the translator could still spit out translated text.
>>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.)
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.
I hope SVG will EXCEED way more what the definition says
since this means that SVG will be a HUGE success.
Never heard the sentence:
"The student go further then the teacher"
>>>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.
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.
>>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.
Your out of topic, my point was to efficiently transfer bitmap picture
into SVG without embedded PNG data stuff using a "D x y" syntax.
i.e.
<rect style='fill:#c0c0c0' x='2' y='2' width='1' height='1'/>
to be equal to a future DOT operator in path:
<path style='fill:#c0c0c0' d='M 2 2 D 1 1'/>
or maybe just:
<path style='fill:#c0c0c0' d='D 2 2'/>
I'm currently using <path> or <rect> both works fine,
compressed it's damn efficient more than
BMP or PNG data by a factor of 1/3
-> 217KB of PNG
= 72KB of SVGZ with inefficient <rect>
= 1580KB in SVG uncompressed.
So, it's a problem for database
generation without gzip compression
from the download time aspect mostly
why 'D x y' would be nice to have.
See:
http://j2k.sourceforge.net/svg/btn_all4.svgz
http://j2k.sourceforge.net/svg/umled10.htm
All .bmp files: 212,078 bytes
All .png files: 212,707 bytes
All .svg file: 1,532,864 bytes with rectangular Y-axis height compression
with no X-axis width compression
All .svgz file: 70,792 bytes with gzip -9
Previous one with umled10.svg included
BTN_ALL4.SVGZ 77,077 bytes
BTN_ALL4.SVG 1,579,313 bytes
Even tough with don't have "D x y", it's still efficient after compression,
more than it would be with pure bitmap files.
In other words, it's more efficient to store icons
inefficiently using svg+xml <rect> with gzip and Y-axis encoding
than pure bitmap files!
i.e. <rect style='fill:#808080' width='1' height='10' x='1' y='4'/>
where height,x,y,fill changes.
>>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.
I couldn't find any PERFECT bitmap image converter to SVG.
For instance, I would REALLY love to see something that takes BMP/PNG/GIF
and translated them into perfect SVG that would SCALE up without
the pixel sickness, BUT are IDENTICAL at the pixel zooming level.
i.e. something that takes [] = Pixel
[][]
[] []
[] []
[][]
And figure out that it is a circle of 4 pixel diameter
and produce EXACTLY this PIXELIZED picture at pixel level with ZOOM=100%,
but draw a nice circle in ZOOM IN mode (e.g. zoom=800%).
Samething for other shapes using <path> or <rect>.
I draw myself the SVG icons in
http://j2k.sourceforge.net/svg/umled10.htm
But I converted stupidly the other SVG icons at
http://j2k.sourceforge.net/svg/btn_all4.svgz
using a batch file doing
bmp2png -0 icon.bmp
perl png.pl icon.png
...
followed by:
copy /b icon1.svg+....+icon200.svg btn_all4.svg
gzip -9 btn_all4.svg
ren btn_all4.sv* btn_all4.svgz
>>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?
You might think I'm crazy, but I'm very damn serious dude.
Wait a little and you'll see it live! =)
It's more than a PROOF of concept,
in fact it will be part of concept [word play].
>> >[*] 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.
I trust your word for that.
I use Netscape 3/4, IE 5.5 mostly.
IE6 and Netscape 6 at work.
Rarely, Lynx, Konqueror or Mozilla on RedHat.
More rarely, Voyager browser on QNX6 (www.qnx.com)
Anyway the following stats might prove my point:
MSIE 5 5894 53.46%
MSIE 6 1921 17.42%
Netscape 4 1759 15.95%
Netscape 7 562 5.09%
MSIE 4 440 3.99%
Netscape 3 308 2.79%
Other 56 0.50% (considered statistical noise?)
Opera 6 17 0.15%
Opera 5 8 0.07%
AOL 4 6 0.05%
MSIE 3 3 0.02%
WebTV 1 1 0.00%
Netscape 23.84% - MSIE 74.90% - Other 0.79%
Windows 85.86% - Mac 0.96% - Unix 8.89% - Other 4.27%
Imagine for a POSIX/QNX/LINUX website project most visitors are using
Windows!!!
IMHO, if it works on Netscape3/4/6/7 and MSIE 4/5/6, it's fine with me.
If it works on other browser then it's great, but not really my concern.
Just look at system tracking stats for websites on Googles:
http://www.google.ca/search?q=t-extreme.dm
>>>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.
whiteboard? plz give a link!
>> >>>it was the case, a 30* response
>>
>>What do you mean by a 30* response?
>HTTP response codes in the region of 300-309
I rarely got across those code, mostly 404 and 500 stuff.
What are those for?
>>>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.)
Okay, but I don't care about line modes neither,
some other might perhaps.
>>>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.
I got bunch of PHP manual, I looked on PHP.net and google,
I'll see later about that, currently I used pure Javascript.
Anyway the refresh thing works so it's okay for me.
Don't put quote mark at the bottom it's annoying use brackets instead
like this [additional info].
>* 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.
BTW, I found on the dev-list, optimizeSpeed;
that fixed my anti-aliased text/shape sickness problem! =)
Still, I'm gonna use normal pixel for shapes tough,
looks like a more garanteed safe approach than shape-rendering,
for user-side defined CSS properties?
<text x='120' y='93.5'
style='font-family: Arial;
font-size: 12;
text-rendering:optimizeSpeed;'>
Function
</text>
<rect x='300' y='180' width='100' height='20' style='fill:#c0c0c0;
stroke-width=1; stroke:#000000;
shape-rendering:optimizeSpeed;' />
Sincerely yours,
Fred.
_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
Received on Tuesday, 22 April 2003 03:29:04 UTC