Re: [SVG] Experiment and proposal

>>However, how do you proceed to have SVG images layout without FIX size?

>What exactly do you mean, what are you trying to achieve? SVG images don't 
>have a fixed size, yes one rectangle is fixed in its size relative to
>another, but when marking up an image, that's kind of important, the 
>meaning of the image could change alarmingly if you allow that (I created 
>an example for a related
>problem: http://jibbering.com/2002/8/text-mixup.svg )

Can be resolve in XHTML easily:

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

In SVG/XHTML it could look like this:

<table border="0" x="100" y="100" height="100" width="100">
<tr>
<td><text>The</text></td>
<td><text>Cat</text></td>
<td><text>Sat</text></td>
<td><text>On</text></td>
<td><text>The</text></td>
<td><text>Mat</text></td>
</tr>
<tr>
<td><text></text></td>
<td><text><use link:href="#cat"/></text></td>
<td><text></text></td>
<td><text></text></td>
<td><text></text></td>
<td><text><use xlink:href="#mat"/></text></td>
</tr>
</table>

Image could scale inside a TABLE or for the matter
it could scale inside a boundary image
i.e. a rectangle, circle, triangle or weird form

That code would scale and FIX your problem easily.
Table have been used since years to layout text,
why shall that change?
People are used to it.
I'm not against providing weird text
formating inside shape tough?

>>However, why does SVG1.2 try to redo XHTML layout stuff
>>in a 'different' way ?

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

You could use something like:

<shape xlink:href="#cat" align="bottom" x="100" y="100">
<text>Dog</text><use xlink:href="#dog"/>
</shape>

and therefore have a dog text and picture
inside a cat shape bordering aligned on the border line?

>>What about having SVG items
>>being layout not statically but dynamically?

That's an example.

>Other than a basic grid (to save you having to precalculate the BBoxes) 
>what
>else do you want?

I want to be able to display stuff as EASY
as possible like it is currently for HTML.

>> >But you do this in your authoring application and NOT (usually)
>> >on-the-fly in the JS/DOM of the SVG...
>>
>>I'm not using any tool, I'm using a basic editor,
>>and my SVG graphics will be generated by scripts using data
>>from a database back-end not an authoring tool at all.

>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,
how can I assume that the text delta is 5,15,20,60 pixels
or less or more the distance between stuff, etc. WHY?

Do you see people doing that in HTML, no.
So why should you calculate such stupid things in SVG,
it doesn't make sense, at least not to me.

>>>SVG fully supports all of that...but none of that effects the
>>>layout because it's based on fixed positions and mathematical
>>>transformations for scale/zoom INSTEAD of content reflow/relayout as 
>>>XHTML is.
>>
>>I mean resize and having your component resize!

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

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

Well, if letters are images,
a set of letter is also a set of image
and therefore, an image. =P

I agree for translator like babelfish, but anyway,
the point is you should be able to display it in SVG easily.

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

The stylesheet is defined within SVG,
so it doesn't make sense.
Also, an SVG document could be
translated by some XML babelfish anyway.

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

Yes, to layout text and images and SVG components.

>something which is not defined for.

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

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

Is there a way to join the group with a Yahoo account?
I forgot how to do it.

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

I don't think so. It would be very nice to have.
Even Adobe was planning to had <table> mark-ups
announced in the svg-developper Yahoo mailling list.

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

I forgot about that one, it's one way to do it. =P

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

I think, I'll use the data: png stuff instead.

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

Question is why not?

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

Well, any graphics in pixel designed size
will look awful on any such device.

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

I'm from low-bandwidth too, 56kpbs ?
You got what a 2400bps or 14400bps modem?
I used to browse the net with it decades ago. =P

>> >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, but the problem is that some of it might have been design
to have some parts in bitmap and some other parts in vectorial object.
My point with the dot thing is to be able to mix both, without having
to embed an entire image.

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.

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

Exactly, it needs to have form and similar XHTML stuff.

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.

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

>[*]  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. =(

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

<EMBED> == <OBJECT> in new HTML specs.

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

Any URL or source code?

>>>With meta refresh regularly  disabled this would seem very silly - even 
>>>if
>>>it was the case, a 30* response

What do you mean by 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.

What's a line mode browser? Something like lynx or cellphone???

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

Do you have any other proposition to solve the issue?

Sincerely,
Fred.

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*   
http://join.msn.com/?page=features/junkmail

Received on Friday, 18 April 2003 22:59:48 UTC