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 
><http://www.w3.org/TR/SVG11/extend.html#EmbeddingForeignObjects>), 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 
>is.

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" 
>xlink:href="data:;base64,/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHgAA/+4ADkFkb2JlAGTAAAAAAf/b
>AIQAEAsLCwwLEAwMEBcPDQ8XGxQQEBQbHxcXFxcXHx4XGhoaGhceHiMlJyUjHi8vMzMvL0BAQEBA
>QEBAQEBAQEBAQAERDw8RExEVEhIVFBEUERQaFBYWFBomGhocGhomMCMeHh4eIzArLicnJy4rNTUw
>MDU1QEA/QEBAQEBAQEBAQEBA/8AAEQgARQA9AwEiAAIRAQMRAf/EAT8AAAEFAQEBAQEBAAAAAAAA
>AAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUD
>DDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1Rk
>RcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX
>5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MV
>Y3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpam
>tsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8Ays2o14lgL98Fv5Vi91t5rHs6e/fBO5sEa6ar
>EjVIJdr6uAetadPod/itazNorcBukjkD+9c9091zQ6rHaXXXwxg/ElXm9A6wbAwtnxIOmqjIF3Ip
>ESdg6TeqY7nDdI7SNeVbbY1/uaZHio4n1M3snIydro4YNAq1dNvTMx3TbiXuGtbz+c1IgVokxI3b
>X521H2fo9m0+qNOdI5Q94Ba7SR2hG9Wz+c7oIee6q0HBf5OaFgO1PxXQdRbYzpzhY4OdvExoufPZ
>SBDpdFZb9tpePa0bpd24ldbV1nBreK3EuPBPGq5jo+QytrWv1iyB/abC3LzgVtbkWNDYIJMfwTJb
>s8Nt3VHXun1W+k8uDvGNFQ6ux1/WMa5hD6/ScZHhJAlE39K6hkfaK4eNATEQ5o7hSyLaxkjHrEBl
>YmPNxKCphBDZIPPClt02yZ8VAn3aKXuiYQYXJ60C3AIPd4XOATC6PqGNkfYHtfa+95c3aHchZA6a
>9rd1rwz+SNSpQrZjUfTxzdMFj2ENPLo5hXWZdPULoeHe1vtZuie6n0jEx8q20Wjc6pn6Nh410JVP
>K6RfTaTQTE6Qmki6K+IkNRq6JuxsRtWSxj6bN0+mX7gW8GYhXcbNZkG/NJ9Ot21jZ8gsTF6Vm5do
>Fp2s7k6wFZ6hh0ty7cWpxFO1ktB+i4CP96Wh0BVLi3Ip1sfPwbbPSqua6wCYn+9Wt5mO/wAFxb+l
>5lDt9QNgBlrmHX7l1HqW/Yd//aj0p2990IGFEarHJycu71CC4nuFTsvvZ7mjcD9IFK682w/uNCma
>6dDqFMoL4uf9lyW3tmlwMgHUFp5C7HCvwOqV+rVtLh9NgOrVxrq2v5CJhG3EyWW47tlg4MwCPAps
>oCS6MuF6zqWRjdNoioA5Lx7B+6P3iuX+0VtJO422vkvcNZJ5koN92Rl3PsvcZcZI/wBeyJW1rQA3
>RKMREIkSd2xVdZEkweyL9pt2ETrxPkqwKfcOJEzMJy1pGNp8I0SrmEkklBMJTGY1+SSSSVtYE8wn
>bPZJJJSQzHmqfv8AtPeYSSSU/wD/2Q=="/>
>

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.

Sincerely,
Fred.


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

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