Re: The coming of SVG
On 2017-11-10 18:50, David Bovill via use-livecode wrote: I don't think this would help (below). What is nice is to be able to use professional illustration tools, and then add hypertext links to one of the objects in the svg with built in tools - for instance using Graphic, or OmniGraphl). That way you can create complex beautiful (and scaleable) interface elements working with artists. Later you can also use javascript to dynamically alter the links by referencing the node in SVG - again working with externally created SVG. I don't see how to do these things if it is not possible to support events / links as per the TinySVG spec? - https://www.w3.org/TR/SVGTiny12/linking.html - https://www.w3.org/wiki/SVG_Links Elements of interactivity and animation have been on my mind with regards SVG - indeed, we can get very far with the pre-compilation approach that we are currently taking. For interaction to work it will be necessary to annotate the SVG file to explain which elements you want to receive event notifications for, and which SVG attributes/properties you want to be able to manipulate at runtime. For animation, it requires grokking and processing the SMIL elements/attributes which the full SVG Tiny spec defines. I must confess I hadn't yet worked out how those annotations might be applied from an illustration tool - but you've just given me that missing piece :) Kinda obvious now, but we can use hyperlinks on the SVG elements, which such tools do allow you to set - so no post-processing of the SVG by a human would be required. So, I have an idea/plan on how to do this - so it is a case of when and not if. The only bit this would not allow would be the ability to add/move/remove elements from the tree, or set attributes/properties which are structural (e.g. gradients can inherit from other gradients in SVG 1.1). However, that is not necessarily too much of a blocker here - as you can have all the elements you need present in the tree at the point of creation, and just control their display by the visibility attribute. To get full interactivity like you get in browsers would require implementing a dynamic SVG canvas - which sounds like an interesting and useful path for the previously mentioned 'canvas' control idea... Warmest Regards, Mark. -- 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
Re: The coming of SVG
On 2017-11-10 18:25, hh via use-livecode wrote: PLEASE, let us first have the basic enhanced object, probably "canvas". This will need at least a full year (my estimate). Well, let's first have the ability to display SVG :) My current approach (as I said previously) is to integrate SVG support into the image object. So you will only need to set the text of the image to an SVG (filename references are going to be a bit more of a pain as the PICT/EMF support in the image object never supported being in separate files, annoyingly). Indeed, I've been working on changing our internal vector graphics API (libgraphics) to have all the fundamental operations to render SVG (that 1-1 correspondence I talked about before), and a new Metafile graphics object type - which the image can then use to render SVG, after processing them with the SVG type. This should also allow exposing of an SVG/Metafile type object in the LCB canvas, so widgets will be able to render them easily also. Beyond that, I've been trying not to get distracted by the idea of the 'canvas' control which evolved from this thread - but will return to it when possible :) Warmest Regards, Mark. -- 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
Re: The coming of SVG
On 2017-11-10 19:02, hh via use-livecode wrote: @David. You respond to my answer for jbv (relating SVG-animation). The answer for you is two paragraphs upwards, a LC stack: http://forums.livecode.com/viewtopic.php?p=129274#p129274 The algorithm there allows you to get the clicked shape. That's all you need for setting clickregions of an image which are defined (whether SVG or not) by shapes (or their points/oulines). Just the same algorithm is used internally by the SVG tools. And the engine (it hit-tests graphic objects in a similar fashion) - although there are some flaws / issues as recently noted about oval segments! The geometric approach will always* work - but does require increasingly complex math to do as fidelity requirements increase, indeed to implement hit-testing correctly for a stroked path requires a lot of care to numeric error and due to the end-caps and joins (round causes no problems - as then its just the standard 'is within half the stroke width away from the path - but miter and bevel are quite a bit more complicated). Then you might have masks, clips, and raster images to take into account too - not to mention fill rules, blend modes and transparency layers. Indeed, to do that kind of hit-testing you have to basically replicate what the graphics engine is doing under the hood - so it would be best to leverage all of that if possible... A perfectly viable method is to actually use rasterization to perform hit-testing: 1) Create an offscreen canvas 1x1 pixel in size 2) Translate the canvas so that the 1x1 pixel is aligned with the mouse position 3) Make sure the canvas is cleared to transparent black (i.e. pixels are 0). 4) Render the complex graphics will all paints as opaque white 5) If the single pixel in the canvas is white, then the complex graphics has been hit, if it is transparent black it has not. This way you can be guaranteed that the hit-testing is done against precisely what the user sees - you can even easily give an expanded hit area. If you want hit to be true if within N pixel radius of the mouse, then render to a NxN canvas centered around the mouse location then blur/spread the result with a radius of N and check the center pixel. (or just check to see if any of the pixels in the NxN canvas are set - slightly simpler!). You can create offscreen canvas's with LCB, so this is all possible with what already exists - indeed, I'm sure there was some code around somewhere to show how to do it for an arbitrary path: https://github.com/livecode/livecode/pull/4358 Warmest Regards, Mark. * 'always' assuming infinite precision numbers, which obviously don't exist. There are lots of cases (particularly with paths) where intersection math can 'blow up' and not give reasonable results - particularly when arbitrary affine transforms, and self-intersecting paths are involved. -- 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
