[Seaside] SVG design questions

[Marcin Tustin]

I'd be interested in having a play with the code as well. It looks like this
is all your own hand-rolled stuff, right?

On Wed, Apr 9, 2008 at 11:22 AM, Gerhard Obermann <obi068 at gmail.com> wrote:

> Hi!
>
> It looks very cool, so please create a squeak package on squeaksource and
> assign me as developer!
>
> AFAIK Inline SVG hast too many drawbacks (especially on IE), so the main
> goal should be the rendering for linked SVG documents.
>
> BTW: Which version are you using!
> I think it should be developed for Seaside 2.9!
>
> br
>
> Gerhard
>
>
>
>
> On 4/9/08, Lukas Renggli <renggli at gmail.com> wrote:
> >
> > Hi Holger,
> >
> > Gerhard is also interested working on that. So I suggest that you
> > collaborate ;-)
> >
> > >  The first issue is the canvas. Subclassing the existing canvas seems
> > to be
> > > a bad idea:
> > >  - SVG has an extensive set of tags. Combining this with the extensive
> > set
> > > of HTML tags will end up in one large bulky mess
> > >  - the SVG anchor has the same tag as the HTML anchor, but requires
> > the
> > > xlink namespace for the href attribute, so it requires a different
> > anchor
> > > brush
> > >  - SVG and HTML cannot be freely mixed, so it's not necessary to
> > combine the
> > > both in a single class.
> >
> > I suggest that you create your own "namespace" that you can retrieve
> > from the html canvas. This would be an object that knows the
> > underlying rendering context, but only has the SVG relevant methods.
> >
> > So that you can write:
> >
> >   html svg line
> >      from: 1 @ 1;
> >      to: 100 @ 100
> >
> > Or for embedded SVG rendering I imagine writing something like:
> >
> >    html svg: [ html renderSvgOn: html svg ]
> >
> > Where renderSvgOn: would look like:
> >
> >    renderSvgOn: svg
> >       svg line
> >          from: 1 @ 1;
> >          to: 100 @ 100
> >
> > >  Currently, I've subclassed WACanvas, not WARenderCanvas. Rendering
> > inlined
> > > SVG will require switching the canvas. Currently I see no problems
> > here, but
> > > maybe I'm wrong.
> >
> > I think that's the way to go.
> >
> > >  Another issue is inlining SVG vs. separate SVG documents. Quite often
> > I've
> > > seen some caveats about inlining SVG (e.g. see
> > > http://wiki.svg.org/Inline_SVG). On the other hand, I see some
> > disadvantages
> >
> > I have no experience with that.
> >
> > I think inlining seems simpler to start with. Have a look at the
> > #iframe brush to see how to create a specific document as part of the
> > page.
> >
> > >  Embedding with <object>
> > >  -----------------------
> > >  I've tried to implement rendering of external SVG documents that are
> > > included as <object> in the HTML document, and kind of succeeded:
> > >
> > >  http://www.smallish.org:7777/seaside/SVG/example
> >
> > Wow, that looks already very cool.
> >
> > Cheers,
> > Lukas
> >
> > --
> > Lukas Renggli
> > http://www.lukas-renggli.ch
> > _______________________________________________
> > seaside mailing list
> > seaside at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> >
>
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20080409/b95d10b1/attachment-0001.htm