Mark one of the most important applications of SVG / canvas object implementation is the ability to create rich interactive graphics - not simply imagery. It is realy hard with any technology other than SVG / Canvas to attach events or hypertext links to a complex area of an image. Using SVG's you can easily add links to create image-maps that scale beautifully allowing you to create complex control panels and the like.
Would it be possible to add simple events to areas of the Canvas object - even if this is by adding href links that can be set only using the text property of the object? On 9 November 2017 at 16:08, Mark Waddingham via use-livecode < use-livecode@lists.runrev.com> wrote: > On 2017-11-09 15:13, hh via use-livecode wrote: > >> @Mark. >> >> You wrote several times >> >> "... the LCB canvas abilities ..., which are a superset of the HTML5 >> Canvas abilities" >> >> It is just now more "planned to be a superset"? >> >> The HTML5 canvas has for example the ability to set and get dataURLs. >> And LCB doesn't even have a base64 encoder/decoder. >> > > It is already superset in terms of anything the HTML5 canvas can draw, the > LCB canvas can draw. > > Specifically, the LCB canvas is a superset because it also supports > transparency layers with local opacity, local blend modes and bitmap > effects. > > The way you can get image data in is not quite the same as HTML5, > admittedly: we have from binary data, local files, resource files and pixel > data whereas HTML5 allows referencing image-like elements, remote URLs and > data URLs. (The latter are subsumed by the 'with data' constructor for LCB > images though). > > Ignoring images for the moment, the critical API differences are that the > HTML5 canvas allows specifying distinct fill and stroke paints - which are > used for 'fill' and 'stroke' operations. > > The latter I've already done a rough patch for here: > > https://github.com/livecode/livecode/pull/6099/commits/3c706 > ad92dff07f6db23fb24e3755e18fe30f011 > > This adds fillPaint/strokePaint/fillOpacity/strokeOpacity properties; a > 'draw' command; the notion of 'no paint' and a transform property. The fill > command uses the fillPaint, the stroke command uses the stroke paint and > the draw command fills (if the fill paint is not 'no paint') then strokes > (if the stroke paint is not 'no paint'). The transform property allows you > to specify the transform to be applied since the last 'save' - this means > you can change the current (local) transform by setting a property rather > than doing a little save/restore dance. > > I must confess that I'm less interested in parity with the HTML5 canvas > (which one can always assume will be a subset of SVG capabilities) than > parity with SVG. > > It seems a little silly to me that the HTML5 Canvas element has *not* been > 100% based around what operations you need to render a suitably processed > SVG file - particularly as all the major browsers support a large majority > of all the existing SVG specs (and so, by extension all the major browsers > must have 2d graphics support which is 'good enough' to render SVG). > (Although, to be fair here, I didn't see that potential correspondence when > I was designing the LCB Canvas API with Ian - so I guess I can't cast too > many aspersions!) > > Critically, you can see the effect of these very small changes to the LCB > Canvas API by looking at the changes it allowed me to make to the > vectoricon implementation (the vectoricon.lcb diffs in the above commit). > With those changes, there is a 1-1 correspondence between canvas commands > and each SVG property and SVG shape element - which means that any sort of > 'metafile' representation of SVG is entirely natural. > > In terms of the image referencing support, then there are perhaps two > missing pieces - the ability to reference an image script object (i.e. an > image object), and the ability to reference a URL. Adding an LCB Image data > URL constructor would be straightforward - remote URLs would be possible > to, but would require a bit more infrastructure (and a callback to use > libUrl). > > In terms of where we are at the moment - the above patch needs a little > more thought. Those initial changes give us a 1-1 correspondence between > flattened SVG (i.e. where it has been converted to a sequence of shapes > with fill/stroke attributes) and the LCB Canvas API; but not (strictly > speaking) a 1-1 correspondence for direct execution of an SVG file (my last > comment on the associated PR there explains that). > > That patch is backwards-compatible (setting paint sets fill and stroke > paints, getting paint gets the fill paint). However, the further change I'd > like to make is three fold: > > - get rid of save/restore, replacing them with begin/end (just without > creating a transparency layer) > > - make all inheritable SVG fill/stroke related properties be 'the value > set since the last begin' or nothing if they haven't > > - add effective forms of all the fill/stroke related properties which > return the *current* value taking into account inheritence > > The above need significantly more thought with regards backwards > compatibility though. > > Looking forward, there are features that full SVG needs which the LCB > canvas does not - so it would be good to add them in the same model; > however, that would be watered down somewhat if the fundamentals did not > match - which is one motivation here (another motivation here, I will admit > is an element of 'structural beauty' which is perhaps, slightly less > pragmatic!). > > So - yes there are a few differences between HTML5 Canvas and LCB Canvas > currently, but there is a clear path to resolving that inline with the goal > of making the LCB Canvas (essentially) an SVG-capable canvas - i.e. > allowing implementation of rendering SVG to be as clean and as simple as > possible; with no points of friction. > > Anyway, in terms of right now, it seems a bit silly to sit here with a > perfectly reasonable SVG implementation which can render all sorts of SVG > files correctly right now whilst we spend time fettling with what are (in > essence) some technical details. > > We already have an object which has the right name for display of > something image-like (the image object); that object already hooks into > icons/imagesources - which is the way the majority of SVG files will likely > want to be used; so pragmatism says that the best approach is to work to > integrate what we have now into that object in a display only way; and then > look to the future to expand what we can do with SVG in LiveCode (e.g. the > 'canvas' control or whatever it might be called). > > Warmest Regards, > > Mark. > > P.S. Could you file an enhancemnt request for 'image from url' - in the > first instance we can certainly implement data urls, remote urls will need > a fair bit more thought and time. > > -- > Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ > LiveCode: Everyone can create apps > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode