Re: [SVG] Experiment and proposal

>>>It's not the DISPLAY of the text/tables, but the LAYOUT of them!   
>>> >Layout of tables, esp. those that support all of the features of XHTML 
>>>is quite complex, and that belongs to the XHTML formatter.   There is 
>>>already a way for SVG to "drop out" to other XML renders, which is the 
>>>correct way to handle this.
>>What do you mean by "drop out", please provide code samples
>>or links or something proving your point, because I don't
>>understand what you mean here.
>         It's the <foreignObject> tag in SVG (see 
><>), however, 
>the current version of the Adobe SVG viewer doesn't support this tag - 
>though other viewers or future updates might/will.
>>Anyway, how do you handle displaying something that mix
>>XHTML/SVG a LOT in a non easy way.
>The correct way is using <foreignObject> - but that doesn't mean that you 
>can do it today.

That looks good enough for me, now but when it's gonna be supported? =P
For text embedded.

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

>>Currently, this would mean
>>that alot of SVG and XHTML and DHTML and JavaScript
>>would have to be used in a very complicated way to provide
>>text layout and graphics layout in a moveable PDF fashion.
>         PDF doesn't support movement of content, since unlike SVG content 
>is not exposed to the JavaScript DOM in a PDF file...

True, well, I mix up things here.
but <foreignObject> could fix the issue I agree.
However, why does SVG1.2 try to redo XHTML layout stuff
in a 'different' way ?

What about having SVG items
being layout not statically but dynamically?
How does this works? Are you telling me
I have to use JavaScript to do such thing?

>So if you are comparing against PDF, then I don't understand.  For static 
>documents, PDF and SVG are equivalent though the use of explicit position 
>of ALL objects (text, vectors, rasters, etc.).  For dynamic documents, SVG 
>has the DOM but PDF does not.
>>I mean if you gonna write a SVG viewer engine, then you probably
>>have the skills to write a proper XHTML layout engine at the same time.
>         Not at all!   SVG is MUCH easier than XHTML because it's all 
>fixed/explicitly positioned elements, while XHTML is a completely dynamic 
>(ie. on-the-fly layout) system.   It is therefore MUCH more complex to do 
>XHTML, esp. for non-Roman languages.

Well, XHTML support non-Roman language also. =P

>>I mean having to calculate the height, width, spacing
>>manually for each line of a paragraph is kind of overkill.
>         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.

We use SVG for different purposes, my point was that
since SVG is XML based, it's easier to generate graphics
from a database back-end then if it was binary like a PNG graphic.

The other way is through GD which also
suffer anti-aliasing font problem.

>>Not to mention having simple stuff like
>><center> or "text-align: center;"
>         text-align:center is fully supported in SVG.
>>Not to mention that having flexible table makes the SVG image
>>"flexible" in height-width and size, therefore making it more scalable.
>         That seems to be the point you are missing.  SVG (today) is NOT 
>about dynamic layout (as XHTML is), it's about static/fixed layout of 
>elements - that could potentially reposition themselves.

Fixed layout is a good start,
dynamic layout is a very useful supplement.

Combining both, makes it much more flexible, then only static layout.

>>Basically, I want to have LAYOUT FLEXIBILITY inside SVG itself =)
>>- Zoom in/out
>>- Resize
>>- Move
>         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 

I mean resize and having your component resize!
Think of it like an XHTML page that resize the layout stuff
as you resize the page dynamically.

>I think once you understand that the two are different systems for 
>different purposes, you'll go further with both...

Doesn't mean that SVG should NOT be extended,
because new appliance are possible with it.

Before I was considering something called GXL,
but SVG seems to be much more powerful and it is,
now how much more powerful can it get that's the question!

>>>         You can embed bitmaps just fine in SVG using CDATA sections.
>>>Adobe Illustrator (and other SVG authoring apps) give you that option.
>>I don't have Adobe Illustrator, so I dunno about it.
>         So what are you using as a graphic editor for SVG to help you 
>author and understand what can be done?
>>Provide a link or code sample showing this,
>>I really want to see how this is done.
><image width="61" height="69" id="ldr_head_shot.png" 

That works fine for me, I agree,
now I need to find a tool to convert images in Base64
on *nix and windows.

Still, the "D x y" dot syntax still makes sense as far as I'm concern.


Help STOP SPAM with the new MSN 8 and get 2 months FREE*

Received on Tuesday, 15 April 2003 20:34:58 UTC