Re: The coming of SVG

[J. Landman Gay via use-livecode]

On 1/5/18 9:03 AM, Mark Waddingham via use-livecode wrote:

Take a look in the dictionary under drawingSvgCompile().


I just read this and, not being very familiar with SVG formats, I'm 
confused. Is there a way to use this to provide a larger hit region 
around an SVG?


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

[Dave Kilroy via use-livecode]

Brilliant thanks Mark! :)

Kind regards

Dave



-
"The first 90% of the task takes 90% of the time, and the last 10% takes the 
other 90% of the time."
Peter M. Brigham 
--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
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

[Bleiler, Timothy via use-livecode]

Thank you, Mark.

This is bug report 20832. I included your response in the description.


> On Jan 5, 2018, at 11:54 AM, Mark Waddingham via use-livecode 
>  wrote:
> 
> On 2018-01-05 17:21, Bleiler, Timothy via use-livecode wrote:
>> I’ve been testing this a little and I’ve run into some files that
>> don’t render correctly.
>> I’ve attached a simple example I found on the internet  that contains
>> this info about how it was created - Generator: Adobe Illustrator
>> 22.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 0).
>> When I tried to display this in the image control as described, I get
>> just an outline of the drawing filled black. I’m using Mac OS with
>> Livecode 9.0.0 (dp 11)
>> Have I missed a critical part of the process or should this be filed as a 
>> bug?
> 
> Please do file a bug with the SVG attached as an example.
> 
> In this case, it isn't working correctly because that SVG uses a 

Re: The coming of SVG

[Mark Waddingham via use-livecode]

On 2018-01-05 17:21, Bleiler, Timothy via use-livecode wrote:

I’ve been testing this a little and I’ve run into some files that
don’t render correctly.

I’ve attached a simple example I found on the internet  that contains
this info about how it was created - Generator: Adobe Illustrator
22.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 0).

When I tried to display this in the image control as described, I get
just an outline of the drawing filled black. I’m using Mac OS with
Livecode 9.0.0 (dp 11)

Have I missed a critical part of the process or should this be filed as 
a bug?


Please do file a bug with the SVG attached as an example.

In this case, it isn't working correctly because that SVG uses a 

Re: The coming of SVG

[Bleiler, Timothy via use-livecode]

Oops, I guess we can’t send attachments to the list.

Here is a link to the file I tested.  

https://lovesvg.com/2018/01/cat-5169/



Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo



> On Jan 5, 2018, at 11:21 AM, Bleiler, Timothy via use-livecode 
>  wrote:
> 
> I’ve been testing this a little and I’ve run into some files that don’t 
> render correctly. 
> 
> I’ve attached a simple example I found on the internet  that contains this 
> info about how it was created - Generator: Adobe Illustrator 22.0.1, SVG 
> Export Plug-In . SVG Version: 6.00 Build 0).  
> 
> When I tried to display this in the image control as described, I get just an 
> outline of the drawing filled black. I’m using Mac OS with Livecode 9.0.0 (dp 
> 11)
> 
> Have I missed a critical part of the process or should this be filed as a bug?
> 
> 
> 
> 
> 
> 
> 
> Tim Bleiler, Ph.D.
> Instructional Designer, HSIT
> University at Buffalo
> 
> 
> 
>> On Jan 5, 2018, at 10:03 AM, Mark Waddingham via use-livecode 
>>  wrote:
>> 
>> On 2018-01-05 15:58, Dave Kilroy via use-livecode wrote:
>>> Hi - anyone got news on 'VectorIcon' or whatever it's going to be called? I
>>> was thinking it would arrive with LC (dp11) but it didn't
>> 
>> It did - but not in widget form.
>> 
>> There is a script library which compiles an SVG file into a metafile format 
>> called a 'drawing'.
>> 
>> Then the image object has been prodded so you can set the text of an image 
>> to said metafile data and it will render the SVG represented by it.
>> 
>> Take a look in the dictionary under drawingSvgCompile().
>> 
>>> When using Mark's external that he shared on LC Global I can get it working
>>> in the IDE but it's a no-show on an iOS device (amongst other errors I get
>>> "864,7,1 unable to load sag compiler")
>> 
>> Yes - there was an issue with inclusions in extensions - that should be 
>> fixed in dp11. However, the support for rendering drawings is in the engine 
>> - so you only need to include the drawing SVG compiler library if you want 
>> to compile SVGs on the fly.
>> 
>> 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
> 
> ___
> 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

Re: The coming of SVG

[Bleiler, Timothy via use-livecode]

I’ve been testing this a little and I’ve run into some files that don’t render 
correctly. 

I’ve attached a simple example I found on the internet  that contains this info 
about how it was created - Generator: Adobe Illustrator 22.0.1, SVG Export 
Plug-In . SVG Version: 6.00 Build 0).  

When I tried to display this in the image control as described, I get just an 
outline of the drawing filled black. I’m using Mac OS with Livecode 9.0.0 (dp 
11)

Have I missed a critical part of the process or should this be filed as a bug?







Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo



> On Jan 5, 2018, at 10:03 AM, Mark Waddingham via use-livecode 
>  wrote:
> 
> On 2018-01-05 15:58, Dave Kilroy via use-livecode wrote:
>> Hi - anyone got news on 'VectorIcon' or whatever it's going to be called? I
>> was thinking it would arrive with LC (dp11) but it didn't
> 
> It did - but not in widget form.
> 
> There is a script library which compiles an SVG file into a metafile format 
> called a 'drawing'.
> 
> Then the image object has been prodded so you can set the text of an image to 
> said metafile data and it will render the SVG represented by it.
> 
> Take a look in the dictionary under drawingSvgCompile().
> 
>> When using Mark's external that he shared on LC Global I can get it working
>> in the IDE but it's a no-show on an iOS device (amongst other errors I get
>> "864,7,1 unable to load sag compiler")
> 
> Yes - there was an issue with inclusions in extensions - that should be fixed 
> in dp11. However, the support for rendering drawings is in the engine - so 
> you only need to include the drawing SVG compiler library if you want to 
> compile SVGs on the fly.
> 
> 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

___
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

[Mark Waddingham via use-livecode]

On 2018-01-05 15:58, Dave Kilroy via use-livecode wrote:
Hi - anyone got news on 'VectorIcon' or whatever it's going to be 
called? I

was thinking it would arrive with LC (dp11) but it didn't


It did - but not in widget form.

There is a script library which compiles an SVG file into a metafile 
format called a 'drawing'.


Then the image object has been prodded so you can set the text of an 
image to said metafile data and it will render the SVG represented by 
it.


Take a look in the dictionary under drawingSvgCompile().

When using Mark's external that he shared on LC Global I can get it 
working
in the IDE but it's a no-show on an iOS device (amongst other errors I 
get

"864,7,1 unable to load sag compiler")


Yes - there was an issue with inclusions in extensions - that should be 
fixed in dp11. However, the support for rendering drawings is in the 
engine - so you only need to include the drawing SVG compiler library if 
you want to compile SVGs on the fly.


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

[Dave Kilroy via use-livecode]

he he -  that should be "svg compiler"

Dave



-
"The first 90% of the task takes 90% of the time, and the last 10% takes the 
other 90% of the time."
Peter M. Brigham 
--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
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

[Dave Kilroy via use-livecode]

Hi - anyone got news on 'VectorIcon' or whatever it's going to be called? I
was thinking it would arrive with LC (dp11) but it didn't

When using Mark's external that he shared on LC Global I can get it working
in the IDE but it's a no-show on an iOS device (amongst other errors I get
"864,7,1 unable to load sag compiler")

Regards

Dave



-
"The first 90% of the task takes 90% of the time, and the last 10% takes the 
other 90% of the time."
Peter M. Brigham 
--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
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

[Mark Waddingham via use-livecode]

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

[Mark Waddingham via use-livecode]

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

[Mark Waddingham via use-livecode]

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

Re: The coming of SVG

[hh via use-livecode]

@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.



___
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

[David Bovill via use-livecode]

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


On 10 November 2017 at 17:25, hh via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> > David wrote:
> > It is realy hard with any technology other than SVG / Canvas
> > to attach events or hypertext links to a complex area of an image.
>
> Not this hard in LiveCode Script, see for example
> http://forums.livecode.com/viewtopic.php?p=129274#p129274
> Works in LC 6/7/8/9 and you can use the core algorithm from there also
> in LC Builder/ a widget -- I use it for the 'clickThrough' of certain
> transparent parts of a widget).
___
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

[hh via use-livecode]

PLEASE, let us first have the basic enhanced object, probably "canvas".
This will need at least a full year (my estimate).

Then add other things (you can already now have via LC Script or via
JavaScript in a browser widget):

> David wrote:
> It is realy hard with any technology other than SVG / Canvas
> to attach events or hypertext links to a complex area of an image.

Not this hard in LiveCode Script, see for example
http://forums.livecode.com/viewtopic.php?p=129274#p129274
Works in LC 6/7/8/9 and you can use the core algorithm from there also
in LC Builder/ a widget -- I use it for the 'clickThrough' of certain
transparent parts of a widget).

> jbv wrote:
> Tools for animation of the svg graphics would be great too.
> SMIL is a good example, although it's not supported on every platform.

You could use just now JavaScript via a browser widget, see for example
'AutoDraw_SVGicon' and 'SVG-TextCrawler' (use "Sample Stacks" or
http://livecodeshare.runrev.com/stack/833/AutoDraw_SVGicon
http://livecodeshare.runrev.com/stack/832/SVG-TextCrawler ).

___
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

[jbv via use-livecode]

On Fri, November 10, 2017 2:31 pm, David Bovill via use-livecode wrote:
> Mark one of the most important applications of SVG / canvas object
> implementation is the ability to create rich interactive graphics - not
> simply imagery.

Tools for animation of the svg graphics would be great too.
SMIL is a good example, although it's not supported on every platform.

jbv


___
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

[David Bovill via use-livecode]

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 

Re: The coming of SVG

[hh via use-livecode]

@ Mark.
Once again thanks for such a deep information. You are also a gifted teacher.

I also know from writing kind of a canvas cheat sheet (WIP) that LCB canvas
is already a larger set than HTML5 canvas but there are still a few important
properties missing (some of them we can have from HTML5 canvas using LCS and
JavaScript as 'mediator').

> 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.

Image  from/to dataURL: #20657
String from/to dataURL: #20658


___
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

[Dwayne Short via use-livecode]

+1 vote for Viewer

 

___
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

[Mark Waddingham via use-livecode]

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/3c706ad92dff07f6db23fb24e3755e18fe30f011


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. 

Re: The coming of SVG

[hh via use-livecode]

@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.

___
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

[Mark Waddingham via use-livecode]

On 2017-11-08 18:47, Alejandro Tejada via use-livecode wrote:

By the way, this new control is a LC9 only widget. Right?


Yes - SVG abilities will initially appear (in some form) in 9.

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

[Mark Waddingham via use-livecode]

On 2017-11-08 23:02, Mike Kerner via use-livecode wrote:
I was just reading an article, this morning, about the trainwreck of 
new
gestures to accommodate the X's lack of a home button, and I guess what 
the

author was saying is pretty much what I'm trying to say:  If it isn't
obvious and easy, then it's wrong.  Keep the language on the level of 
what
a grade schooler would grasp and not forget.  If that means we chop 
down
several objects into the graphic object, and just add a "type" 
property,

then so be it.  Most of these other proposals don't keep it simple.


Indeed - this discussion has been most useful in working out the best 
approach here.


The main take home I've got from this thread is that my original idea of 
'picture' was not quite right I don't think - I had conflated two 
things:


  1) The idea of viewing

  2) The idea of definition

We already have a suitable abstraction for (1) - the image object - I'm 
going to re-investigate what it would take to allow the image object to 
reference an SVG file, or have the content of an SVG file set on it as 
the text. This would immediately give us icon and imageSrc references 
with no extra work.


In terms of (2), then I'm heavily leaning towards a 'canvas' control - 
which would essentially be a 'deferred' renderer for a list of 'vector' 
elements (i.e. the shape/image tags you find in SVG). This would wrap 
the LCB canvas abilities directly, which are a superset of the HTML5 
Canvas abilities. i.e. The Canvas control would be the LCS/xTalk-like 
reflection of the lower-level (immediate execution) Canvas abstractions 
(which is very xTalk-like).


In reality (2) needs a bit more design to get right (I've had a number 
of ideas I want to explore before committing to anything), where as we 
already have enough to do (1) usefully, so pragmatically going with (1) 
for right now seems to be the best short-term path.


Anyway, thanks to all of you for your input on this - I'm sure I'll be 
back on this topic in due course :)


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

[Richard Gaskin via use-livecode]

My $0.02 on the three leading candidates:

"picture" -- gets my vote for this proposed object because we have 
decades of precedent well established with Apple's picture ('PICT') 
format, distinguished by the same thing that defines this new object: a 
type of image that can be comprised of vector or raster elements, or any 
mix of the two.


"canvas" -- *might* be a better choice *IF* LC's implementation can 
support at least a substantial subset of HTML's well-known canvas 
object.  Otherwise it just becomes confusing, with unmeetable expectations.


"viewer" -- too general for an image object; everything on screen can be 
"viewed"; a window is already as much a "viewer" as anything else.


Besides, the xTalk world already has a precedent for a Viewer object, 
one that's every bit as general as such a broad term implies:


Gain Momentum's Viewer objects allowed its scripter using that Unix and 
Windows toolkit to view any stack inside a rectangle within any other stack.


Though I doubt it's currently a front-burner project for the team, at 
various times Mark Waddingham has expressed interest in it, 
understandably given the vast range of powerful options it would open up 
for us to add that Gain feature in LiveCode.


Yes, it's in the RQCC:
http://quality.livecode.com/show_bug.cgi?id=2786

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

[Jim Lambert via use-livecode]

Viewer +1

Jim Lambert

___
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

[Mike Kerner via use-livecode]

I was just reading an article, this morning, about the trainwreck of new
gestures to accommodate the X's lack of a home button, and I guess what the
author was saying is pretty much what I'm trying to say:  If it isn't
obvious and easy, then it's wrong.  Keep the language on the level of what
a grade schooler would grasp and not forget.  If that means we chop down
several objects into the graphic object, and just add a "type" property,
then so be it.  Most of these other proposals don't keep it simple.

On Wed, Nov 8, 2017 at 1:59 PM, Devin Asay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Having followed this discussion from digest purgatory while on a
> conference trip, my vote is for “Viewer” as well.
>
> Viewer has these advantages:
>  -  not already a token in either LCS or LCB (that I know of)
>  -  is descriptive of what it does
>  -  is a nice parallel to player, a container for various time-based media.
>
> Viewport is a possibility, but it seems to already have a fairly precise
> technical definition in the computer graphics world.
>
> Canvas is okay, but evokes painting not vector graphics.
>
> My $.02.
>
> Devin
>
>
> On Nov 8, 2017, at 10:47 AM, Alejandro Tejada via use-livecode <
> use-livecode@lists.runrev.com>
> wrote:
>
> Martin Koob wrote:
> what about calling it a *viewer* object which would then
> allow us to view SVGs, images, graphics or any other
> drawing or illustration format.
>
> Actually, I like the name "viewer" too, but if we could use
> the word "viewer" then "viewport" is more descriptive:
>
> https://en.wikipedia.org/wiki/Viewport
>
> By the way, this new control is a LC9 only widget. Right?
>
> Al
>
> ___
> 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
>
> Devin Asay
> Director
> Office of Digital Humanities
> Brigham Young University
>
> ___
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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

[Devin Asay via use-livecode]

Having followed this discussion from digest purgatory while on a conference 
trip, my vote is for “Viewer” as well.

Viewer has these advantages:
 -  not already a token in either LCS or LCB (that I know of)
 -  is descriptive of what it does
 -  is a nice parallel to player, a container for various time-based media.

Viewport is a possibility, but it seems to already have a fairly precise 
technical definition in the computer graphics world.

Canvas is okay, but evokes painting not vector graphics.

My $.02.

Devin


On Nov 8, 2017, at 10:47 AM, Alejandro Tejada via use-livecode 
> wrote:

Martin Koob wrote:
what about calling it a *viewer* object which would then
allow us to view SVGs, images, graphics or any other
drawing or illustration format.

Actually, I like the name "viewer" too, but if we could use
the word "viewer" then "viewport" is more descriptive:

https://en.wikipedia.org/wiki/Viewport

By the way, this new control is a LC9 only widget. Right?

Al

___
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

Devin Asay
Director
Office of Digital Humanities
Brigham Young University

___
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

[Alejandro Tejada via use-livecode]

Martin Koob wrote:
> what about calling it a *viewer* object which would then
> allow us to view SVGs, images, graphics or any other
> drawing or illustration format.

Actually, I like the name "viewer" too, but if we could use
the word "viewer" then "viewport" is more descriptive:

https://en.wikipedia.org/wiki/Viewport

By the way, this new control is a LC9 only widget. Right?

Al

___
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

[Martin Koob via use-livecode]

I was thinking that to view movies or videos we user a *player* object not a
movie  or video object.  So what about calling it a *viewer* object  which
would then allow us to view SVGs, images, graphics or any other drawing or
illustration format.  This way the name is not tied to the data type being
viewed.  The internals of the viewer object would take care of displaying
the assigned object whether using SVG to display SVG paths or image data
etc. 

Martin Koob



--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
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

[Robert Mann via use-livecode]

Hi all, long time not around, but clarity in language is a key point so my 2
cents :

1) I would much favor DRAWING versus image. The core differentation of a
vector image is that it has been drawn versus "shot" by a camera for an
image. That can be physically understood by all. The idea of a vector is
much more technical and designates the technicalities of the coding of the
information.

2) I would make the largest subset of basic commands and property that can
apply both to DRAWINGS and IMAGES common, same name and parameters : 
Example : resize, tilt, position...

3) I would add specific commands and properties that only apply to DRAWINGS
like export into some other format, change size of lines, delete background,
whatever (change fonts, replace colors)

4) Picture is really confusing, so close to image, yet so far from drawing.
Picture is what we actually see on screen… or in museums!

last but not least I find it great that the question is put up, and openedu
up to shared intelligence! thumbs up! Robert



--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
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

[J. Landman Gay via use-livecode]

On 11/7/17 2:01 PM, Alex Tweedly via use-livecode wrote:

On 07/11/2017 19:02, J. Landman Gay via use-livecode wrote:
I believe the objection to using "vector" is because the object isn't 
going to contain only vector graphics. Eventually it will be a 
representation of many different image formats, a sort of catch-all 
that will replace all the existing bitmap and vector controls in the 
future. 

So it's going to be about controls where the *appearance* is important.


Right. Kind of like a...picture.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

[Alex Tweedly via use-livecode]

On 07/11/2017 19:02, J. Landman Gay via use-livecode wrote:
I believe the objection to using "vector" is because the object isn't 
going to contain only vector graphics. Eventually it will be a 
representation of many different image formats, a sort of catch-all 
that will replace all the existing bitmap and vector controls in the 
future. 

So it's going to be about controls where the *appearance* is important.

I vote for "apparition" - just wish I'd thought of it a week ago :-)

-- Alex
(btw - I'm joking - I do not vote for apparition :-)

___
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

[J. Landman Gay via use-livecode]

I believe the objection to using "vector" is because the object isn't 
going to contain only vector graphics. Eventually it will be a 
representation of many different image formats, a sort of catch-all that 
will replace all the existing bitmap and vector controls in the future.


On 11/7/17 12:23 PM, Stephen Barncard via use-livecode wrote:

Well,  the word vector is not to be found anywhere in the dictionary.

*vectorImage*  (we already have newImage and deleteImage messages, and
several properties begin with *image*

*imageVector*  (we already have imageSource imageData and imagePixmapID

*vectorRender*

somehow function and command names look far more important in a classic
boldface serif font.

--
Stephen Barncard - Sebastopol Ca. USA -
mixstream.org

On Tue, Nov 7, 2017 at 10:05 AM, Richmond Mathewson via use-livecode <
use-livecode@lists.runrev.com> wrote:


I have a feeling the name should be one word, probably in camel format,
so that has to be

vectorSomethingOrOther

shartened, presumably, to vSOO

Richmond.



--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

[Stephen Barncard via use-livecode]

Well,  the word vector is not to be found anywhere in the dictionary.

*vectorImage*  (we already have newImage and deleteImage messages, and
several properties begin with *image*

*imageVector*  (we already have imageSource imageData and imagePixmapID

*vectorRender*

somehow function and command names look far more important in a classic
boldface serif font.

--
Stephen Barncard - Sebastopol Ca. USA -
mixstream.org

On Tue, Nov 7, 2017 at 10:05 AM, Richmond Mathewson via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I have a feeling the name should be one word, probably in camel format,
> so that has to be
>
> vectorSomethingOrOther
>
> shartened, presumably, to vSOO
>
> Richmond.
>
>
> On 7/11/17 5:31 pm, Bob Sneidar via use-livecode wrote:
>
>> +1 for vector something or other.
>>
>> Bob S
>>
>>
>> On Nov 6, 2017, at 15:35 , Stephen Barncard via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
>>>
>>> How about just plain vector?
>>>
>>> Or is that a parameter?
>>>
>>
>> ___
>> 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
>
___
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

[Richmond Mathewson via use-livecode]

I have a feeling the name should be one word, probably in camel format,
so that has to be

vectorSomethingOrOther

shartened, presumably, to vSOO

Richmond.

On 7/11/17 5:31 pm, Bob Sneidar via use-livecode wrote:

+1 for vector something or other.

Bob S



On Nov 6, 2017, at 15:35 , Stephen Barncard via use-livecode 
 wrote:

How about just plain vector?

Or is that a parameter?


___
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

Re: The coming of SVG

[Bob Sneidar via use-livecode]

+1 for vector something or other. 

Bob S


> On Nov 6, 2017, at 15:35 , Stephen Barncard via use-livecode 
>  wrote:
> 
> How about just plain vector?
> 
> Or is that a parameter?


___
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

[Stephen Barncard via use-livecode]

How about just plain vector?

Or is that a parameter?
On Mon, Nov 6, 2017 at 13:04 sphere via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I agree with Rick and Jacque.
> Something combined with SVG or vector-image is better.
> Anyone working with images knows (or learns very fast) what svg's are.
> Picture is to much linked to Photo (for me it is the same), if you take a
> picture the result is a photo.
> I would not think for picture at all if i was looking for svg
>
> and i disagree on the word FRAME as FRAME is part of video and movie
> that would make totall confusion
>
> a few suggestions:
> Figure
> Drawing
> Form
> Illustration
> Model
> Reflection
> Replica
> Carbon
> Simulacre
> Similitude
> Representatio
> Appearance
> Semblance
> Shape
> Illiusion
> Vision
> Visualisation
> Envision
> Impression
>
> _
> Sent from http://runtime-revolution.278305.n4.nabble.com
>
>
> ___
> 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
>
-- 
--
Stephen Barncard - Sebastopol Ca. USA -
mixstream.org
___
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

[sphere via use-livecode]

I agree with Rick and Jacque.
Something combined with SVG or vector-image is better.
Anyone working with images knows (or learns very fast) what svg's are.
Picture is to much linked to Photo (for me it is the same), if you take a 
picture the result is a photo.
I would not think for picture at all if i was looking for svg

and i disagree on the word FRAME as FRAME is part of video and movie
that would make totall confusion

a few suggestions:
Figure
Drawing
Form
Illustration
Model
Reflection
Replica
Carbon
Simulacre
Similitude
Representatio
Appearance
Semblance
Shape
Illiusion
Vision
Visualisation
Envision
Impression 

_
Sent from http://runtime-revolution.278305.n4.nabble.com


___
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

[Ben Rubinstein via use-livecode]

On 06/11/2017 16:52, Mark Waddingham via use-livecode wrote:
In any case, introducing a new control (which is far more than an image) in 
the first instance doesn't stop it at some point 'feeling' like an image from 
the point of view of script in the future so it seems like a getting the 
control into existence first is the best approach.


From every other consideration, I'd agree. My only thought is that if it 
could be so well developed that on introduction it already subsumes all the 
current functions of the 'image' control, that would provided a very nice 
resolution to the name question.



Is this a mad dream?


That depends on whether it involves saying wibble, a pair of underpants and 
two pencils...


Call that mad? I've had much crazier than that...

Ben

___
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

[Mark Waddingham via use-livecode]

On 2017-11-06 15:34, Ben Rubinstein via use-livecode wrote:

This might be a stupid question, but might it be possible for this new
control to completely replace the existing image control?


It isn't a stupid question...


There aren't very many special properties relating especially to
images. If the new object implemented those at least to a first
approximation, then perhaps it could simply be called "image". All
existing uses of images would work, and the gloss would be that the
image object had gained some exciting new capabilities.


The way to look at it is that there is some 'abstract interface' (i.e. 
collection of properties and commands etc.) which are what makes an 
image imagey - then any control which implemented them *could* be 
considered an 'image' (from the point of view of the chunk).


There's certainly something there in terms of an idea for evolution of 
object chunks and such, but I'd be hesitant to try to get there right 
now without a good deal more analysis of how that might work (and 
whether such a suitable interface can be defined for 'image').


I think the best way to get images to like SVG is to allow an SVG file 
to be set as the text of the image - the image object used to have EMF 
and PICT support (I think it still may have EMF, but PICT disappeared 
with Carbon/Classic API usage) - so there is precedent.


Additionally, if we extend imageSource/icon references to be more 
general (i.e. internally any control which implements the 'I can be an 
icon' type set of actions could be used) - then I'm not sure whether 
there will be many cases left where you might want a 
 to actually be an image.


In any case, introducing a new control (which is far more than an image) 
in the first instance doesn't stop it at some point 'feeling' like an 
image from the point of view of script in the future so it seems like a 
getting the control into existence first is the best approach.



Is this a mad dream?


That depends on whether it involves saying wibble, a pair of underpants 
and two pencils...


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

[Mike Kerner via use-livecode]

I hope not, because I was thinking the same thing.  One of those properties
could be "type" or "class", and that could be "svg", for instance.

On Mon, Nov 6, 2017 at 9:34 AM, Ben Rubinstein via use-livecode <
use-livecode@lists.runrev.com> wrote:

> This might be a stupid question, but might it be possible for this new
> control to completely replace the existing image control?
>
> There aren't very many special properties relating especially to images.
> If the new object implemented those at least to a first approximation, then
> perhaps it could simply be called "image". All existing uses of images
> would work, and the gloss would be that the image object had gained some
> exciting new capabilities.
>
> Is this a mad dream?
>
>
> On 03/11/2017 18:41, Mark Waddingham via use-livecode wrote:
>
>> On 2017-11-03 19:33, Rick Harrison via use-livecode wrote:
>>
>>> I like “vectorImage” too!
>>>
>>> “Picture" has been used for images for a long time,
>>> and we don’t want to add more confusion for users.
>>>
>>
>> Where do you think the confusion would come from?
>>
>> As I said one of the goals of this control would eventually be to replace
>> the image object - so at some point (all being well) you will be able to do:
>>
>>set the filename of  "foo" to "foo.png"
>>set the filename of  "foo" to "foo.gif"
>>set the filename of  "foo" to "foo.jpg"
>>set the filename of  "foo" to "foo.png"
>>...
>>
>> Or
>>
>>set the content of  "foo" to tPngData
>>...
>>
>> At this point, describing the control as a 'vectorImage' might also seem
>> confusing.
>>
>> Warmest Regards,
>>
>> Mark.
>>
>>
> ___
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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

[Ben Rubinstein via use-livecode]

This might be a stupid question, but might it be possible for this new control 
to completely replace the existing image control?


There aren't very many special properties relating especially to images. If 
the new object implemented those at least to a first approximation, then 
perhaps it could simply be called "image". All existing uses of images would 
work, and the gloss would be that the image object had gained some exciting 
new capabilities.


Is this a mad dream?


On 03/11/2017 18:41, Mark Waddingham via use-livecode wrote:

On 2017-11-03 19:33, Rick Harrison via use-livecode wrote:

I like “vectorImage” too!

“Picture" has been used for images for a long time,
and we don’t want to add more confusion for users.


Where do you think the confusion would come from?

As I said one of the goals of this control would eventually be to replace the 
image object - so at some point (all being well) you will be able to do:


   set the filename of  "foo" to "foo.png"
   set the filename of  "foo" to "foo.gif"
   set the filename of  "foo" to "foo.jpg"
   set the filename of  "foo" to "foo.png"
   ...

Or

   set the content of  "foo" to tPngData
   ...

At this point, describing the control as a 'vectorImage' might also seem 
confusing.


Warmest Regards,

Mark.



___
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

[hh via use-livecode]

@Mark
Thank you very much for that fine explanation.

Hopefully the team and you will find enough time to implement
the enhanced 'canvas' (whatever the name).

___
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

[Mark Waddingham via use-livecode]

On 2017-11-05 15:15, hh via use-livecode wrote:

Until now I saw it like that:
,  and  are HTML5 tags.
And  and  are different concepts. Roughly

 is more an XML-based vector graphics format,


Yes - SVG is a way of encoding a sequence of vector graphics commands 
using XML.



 is more an API for drawing on a bitmap surface.


True - but you can also view the canvas as an element which allows you 
to use 2D vector graphics commands from JavaScript to draw, and then 
display.


The HTML5 canvas element (and the canvas API as specified by W3C as it 
stands) is a proper subset of the LCB canvas (or will be after I've 
finished making a small tweak or two with regards separate stroke/fill 
paints).


Indeed, by extension you can view both the LCB and HTML5 Canvas APIs as 
the procedural way to render SVG (HTML5 Canvas API is not quite fully 
featured enough to make this mapping 1-1, but the LCB Canvas is almost 
that, and will become that).


Looking at things from this point of view, the control we are discussing 
is the deferred / data-driven way to display such vector graphics 
commands (without having to create separate graphic objects and such).


When thought about from this point of view, it almost becomes 'obvious' 
that canvas is the correct choice - the only difference between the 
canvas in LCS and the canvas in LCB, is that the canvas in LCB requires 
you to execute a sequence of commands whereas the proposed control in 
LCS is a sequence of deferred commands, which are executed when the 
control needs to be rendered.



Will it be possible to edit properties:

Getting and setting the points of a graphic?
Getting and setting the imagedata of a placed image?
Getting and setting the specific data of an SVG?


That is definitely a potential future direction. The canvas control's 
'content' is (at present) a sequence of commands representing the SVG 
tags which render something, along with state setting commands for 
stroke/fill/transform.


There is no reason why, in the future, you shouldn't be able to edit 
already existing commands - although for the time being you would need 
to rewrite and set the svgText property.



Can it be used for exactly one of the objects or also a mix of the
three, say an SVGicon on top of an image?


Yes - you could create an SVG fragment which describes those objects, 
and then set the svgText.


The svgText property is the same idea as the htmlText property of a 
field - it is a fully faithful representation of the field's content, 
encoded as string using HTML (well HTML-like).



For example:
A lot of people are not able to write SVG, they are simply copying
out of programs like 'inkscape' and would like to paste the code
into a property of the control. Will that be possible?


Yes - the, you will be able to set the svgText to SVG generated from any 
program. The SVG compiler removes anything it doesn't understand (as per 
the requirements of the SVG spec), and renders what is left. i.e. There 
is no need to externally process the SVG source in any way (unless you 
want to tweak it of course).


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

[Erik Beugelaar via use-livecode]

Maybe ‘raster’ as an anternative for ‘canvas’?

Cheers,
Erik



On 05/11/17 22:06, "use-livecode on behalf of Richmond Mathewson via 
use-livecode"  wrote:

I'm not sure how the word "canvas" conjures up ideas of interactivity.

Interactive words:

Playground

Kitchen

Chalkboard

Tray

Not, frankly, that any of the above would do.

I'm still pushing svgImage

although vImage (as in Vector + Image) might not be bad.

Richmond.

On 11/5/17 10:49 pm, Monte Goulding via use-livecode wrote:
>> On 6 Nov 2017, at 6:24 am, J. Landman Gay via use-livecode 
 wrote:
>>
>>> will stop Jacque killing Mark when there is no
>>> abbreviation
>> If we go with "canvas" I expect "cv" or similar. :) It did occur to me 
that if I kill Mark my career will be cut short. I have to think about that.
> Hmm… I’m not sure if Mark will change his mind on synonyms even given 
death threats ;-)
>
> I like canvas too though. One nice thing is I feel it gives more scope 
for interactive elements than picture does.
>
> Cheers
>
> Monte
> ___
> 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



___
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

[Mark Waddingham via use-livecode]

On 2017-11-05 21:49, Monte Goulding via use-livecode wrote:
On 6 Nov 2017, at 6:24 am, J. Landman Gay via use-livecode 
 wrote:



will stop Jacque killing Mark when there is no
abbreviation


If we go with "canvas" I expect "cv" or similar. :) It did occur to me 
that if I kill Mark my career will be cut short. I have to think about 
that.


Hmm… I’m not sure if Mark will change his mind on synonyms even given
death threats ;-)


Heh - indeed - although in this case it is an abbreviation (as 
previously discussed), rather than a synonym ;)


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

[hh via use-livecode]

From Wikipedia:
The word "canvas" is derived from the 13th century Anglo-French
canevaz and the Old French canevas. Both may be derivatives of
the Vulgar Latin cannapaceus for "made of hemp," originating
from the Greek κάνναβις (cannabis).

So give it the synonyms hemp and cannabis -- if not joint ;-)


___
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

[Jim Lambert via use-livecode]

FRAME would be good except it is already defined in the Livecode Dictionary as:

'One of the images in the sequence of images that makes up an animation or 
video.’

And there’s also framecount and framerate relating to animated GIFs.
Presumably some video widgets would also refer to movie frames, keyframes, etc.

Jim Lambert
___
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

[Dan Brown via use-livecode]

https://www.w3schools.com/html/html5_canvas.asp

"Canvas" could be confused with the html5 element of the same name. What
with livecode deploying to html5 now...

On 5 Nov 2017 8:49 pm, "Monte Goulding via use-livecode" <
use-livecode@lists.runrev.com> wrote:

>
> > On 6 Nov 2017, at 6:24 am, J. Landman Gay via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> >> will stop Jacque killing Mark when there is no
> >> abbreviation
> >
> > If we go with "canvas" I expect "cv" or similar. :) It did occur to me
> that if I kill Mark my career will be cut short. I have to think about that.
>
> Hmm… I’m not sure if Mark will change his mind on synonyms even given
> death threats ;-)
>
> I like canvas too though. One nice thing is I feel it gives more scope for
> interactive elements than picture does.
>
> Cheers
>
> Monte
> ___
> 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

Re: The coming of SVG

[Richmond Mathewson via use-livecode]

I'm not sure how the word "canvas" conjures up ideas of interactivity.

Interactive words:

Playground

Kitchen

Chalkboard

Tray

Not, frankly, that any of the above would do.

I'm still pushing svgImage

although vImage (as in Vector + Image) might not be bad.

Richmond.

On 11/5/17 10:49 pm, Monte Goulding via use-livecode wrote:

On 6 Nov 2017, at 6:24 am, J. Landman Gay via use-livecode 
 wrote:


will stop Jacque killing Mark when there is no
abbreviation

If we go with "canvas" I expect "cv" or similar. :) It did occur to me that if 
I kill Mark my career will be cut short. I have to think about that.

Hmm… I’m not sure if Mark will change his mind on synonyms even given death 
threats ;-)

I like canvas too though. One nice thing is I feel it gives more scope for 
interactive elements than picture does.

Cheers

Monte
___
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

Re: The coming of SVG

[Monte Goulding via use-livecode]

> On 6 Nov 2017, at 6:24 am, J. Landman Gay via use-livecode 
>  wrote:
> 
>> will stop Jacque killing Mark when there is no
>> abbreviation
> 
> If we go with "canvas" I expect "cv" or similar. :) It did occur to me that 
> if I kill Mark my career will be cut short. I have to think about that.

Hmm… I’m not sure if Mark will change his mind on synonyms even given death 
threats ;-)

I like canvas too though. One nice thing is I feel it gives more scope for 
interactive elements than picture does.

Cheers

Monte
___
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

[Tore Nilsen via use-livecode]

Please consider it very carefully! Do not proceed until you have found a proper 
replacement.

Tore  

> 5. nov. 2017 kl. 20:24 skrev J. Landman Gay via use-livecode 
> :
> 
> It did occur to me that if I kill Mark my career will be cut short. I have to 
> think about that.

___
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

[J. Landman Gay via use-livecode]

On 11/5/17 3:17 AM, Lagi Pittas via use-livecode wrote:

will stop Jacque killing Mark when there is no
abbreviation


If we go with "canvas" I expect "cv" or similar. :) It did occur to me 
that if I kill Mark my career will be cut short. I have to think about that.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

[J. Landman Gay via use-livecode]

On 11/5/17 6:19 AM, Mark Waddingham via use-livecode wrote:

Hmmm - actually, why not 'canvas'?


I like this.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

[Terry Judd via use-livecode]

If not picture (or canvas) then another couple of names that might work and 
don’t have baggage associated with them are figure and drawing.

I perhaps like the look/sound of drawing better but it doesn’t really capture 
the ability of the object to contain an image particularly well. If you think 
about figure, in the way it is used in presenting visual information in 
books/articles etc then a figure can contain all sorts of visual elements, 
graphics, drawings, images, text, whatever.

Terry...

On 5/11/2017 11:19 pm, "use-livecode on behalf of Mark Waddingham via 
use-livecode"  wrote:

On 2017-11-05 00:59, Niggemann, Bernd via use-livecode wrote:
> I like "Canvas" from LCB but unfortunately that is already taken. It
> would have been my favorite.

Hmmm - actually, why not 'canvas'?



___
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

[Richmond Mathewson via use-livecode]

svgImage shortened to svgImg

Richmond.

On 11/5/17 5:46 pm, Dave Kilroy via use-livecode wrote:

Hmm tricky this naming business isn’t it!

My take on this is that it would be better to have a modifier for an existing 
control name rather than baptise a new control name to join what we already 
have (especially as it sounds like what Mark has done to to create a 
‘superImage’ / ‘superGraphic’ control (I know there is more to it than that, 
but for me this is what stands out as new)

In much the same way that ‘trueWord’ joined ‘word’ we could have ‘uniImage’ or 
‘trueImage’ (or ‘uniGraphic’ or ‘trueGraphic’) - this will keep the number of 
control names down as a low as possible and won’t break anything in old code

Kind regards

Dave



___
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

Re: The coming of SVG

[Dave Kilroy via use-livecode]

Hmm tricky this naming business isn’t it!

My take on this is that it would be better to have a modifier for an existing 
control name rather than baptise a new control name to join what we already 
have (especially as it sounds like what Mark has done to to create a 
‘superImage’ / ‘superGraphic’ control (I know there is more to it than that, 
but for me this is what stands out as new)

In much the same way that ‘trueWord’ joined ‘word’ we could have ‘uniImage’ or 
‘trueImage’ (or ‘uniGraphic’ or ‘trueGraphic’) - this will keep the number of 
control names down as a low as possible and won’t break anything in old code

Kind regards

Dave



___
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

[Mike Kerner via use-livecode]

@mark  when possible, I think it's better to keep the vocabulary simpler or
more obvious in LC.  It's one of the benefits of the environment and the
tool - less mental effort around the tool and the language.  When possible,
I think it's better to make it obvious to non-nerds, which will also mean
it is more obvious to people who don't work with a particular feature
frequently.

On Sun, Nov 5, 2017 at 9:15 AM, hh via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Until now I saw it like that:
> ,  and  are HTML5 tags.
> And  and  are different concepts. Roughly
>
>  is more an XML-based vector graphics format,
>  is more an API for drawing on a bitmap surface.
>
> And  is a container for an image at different sizes.
> [And, as James says,  is also a (different) HTML container.]
>
> @Mark.
>
> But I think, the interesting thing is not the name (call it as you
> like it) but the direction of your path, the content of the object.
> Let's talk about that.
>
> Will it be possible to edit properties:
>
> Getting and setting the points of a graphic?
> Getting and setting the imagedata of a placed image?
> Getting and setting the specific data of an SVG?
>
> Can it be used for exactly one of the objects or also a mix of the
> three, say an SVGicon on top of an image?
>
> For example:
> A lot of people are not able to write SVG, they are simply copying
> out of programs like 'inkscape' and would like to paste the code
> into a property of the control. Will that be possible?
>
> Who if not you knows that most of this (except the SVG part) is
> already possible in LCB?
>
> For example my IconGrid widget has for each element
> * a paint property (color)
> * a text property (textsize, textfont settable)
> * an image property (image scalable)
> * a SVGIcon property (svg scalable).
>
> So, if you would extend the SVGIcon widget to a SVG_1.0 widget, we
> could have all that without the need for a new container.
>
> ___
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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

[hh via use-livecode]

Until now I saw it like that:
,  and  are HTML5 tags.
And  and  are different concepts. Roughly

 is more an XML-based vector graphics format,
 is more an API for drawing on a bitmap surface.

And  is a container for an image at different sizes.
[And, as James says,  is also a (different) HTML container.]

@Mark.

But I think, the interesting thing is not the name (call it as you
like it) but the direction of your path, the content of the object.
Let's talk about that.

Will it be possible to edit properties:

Getting and setting the points of a graphic?
Getting and setting the imagedata of a placed image?
Getting and setting the specific data of an SVG?

Can it be used for exactly one of the objects or also a mix of the
three, say an SVGicon on top of an image?

For example:
A lot of people are not able to write SVG, they are simply copying
out of programs like 'inkscape' and would like to paste the code
into a property of the control. Will that be possible?

Who if not you knows that most of this (except the SVG part) is
already possible in LCB?

For example my IconGrid widget has for each element
* a paint property (color)
* a text property (textsize, textfont settable)
* an image property (image scalable)
* a SVGIcon property (svg scalable).

So, if you would extend the SVGIcon widget to a SVG_1.0 widget, we
could have all that without the need for a new container.

___
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

[James At The Hale via use-livecode]

Between Bernd’s post and Richard’s I too thought of frame but then discounted 
(reluctantly) as it has a specific meaning in html which could also be 
confusing.

James

___
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

[Mark Waddingham via use-livecode]

On 2017-11-05 00:59, Niggemann, Bernd via use-livecode wrote:

I like "Canvas" from LCB but unfortunately that is already taken. It
would have been my favorite.


Hmmm - actually, why not 'canvas'?

Certainly there is a Canvas type in LiveCode Builder, but the 'canvas' 
idea hasn't been used in LiveCode Script. I'd be wary if the two notions 
- i.e. the Canvas type in LCB and the 'SomethingLikePicture' object in 
LCS - were unrelated, but they aren't.


After all it is the Canvas type in LCB which provides the actual ability 
to render the commands which come out of processing an SVG file - the 
mapping from resulting attributed element (e.g. rect with paint and 
stroke attributes) is almost a 1-1 mapping from notion to canvas command 
and the plan is to make this completely 1-1.


So, we can view the LCB Canvas Type as being a 'rasterization-only' 
target for SVG commands, whereas the LCS canvas object essentially 
records the commands and plays them back on demand.


In fact, 'canvas' perhaps describes what the proposed object will 
actually be - it will allow you (from LCS) to describe a sequence of 2d 
vector graphics operations, which are then rendered on demand - 
essentially a deferred version of the LCB Canvas Type (essentially the 
'canvas' script object would be a high-level wrapper around the LCB 
canvas type).


Certainly the idea of being able to specify an image, or vector 
graphics, or a single graphic type to be drawn on a 'canvas' perhaps 
makes more sense than on a 'picture' (or other image-like synonyms).


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

[Richmond Mathewson via use-livecode]

Frame

Richmond.

On 11/5/17 1:59 am, Niggemann, Bernd via use-livecode wrote:

for me "Picture" is a bit confusing.

We have "Image" for bitmaps, "Graphic" for vector graphics of a certain type and now we 
might have "Picture" for all kinds of elements.

However "Picture" is easily confused with "Image" or "Graphic" for a newcomer. 
The forum is full of synonyms that take a graphic for a bitmap and an image for a vector graphic.

Why not call the new widget something like "Blackboard"? Or something like 
that. It conveys the notion that you can put all sort of things onto a blackboard, 
regardless of their internal representation. It alludes to the container for those things 
not the result of what is displayed.

I like "Canvas" from LCB but unfortunately that is already taken. It would have 
been my favorite.

Logically "Image", "Graphic" and "Picture" are all elements of a class of "visuals", but now 
"Image" and "Graphic" become elements of the class "Picture".

It is a bit fuzzy what the difference in logical hierarchy is. A new term could prevent a possible 
confusion that "Picture" is a new logical class with said elements but at the same time a 
picture could be considered a member of class "Picture".

Kind regards
Bernd
___
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

Re: The coming of SVG

[Lagi Pittas via use-livecode]

I was going for PICTURE but now I think  Richmond’s FRAME is better. It
takes into account the newbies, encompasses the same thought process as
Bernd’s BLACKBOARD and will stop Jacque killing Mark when there is no
abbreviation, because BLACK is taken.

Lagi

On Sun, 5 Nov 2017 at 08:53, Richmond Mathewson via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Frame
>
> Richmond.
>
> On 11/5/17 1:59 am, Niggemann, Bernd via use-livecode wrote:
> > for me "Picture" is a bit confusing.
> >
> > We have "Image" for bitmaps, "Graphic" for vector graphics of a certain
> type and now we might have "Picture" for all kinds of elements.
> >
> > However "Picture" is easily confused with "Image" or "Graphic" for a
> newcomer. The forum is full of synonyms that take a graphic for a bitmap
> and an image for a vector graphic.
> >
> > Why not call the new widget something like "Blackboard"? Or something
> like that. It conveys the notion that you can put all sort of things onto a
> blackboard, regardless of their internal representation. It alludes to the
> container for those things not the result of what is displayed.
> >
> > I like "Canvas" from LCB but unfortunately that is already taken. It
> would have been my favorite.
> >
> > Logically "Image", "Graphic" and "Picture" are all elements of a class
> of "visuals", but now "Image" and "Graphic" become elements of the class
> "Picture".
> >
> > It is a bit fuzzy what the difference in logical hierarchy is. A new
> term could prevent a possible confusion that "Picture" is a new logical
> class with said elements but at the same time a picture could be considered
> a member of class "Picture".
> >
> > Kind regards
> > Bernd
> > ___
> > 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
>
___
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

[Niggemann, Bernd via use-livecode]

for me "Picture" is a bit confusing.

We have "Image" for bitmaps, "Graphic" for vector graphics of a certain type 
and now we might have "Picture" for all kinds of elements.

However "Picture" is easily confused with "Image" or "Graphic" for a newcomer. 
The forum is full of synonyms that take a graphic for a bitmap and an image for 
a vector graphic.

Why not call the new widget something like "Blackboard"? Or something like 
that. It conveys the notion that you can put all sort of things onto a 
blackboard, regardless of their internal representation. It alludes to the 
container for those things not the result of what is displayed.

I like "Canvas" from LCB but unfortunately that is already taken. It would have 
been my favorite.

Logically "Image", "Graphic" and "Picture" are all elements of a class of 
"visuals", but now "Image" and "Graphic" become elements of the class 
"Picture". 

It is a bit fuzzy what the difference in logical hierarchy is. A new term could 
prevent a possible confusion that "Picture" is a new logical class with said 
elements but at the same time a picture could be considered a member of class 
"Picture". 

Kind regards
Bernd
___
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

[hh via use-livecode]

What about:

wad (also honouring the main author of the new "container")

on mouseUp
   if there is no wad "w_1" then
  create wad "w_1"
  put image "img_1" into wad "w_0" 
  put graphic "grc_1" onto back of wad "w_1"
  put svgicon "svg_1" onto front of wad "w_1"
  end if
end mouseUp


___
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

[James At The Hale via use-livecode]

Of the alternatives presented “picture” gets my vote.



___
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

[Richmond Mathewson via use-livecode]

Humph: when I was 32 and using a Mac Performa 475 SuperPaint was a "not 
so super"
program for doing things that by today's standards look largely like a 
complete and utter waste

of time.

I don't know what the new "SVG" thang should called,

and I am slobbering in excitement at the thought of it,

but, Please nothing with "paint" in it, or a comparative or superlative
adjective:

"Bestest Ever Paint"

because anything with a comparative or superlative in its name is going to
be superseded sooner or later,

and "paint" . . .

---

Just back from a wonderful 3 day break hill-walking with my wife,

[anyone thinking of an inexpensive hill-walking trip in
some stunning scenery (Bulgarian mountains) contact me]

and slightly "murh" as it is the end of a holiday, and I find the news
about the new SVG thang in my in-box: Wow; fantastic news.

Richmond.

On 11/4/17 2:33 pm, Mike Kerner via use-livecode wrote:

The issue with art is that anything that I do will automatically be
relabeled "areYouKiddingThatIsNotArt", and abbreviated "thatIsSoNotArt",
with a synonym "hahahahahahahahahahahahahahahahahahaha"

On Sat, Nov 4, 2017 at 2:34 AM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:


Alejandro Tejada wrote:


By the way, this new control type, Could allow easier implementation
of image libraries, where you store a single instance of a bitmap
or graphic and then LiveCode engine just rebuild your picture
from the original data applying all transformation or changes
applied to the new instance of this same picture?

That is the way in which Xara and other programs manages
vector symbols and bitmap images:

https://www.youtube.com/watch?v=BTuTe6LG6cA

Wonderful.

When I was a kid we called that SuperPaint (ah, the wonders of Silicon
Beach Software).

Nice to see the spirit alive and well

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  
  ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

Re: The coming of SVG

[Mike Kerner via use-livecode]

The issue with art is that anything that I do will automatically be
relabeled "areYouKiddingThatIsNotArt", and abbreviated "thatIsSoNotArt",
with a synonym "hahahahahahahahahahahahahahahahahahaha"

On Sat, Nov 4, 2017 at 2:34 AM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Alejandro Tejada wrote:
>
> > By the way, this new control type, Could allow easier implementation
> > of image libraries, where you store a single instance of a bitmap
> > or graphic and then LiveCode engine just rebuild your picture
> > from the original data applying all transformation or changes
> > applied to the new instance of this same picture?
> >
> > That is the way in which Xara and other programs manages
> > vector symbols and bitmap images:
> >
> > https://www.youtube.com/watch?v=BTuTe6LG6cA
>
> Wonderful.
>
> When I was a kid we called that SuperPaint (ah, the wonders of Silicon
> Beach Software).
>
> Nice to see the spirit alive and well
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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

[Richard Gaskin via use-livecode]

Alejandro Tejada wrote:

> By the way, this new control type, Could allow easier implementation
> of image libraries, where you store a single instance of a bitmap
> or graphic and then LiveCode engine just rebuild your picture
> from the original data applying all transformation or changes
> applied to the new instance of this same picture?
>
> That is the way in which Xara and other programs manages
> vector symbols and bitmap images:
>
> https://www.youtube.com/watch?v=BTuTe6LG6cA

Wonderful.

When I was a kid we called that SuperPaint (ah, the wonders of Silicon 
Beach Software).


Nice to see the spirit alive and well

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

The coming of SVG

[Alejandro Tejada via use-livecode]

Jim Lambert wrote:
 > I like Mark's ‘picture' because it is general. A picture can contain
 > both vectors and bitmaps.

Richard Gaskin wrote:
> Seconded.  When I first read Mark's post I was wary of "picture",
> but on further reflection I remembered Apple's PICT file/data type,
> distinct from PNTG as the latter was exclusively bitmap data but
> PICT could contain a mix of vectors and bitmaps.
> If it's good enough for Apple, it's good enough for me.

Count my vote, too. :-)

By the way, this new control type, Could allow easier implementation
of image libraries, where you store a single instance of a bitmap
or graphic and then LiveCode engine just rebuild your picture
from the original data applying all transformation or changes
applied to the new instance of this same picture?

That is the way in which Xara and other programs manages
vector symbols and bitmap images:

https://www.youtube.com/watch?v=BTuTe6LG6cA

Al
___
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

[Kay C Lan via use-livecode]

On Sat, Nov 4, 2017 at 7:19 AM, hh via use-livecode
 wrote:
>
> Probably we could call it "artwork"?
> (If all the promises realise it is indeed a software artwork!)

Beat me to it. But considering LC takes the hard work out of cross
platform programing. And considering Jacques comments about Mark not
being fond of abbreviations. Lets just take the work out of artwork
and call it 'art';-)

___
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

[Bob Sneidar via use-livecode]

Actually, any button using an image/icon should have a scale and alternately a 
position, like when you set a picture for a web avatar. But that may be asking 
too much. A scale percentage would be great! I usually import the image, set 
it's scale, lock it's location, and then the buttons that use it will reflect 
those settings. It would be easier if the button had an icon scale option. 

Bob S


> On Nov 3, 2017, at 10:51 , Klaus major-k via use-livecode 
>  wrote:
> 
> When using an image as a button icon, the size of the image in button = size 
> of the image with that ID.
> Will this behaviour be the same with SVG "icons"? Or will we be able to 
> display the same SVG in different 
> buttons at different sizes? Know what I mean?
> 
> If that is possible, then we would need another property for buttons (or the 
> SVGs?) to be able to scale the 
> icon inside of the button. Something to consider, I think. :-)
> 
> 
> Best
> 
> Klaus
> 
> --
> Klaus Major
> http://www.major-k.de
> kl...@major-k.de


___
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

[Richard Gaskin via use-livecode]

Jim Lambert wrote:

> I like Mark's ‘picture' because it is general. A picture can contain
> both vectors and bitmaps.

Seconded.  When I first read Mark's post I was wary of "picture", but on 
further reflection I remembered Apple's PICT file/data type, distinct 
from PNTG as the latter was exclusively bitmap data but PICT could 
contain a mix of vectors and bitmaps.


If it's good enough for Apple, it's good enough for me.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

[Jim Lambert via use-livecode]

I like Mark's ‘picture' because it is general. A picture can contain both 
vectors and bitmaps. 
Any word with ‘icon’ in it seems overly specific as does ’SVG’-anything; while 
‘vectorimage’ implies an image made up of vectors.

set the filename of pct 1 to ‘blah blah.blah’

Jim Lambert


___
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

[J. Landman Gay via use-livecode]

Oh you 'nix people. Okay, "vct" then. ;)

Mark doesn't like abbreviations. We're at his mercy.


On 11/3/17 3:16 PM, Mike Kerner via use-livecode wrote:

Please, not "vi"

On Fri, Nov 3, 2017 at 4:14 PM, J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:


On 11/3/17 1:41 PM, Mark Waddingham via use-livecode wrote:


As I said one of the goals of this control would eventually be to replace
the image object - so at some point (all being well) you will be able to do:

set the filename of  "foo" to "foo.png"
set the filename of  "foo" to "foo.gif"
set the filename of  "foo" to "foo.jpg"
set the filename of  "foo" to "foo.png"
...

Or

set the content of  "foo" to tPngData
...

At this point, describing the control as a 'vectorImage' might also seem
confusing.




It's short for "thing that can handle vectors or images". VectorsOrImages
-> Vector/Image -> VectorImage -> vi.

We *will* get an abbreviation, right?

;)

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
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








--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

[hh via use-livecode]

> At least historically, paintings were bitmapped,
> not vector (think MacPaint vs. MacDraw)

Yes. And LCB "draws" an image and uses "OnPaint" for it's canvas.

Probably we could call it "artwork"?
(If all the promises realise it is indeed a software artwork!)


___
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

[Mike Kerner via use-livecode]

Please, not "vi"

On Fri, Nov 3, 2017 at 4:14 PM, J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 11/3/17 1:41 PM, Mark Waddingham via use-livecode wrote:
>
>> As I said one of the goals of this control would eventually be to replace
>> the image object - so at some point (all being well) you will be able to do:
>>
>>set the filename of  "foo" to "foo.png"
>>set the filename of  "foo" to "foo.gif"
>>set the filename of  "foo" to "foo.jpg"
>>set the filename of  "foo" to "foo.png"
>>...
>>
>> Or
>>
>>set the content of  "foo" to tPngData
>>...
>>
>> At this point, describing the control as a 'vectorImage' might also seem
>> confusing.
>>
>
>
> It's short for "thing that can handle vectors or images". VectorsOrImages
> -> Vector/Image -> VectorImage -> vi.
>
> We *will* get an abbreviation, right?
>
> ;)
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
>
> ___
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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

[J. Landman Gay via use-livecode]

On 11/3/17 1:41 PM, Mark Waddingham via use-livecode wrote:
As I said one of the goals of this control would eventually be to 
replace the image object - so at some point (all being well) you will be 
able to do:


   set the filename of  "foo" to "foo.png"
   set the filename of  "foo" to "foo.gif"
   set the filename of  "foo" to "foo.jpg"
   set the filename of  "foo" to "foo.png"
   ...

Or

   set the content of  "foo" to tPngData
   ...

At this point, describing the control as a 'vectorImage' might also seem 
confusing.



It's short for "thing that can handle vectors or images". 
VectorsOrImages -> Vector/Image -> VectorImage -> vi.


We *will* get an abbreviation, right?

;)

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
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

[Stephen Barncard via use-livecode]

Universal Image Object
uni-Image
imagePak
UIO
imageBlob
imagepack
imageContainer

quicktime... (oh, wait..)


how about imageData

... has been used yes but base the 'thing' on that ...add the options

--
Stephen Barncard - Sebastopol Ca. USA -
mixstream.org

On Fri, Nov 3, 2017 at 12:49 PM, Mike Kerner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> At least historically, paintings were bitmapped, not vector (think MacPaint
> vs. MacDraw)
>
> On Fri, Nov 3, 2017 at 3:40 PM, hh via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > Look forward to the first release of .
> >
> > For the name, what about "painting"?
> >
> > ___
> > 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
> >
>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>and did a little diving.
> And God said, "This is good."
> ___
> 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

Re: The coming of SVG

[Mike Kerner via use-livecode]

At least historically, paintings were bitmapped, not vector (think MacPaint
vs. MacDraw)

On Fri, Nov 3, 2017 at 3:40 PM, hh via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Look forward to the first release of .
>
> For the name, what about "painting"?
>
> ___
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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

[hh via use-livecode]

Look forward to the first release of .

For the name, what about "painting"?

___
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

[Mark Waddingham via use-livecode]

On 2017-11-03 19:33, Rick Harrison via use-livecode wrote:

I like “vectorImage” too!

“Picture" has been used for images for a long time,
and we don’t want to add more confusion for users.


Where do you think the confusion would come from?

As I said one of the goals of this control would eventually be to 
replace the image object - so at some point (all being well) you will be 
able to do:


  set the filename of  "foo" to "foo.png"
  set the filename of  "foo" to "foo.gif"
  set the filename of  "foo" to "foo.jpg"
  set the filename of  "foo" to "foo.png"
  ...

Or

  set the content of  "foo" to tPngData
  ...

At this point, describing the control as a 'vectorImage' might also seem 
confusing.


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

[Mark Waddingham via use-livecode]

On 2017-11-03 19:02, Bleiler, Timothy via use-livecode wrote:

This is good news!!

Is there any reason not to call the control “SVG?”


Three main reasons:

  - SVG is a somewhat human-unfriendly term

  - SVG is technically a vector graphics interchange format (and so an 
adjective, not a noun - you have SVG Files, or SVG Documents)


  - SVG doesn't represent what the control does / will do, as SVG is 
only the means it uses to describe its internal structure when you set 
or get it


The future goal here would be to make the new control the *replacement* 
for the existing image/graphic objects - it is for displaying pictorial 
things, whether they be raster images, svg files, simple geometric 
shapes etc.


Another way to look at this is to forget I had ever mentioned anything 
related to SVG and then ask yourself this:


  'What would be a good name for a control which can display complex 
vector images, raster images or combinations of geometric shapes be, 
assuming 'graphic' or 'image' were not available?'


Why create another abstraction in the name from what the control 
actually is?


I don't really see it as creating another abstraction, more about 
accurately representing the abstractions which are there. i.e. the 
proposed control uses SVG as one of its means of interchange, but its 
purpose is to display an image/picture. It also means that the term 
'svg' can be left for being 'an object which is *just* a manipulatable 
representation of an SVG docuent' (indeed, the experimental SVGViewer 
widget I wrote a couple of years back based on nanosvg added an 'svg' 
object to the canvas module in LCB - allowing you to render them like 
you can paths).


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

[Rick Harrison via use-livecode]

I like “vectorImage” too!

“Picture" has been used for images for a long time,
and we don’t want to add more confusion for users.

Just my 2 cents..

Rick

> On Nov 3, 2017, at 2:23 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> Or maybe "vectorImage".

___
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

The coming of SVG

[Alejandro Tejada via use-livecode]

Mark Waddingham wrote:
> we are now firmly on the road to full SVG support in LiveCode!

These are great good news! Congratulations. :-D

> the name is currently vectoricon

Actually, I like the name "Picture" because
it remembers me about the PICT file format
that could include bitmaps, vectors and text.

Because you asked for names ideas,
here they are:

Pathline
Pathshape
Linepath
Shapepath
Shapeline

But I still prefer "Picture". :-)

Al
___
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

[J. Landman Gay via use-livecode]

On 11/3/17 1:12 PM, J. Landman Gay via use-livecode wrote:

On 11/3/17 11:05 AM, Mark Waddingham via use-livecode wrote:

the name is currently vectoricon


To be honest, I like this better than "picture". It's more descriptive.



Or maybe "vectorImage".

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

[Mike Kerner via use-livecode]

SVG's are not just standalone objects.  They are also part of various
widgets.

On Fri, Nov 3, 2017 at 2:02 PM, Bleiler, Timothy via use-livecode <
use-livecode@lists.runrev.com> wrote:

> This is good news!!
>
> Is there any reason not to call the control “SVG?”
> Why create another abstraction in the name from what the control actually
> is?
>
> e.g.
> Set the fileName of SVG “My Picture” to ….
>
> Tim Bleiler, Ph.D.
> Instructional Designer, HSIT
> University at Buffalo
>
>
>
> > On Nov 3, 2017, at 9:19 AM, Mark Waddingham via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Hi all,
> >
> > My most recent talk at LCG (in October) was 'Building an SVG Widget' and
> in order to talk about such a thing, I needed to actually build one - so I
> did :)
> >
> > So, we are now firmly on the road to full SVG support in LiveCode!
> >
> > At the moment the implementation only supports geometric shape tags,
> paths, and solid color fills. However, it supports the standard fill/stroke
> attributes and should work with any SVG file - anything which isn't
> supported just doesn't get rendered (so you have a modicum of graceful
> degradation in terms of features). In particular, you don't need to
> preprocess your SVG file to pull out incompatible tags / attributes, or
> just extract the path (as you do for the SVGIcon widget).
> >
> > The current implementation successfully renders quite a wide range of
> simple SVGs (simple in the features they use, rather than how they look!).
> Indeed, it happily renders the (quite widely known) Tiger and Lion SVGs,
> and has been tested on quite a few random SVGs I managed to find on
> Wikipedia. It is certainly more than capable if you want to use simply
> coloured multi-path SVGs.
> >
> > LCG attendees got a prototype of a widget to play with - called
> vectoricon - and integrating this initial version this into the product has
> now got to the top of my work-list :)
> >
> > The principal thing which I'd like some feedback on right now is the
> name of the widget/control - I think we have a good one, but wanted to see
> what you all thought before committing us to it forever and a day.
> >
> > Before getting to that though, I should perhaps explain what a potential
> path for the evolution of this new feature in LiveCode could look like.
> >
> > SVG as a concept allows arbitrary collections of vector shapes, images
> and text to be represented in a single high-level way as XML - in
> particular, you can express geometric shapes, raster images and text all in
> one unified form.
> >
> > Previously we had proposed producing a 'shape' object which would be a
> 'graphic object on steroids' - allowing affine transformation, higher
> fidelity specification of geometric objects and groups of them; providing
> an 'svgText' interface similar to htmlText on the field. Essentially, the
> proposed 'shape' object would have used a subset of SVG to allow easy
> interchange of what it represents.
> >
> > That notion of 'shape' object (and thus the current 'graphic' object)
> can be subsumed into the SVG implementation in an obvious way - if you ask
> your SVG object to be a rectangle, it creates (notionally) the SVG for a
> rectangle internally and uses that - which you would see via the svgText.
> >
> > Similarly, as SVG can represent raster images too, we can fold the
> current behavior of the 'image' object into it to - in a similar way.
> >
> > The end result here would be a single object which is a generalization
> of two existing objects - image and graphic - but without the
> backwards-compatibility baggage we currently have.
> >
> > In terms of using this new object in a consistent way to our current
> model, we propose (subsequently) to generalize the types of objects which
> can be referenced by imageSource and icon properties - allowing them to use
> any object which 'knows how to be used as an icon'. Currently, only the
> image object has this knowledge - but we can extend to other objects by
> getting them to implement the appropriate internal interface. This would
> mean that you could just replace the images you use currently for icons and
> such, with the new control which supports SVG and use SVG instead.
> >
> > Given the potential future path of this particular feature, we also
> propose to eventually give it an actual control type - rather than widget
> (although it will still be a widget). i.e. We think it is has such future
> potential that being able to do ' "foo"' in script will be very
> useful (this is almost a requirement if it is to eventually 'replace' the
> image and graphic objects). [ Note: we have also been considering this for
> the browser widget too! ].
> >
> > Thus with all that in mind - we are proposing 'picture' as the name of
> the new SVG capable control, with the following ideal roadmap:
> >
> >  a) we would integrate the 'prototype' implemented for SVG as
> 'com.livecode.widget.picture'
> >
> >  b) we would add a 'picture' noun to the 

Re: The coming of SVG

[J. Landman Gay via use-livecode]

On 11/3/17 11:05 AM, Mark Waddingham via use-livecode wrote:

the name is currently vectoricon


To be honest, I like this better than "picture". It's more descriptive.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

[Bleiler, Timothy via use-livecode]

This is good news!! 

Is there any reason not to call the control “SVG?” 
Why create another abstraction in the name from what the control actually is?

e.g.
Set the fileName of SVG “My Picture” to ….

Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo



> On Nov 3, 2017, at 9:19 AM, Mark Waddingham via use-livecode 
>  wrote:
> 
> Hi all,
> 
> My most recent talk at LCG (in October) was 'Building an SVG Widget' and in 
> order to talk about such a thing, I needed to actually build one - so I did :)
> 
> So, we are now firmly on the road to full SVG support in LiveCode!
> 
> At the moment the implementation only supports geometric shape tags, paths, 
> and solid color fills. However, it supports the standard fill/stroke 
> attributes and should work with any SVG file - anything which isn't supported 
> just doesn't get rendered (so you have a modicum of graceful degradation in 
> terms of features). In particular, you don't need to preprocess your SVG file 
> to pull out incompatible tags / attributes, or just extract the path (as you 
> do for the SVGIcon widget).
> 
> The current implementation successfully renders quite a wide range of simple 
> SVGs (simple in the features they use, rather than how they look!). Indeed, 
> it happily renders the (quite widely known) Tiger and Lion SVGs, and has been 
> tested on quite a few random SVGs I managed to find on Wikipedia. It is 
> certainly more than capable if you want to use simply coloured multi-path 
> SVGs.
> 
> LCG attendees got a prototype of a widget to play with - called vectoricon - 
> and integrating this initial version this into the product has now got to the 
> top of my work-list :)
> 
> The principal thing which I'd like some feedback on right now is the name of 
> the widget/control - I think we have a good one, but wanted to see what you 
> all thought before committing us to it forever and a day.
> 
> Before getting to that though, I should perhaps explain what a potential path 
> for the evolution of this new feature in LiveCode could look like.
> 
> SVG as a concept allows arbitrary collections of vector shapes, images and 
> text to be represented in a single high-level way as XML - in particular, you 
> can express geometric shapes, raster images and text all in one unified form.
> 
> Previously we had proposed producing a 'shape' object which would be a 
> 'graphic object on steroids' - allowing affine transformation, higher 
> fidelity specification of geometric objects and groups of them; providing an 
> 'svgText' interface similar to htmlText on the field. Essentially, the 
> proposed 'shape' object would have used a subset of SVG to allow easy 
> interchange of what it represents.
> 
> That notion of 'shape' object (and thus the current 'graphic' object) can be 
> subsumed into the SVG implementation in an obvious way - if you ask your SVG 
> object to be a rectangle, it creates (notionally) the SVG for a rectangle 
> internally and uses that - which you would see via the svgText.
> 
> Similarly, as SVG can represent raster images too, we can fold the current 
> behavior of the 'image' object into it to - in a similar way.
> 
> The end result here would be a single object which is a generalization of two 
> existing objects - image and graphic - but without the 
> backwards-compatibility baggage we currently have.
> 
> In terms of using this new object in a consistent way to our current model, 
> we propose (subsequently) to generalize the types of objects which can be 
> referenced by imageSource and icon properties - allowing them to use any 
> object which 'knows how to be used as an icon'. Currently, only the image 
> object has this knowledge - but we can extend to other objects by getting 
> them to implement the appropriate internal interface. This would mean that 
> you could just replace the images you use currently for icons and such, with 
> the new control which supports SVG and use SVG instead.
> 
> Given the potential future path of this particular feature, we also propose 
> to eventually give it an actual control type - rather than widget (although 
> it will still be a widget). i.e. We think it is has such future potential 
> that being able to do ' "foo"' in script will be very useful (this is 
> almost a requirement if it is to eventually 'replace' the image and graphic 
> objects). [ Note: we have also been considering this for the browser widget 
> too! ].
> 
> Thus with all that in mind - we are proposing 'picture' as the name of the 
> new SVG capable control, with the following ideal roadmap:
> 
>  a) we would integrate the 'prototype' implemented for SVG as 
> 'com.livecode.widget.picture'
> 
>  b) we would add a 'picture' noun to the language as the control type for 
> that widget
> 
>  c) we would add icon reference support, allowing it to be used in place of 
> an image
> 
>  d) we would add graphic-like shape properties, allowing you to use it in 
> 

Re: The coming of SVG

[Klaus major-k via use-livecode]

Hi Mark

> Am 03.11.2017 um 14:19 schrieb Mark Waddingham via use-livecode 
> :
> 
> Hi all,
> 
> My most recent talk at LCG (in October) was 'Building an SVG Widget' and in 
> order to talk about such a thing, I needed to actually build one - so I did :)
> 
> So, we are now firmly on the road to full SVG support in LiveCode!
> 
> At the moment the implementation only supports geometric shape tags, paths, 
> and solid color fills. However, it supports the standard fill/stroke 
> attributes and should work ...
> 
>  a) we would integrate the 'prototype' implemented for SVG as 
> 'com.livecode.widget.picture'
>  b) we would add a 'picture' noun to the language as the control type for 
> that widget
>  c) we would add icon reference support, allowing it to be used in place of 
> an image
>  d) we would add graphic-like shape properties, allowing you to use it in 
> place of a graphic
>  e) we would add support to the image tag in svg, and image-like image 
> properties, allowing it to be used in place of an image
>  f) we would gradually expand support for the range of SVG it can directly 
> render (gradients and layers are high on the hit list here)
> 
> In terms of timescale, we are currently looking at delivering 'just' (a) for 
> 9.0 (although I do have my eye on at least (c) too - we'll have to see how 
> other things we still need to ...
> I look forward to reading any feedback you might have!
> 
> Warmest Regards,
> 
> Mark.

this is really wonderful news!

Some questions regarding C: 
When using an image as a button icon, the size of the image in button = size of 
the image with that ID.
Will this behaviour be the same with SVG "icons"? Or will we be able to display 
the same SVG in different 
buttons at different sizes? Know what I mean?

If that is possible, then we would need another property for buttons (or the 
SVGs?) to be able to scale the 
icon inside of the button. Something to consider, I think. :-)


Best

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
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

[Mark Waddingham via use-livecode]

On 2017-11-03 14:19, Mark Waddingham via use-livecode wrote:

Hi all,

My most recent talk at LCG (in October) was 'Building an SVG Widget'
and in order to talk about such a thing, I needed to actually build
one - so I did :)

So, we are now firmly on the road to full SVG support in LiveCode!


For anyone interested in the gory details, I've just submitted the 
initial PR

containing the implementation I did for LCG:

  https://github.com/livecode/livecode/pull/6099

It consists of around 2000 lines of LCS, and 400 lines of LCB, along 
with

a specification text file.

This should be considered a Work-In-Progress - the name is currently 
vectoricon
and the persistent state of the widget is not yet stable. The former 
will get
updated when we finally decide on a suitable name; the latter will get 
updated
when I've finished planning the fine details of the initial set of 
properties

it needs.

The widget itself is really easy to use - you drag one out and set the 
'svgText'
property of the widget to the content of an SVG file (i.e. the actual 
XML text,
not a filename). If the SVG has a 'viewBox' top-level attribute, then 
that area
of the (SVG) 'canvas' will be scaled to fit into the widget's rect; 
otherwise the

canvas will be rendered as defined.

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

[prothero--- via use-livecode]

This is great news!
Bill

William Prothero
http://es.earthednet.org

> On Nov 3, 2017, at 8:18 AM, Mike Kerner via use-livecode 
>  wrote:
> 
> OOOH.  Cool.  So pretty soon maybe I can render interfaces in Sketch
> after applying themes from my favorite interface design houses...
> 
> On Fri, Nov 3, 2017 at 9:19 AM, Mark Waddingham via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> Hi all,
>> 
>> My most recent talk at LCG (in October) was 'Building an SVG Widget' and
>> in order to talk about such a thing, I needed to actually build one - so I
>> did :)
>> 
>> So, we are now firmly on the road to full SVG support in LiveCode!
>> 
>> At the moment the implementation only supports geometric shape tags,
>> paths, and solid color fills. However, it supports the standard fill/stroke
>> attributes and should work with any SVG file - anything which isn't
>> supported just doesn't get rendered (so you have a modicum of graceful
>> degradation in terms of features). In particular, you don't need to
>> preprocess your SVG file to pull out incompatible tags / attributes, or
>> just extract the path (as you do for the SVGIcon widget).
>> 
>> The current implementation successfully renders quite a wide range of
>> simple SVGs (simple in the features they use, rather than how they look!).
>> Indeed, it happily renders the (quite widely known) Tiger and Lion SVGs,
>> and has been tested on quite a few random SVGs I managed to find on
>> Wikipedia. It is certainly more than capable if you want to use simply
>> coloured multi-path SVGs.
>> 
>> LCG attendees got a prototype of a widget to play with - called vectoricon
>> - and integrating this initial version this into the product has now got to
>> the top of my work-list :)
>> 
>> The principal thing which I'd like some feedback on right now is the name
>> of the widget/control - I think we have a good one, but wanted to see what
>> you all thought before committing us to it forever and a day.
>> 
>> Before getting to that though, I should perhaps explain what a potential
>> path for the evolution of this new feature in LiveCode could look like.
>> 
>> SVG as a concept allows arbitrary collections of vector shapes, images and
>> text to be represented in a single high-level way as XML - in particular,
>> you can express geometric shapes, raster images and text all in one unified
>> form.
>> 
>> Previously we had proposed producing a 'shape' object which would be a
>> 'graphic object on steroids' - allowing affine transformation, higher
>> fidelity specification of geometric objects and groups of them; providing
>> an 'svgText' interface similar to htmlText on the field. Essentially, the
>> proposed 'shape' object would have used a subset of SVG to allow easy
>> interchange of what it represents.
>> 
>> That notion of 'shape' object (and thus the current 'graphic' object) can
>> be subsumed into the SVG implementation in an obvious way - if you ask your
>> SVG object to be a rectangle, it creates (notionally) the SVG for a
>> rectangle internally and uses that - which you would see via the svgText.
>> 
>> Similarly, as SVG can represent raster images too, we can fold the current
>> behavior of the 'image' object into it to - in a similar way.
>> 
>> The end result here would be a single object which is a generalization of
>> two existing objects - image and graphic - but without the
>> backwards-compatibility baggage we currently have.
>> 
>> In terms of using this new object in a consistent way to our current
>> model, we propose (subsequently) to generalize the types of objects which
>> can be referenced by imageSource and icon properties - allowing them to use
>> any object which 'knows how to be used as an icon'. Currently, only the
>> image object has this knowledge - but we can extend to other objects by
>> getting them to implement the appropriate internal interface. This would
>> mean that you could just replace the images you use currently for icons and
>> such, with the new control which supports SVG and use SVG instead.
>> 
>> Given the potential future path of this particular feature, we also
>> propose to eventually give it an actual control type - rather than widget
>> (although it will still be a widget). i.e. We think it is has such future
>> potential that being able to do ' "foo"' in script will be very
>> useful (this is almost a requirement if it is to eventually 'replace' the
>> image and graphic objects). [ Note: we have also been considering this for
>> the browser widget too! ].
>> 
>> Thus with all that in mind - we are proposing 'picture' as the name of the
>> new SVG capable control, with the following ideal roadmap:
>> 
>>  a) we would integrate the 'prototype' implemented for SVG as
>> 'com.livecode.widget.picture'
>> 
>>  b) we would add a 'picture' noun to the language as the control type for
>> that widget
>> 
>>  c) we would add icon reference support, allowing it to be used in place
>> of 

Re: The coming of SVG

[Mike Kerner via use-livecode]

OOOH.  Cool.  So pretty soon maybe I can render interfaces in Sketch
after applying themes from my favorite interface design houses...

On Fri, Nov 3, 2017 at 9:19 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi all,
>
> My most recent talk at LCG (in October) was 'Building an SVG Widget' and
> in order to talk about such a thing, I needed to actually build one - so I
> did :)
>
> So, we are now firmly on the road to full SVG support in LiveCode!
>
> At the moment the implementation only supports geometric shape tags,
> paths, and solid color fills. However, it supports the standard fill/stroke
> attributes and should work with any SVG file - anything which isn't
> supported just doesn't get rendered (so you have a modicum of graceful
> degradation in terms of features). In particular, you don't need to
> preprocess your SVG file to pull out incompatible tags / attributes, or
> just extract the path (as you do for the SVGIcon widget).
>
> The current implementation successfully renders quite a wide range of
> simple SVGs (simple in the features they use, rather than how they look!).
> Indeed, it happily renders the (quite widely known) Tiger and Lion SVGs,
> and has been tested on quite a few random SVGs I managed to find on
> Wikipedia. It is certainly more than capable if you want to use simply
> coloured multi-path SVGs.
>
> LCG attendees got a prototype of a widget to play with - called vectoricon
> - and integrating this initial version this into the product has now got to
> the top of my work-list :)
>
> The principal thing which I'd like some feedback on right now is the name
> of the widget/control - I think we have a good one, but wanted to see what
> you all thought before committing us to it forever and a day.
>
> Before getting to that though, I should perhaps explain what a potential
> path for the evolution of this new feature in LiveCode could look like.
>
> SVG as a concept allows arbitrary collections of vector shapes, images and
> text to be represented in a single high-level way as XML - in particular,
> you can express geometric shapes, raster images and text all in one unified
> form.
>
> Previously we had proposed producing a 'shape' object which would be a
> 'graphic object on steroids' - allowing affine transformation, higher
> fidelity specification of geometric objects and groups of them; providing
> an 'svgText' interface similar to htmlText on the field. Essentially, the
> proposed 'shape' object would have used a subset of SVG to allow easy
> interchange of what it represents.
>
> That notion of 'shape' object (and thus the current 'graphic' object) can
> be subsumed into the SVG implementation in an obvious way - if you ask your
> SVG object to be a rectangle, it creates (notionally) the SVG for a
> rectangle internally and uses that - which you would see via the svgText.
>
> Similarly, as SVG can represent raster images too, we can fold the current
> behavior of the 'image' object into it to - in a similar way.
>
> The end result here would be a single object which is a generalization of
> two existing objects - image and graphic - but without the
> backwards-compatibility baggage we currently have.
>
> In terms of using this new object in a consistent way to our current
> model, we propose (subsequently) to generalize the types of objects which
> can be referenced by imageSource and icon properties - allowing them to use
> any object which 'knows how to be used as an icon'. Currently, only the
> image object has this knowledge - but we can extend to other objects by
> getting them to implement the appropriate internal interface. This would
> mean that you could just replace the images you use currently for icons and
> such, with the new control which supports SVG and use SVG instead.
>
> Given the potential future path of this particular feature, we also
> propose to eventually give it an actual control type - rather than widget
> (although it will still be a widget). i.e. We think it is has such future
> potential that being able to do ' "foo"' in script will be very
> useful (this is almost a requirement if it is to eventually 'replace' the
> image and graphic objects). [ Note: we have also been considering this for
> the browser widget too! ].
>
> Thus with all that in mind - we are proposing 'picture' as the name of the
> new SVG capable control, with the following ideal roadmap:
>
>   a) we would integrate the 'prototype' implemented for SVG as
> 'com.livecode.widget.picture'
>
>   b) we would add a 'picture' noun to the language as the control type for
> that widget
>
>   c) we would add icon reference support, allowing it to be used in place
> of an image
>
>   d) we would add graphic-like shape properties, allowing you to use it in
> place of a graphic
>
>   e) we would add support to the image tag in svg, and image-like image
> properties, allowing it to be used in place of an image
>
>   f) we would gradually expand support 

The coming of SVG

[Mark Waddingham via use-livecode]

Hi all,

My most recent talk at LCG (in October) was 'Building an SVG Widget' and 
in order to talk about such a thing, I needed to actually build one - so 
I did :)


So, we are now firmly on the road to full SVG support in LiveCode!

At the moment the implementation only supports geometric shape tags, 
paths, and solid color fills. However, it supports the standard 
fill/stroke attributes and should work with any SVG file - anything 
which isn't supported just doesn't get rendered (so you have a modicum 
of graceful degradation in terms of features). In particular, you don't 
need to preprocess your SVG file to pull out incompatible tags / 
attributes, or just extract the path (as you do for the SVGIcon widget).


The current implementation successfully renders quite a wide range of 
simple SVGs (simple in the features they use, rather than how they 
look!). Indeed, it happily renders the (quite widely known) Tiger and 
Lion SVGs, and has been tested on quite a few random SVGs I managed to 
find on Wikipedia. It is certainly more than capable if you want to use 
simply coloured multi-path SVGs.


LCG attendees got a prototype of a widget to play with - called 
vectoricon - and integrating this initial version this into the product 
has now got to the top of my work-list :)


The principal thing which I'd like some feedback on right now is the 
name of the widget/control - I think we have a good one, but wanted to 
see what you all thought before committing us to it forever and a day.


Before getting to that though, I should perhaps explain what a potential 
path for the evolution of this new feature in LiveCode could look like.


SVG as a concept allows arbitrary collections of vector shapes, images 
and text to be represented in a single high-level way as XML - in 
particular, you can express geometric shapes, raster images and text all 
in one unified form.


Previously we had proposed producing a 'shape' object which would be a 
'graphic object on steroids' - allowing affine transformation, higher 
fidelity specification of geometric objects and groups of them; 
providing an 'svgText' interface similar to htmlText on the field. 
Essentially, the proposed 'shape' object would have used a subset of SVG 
to allow easy interchange of what it represents.


That notion of 'shape' object (and thus the current 'graphic' object) 
can be subsumed into the SVG implementation in an obvious way - if you 
ask your SVG object to be a rectangle, it creates (notionally) the SVG 
for a rectangle internally and uses that - which you would see via the 
svgText.


Similarly, as SVG can represent raster images too, we can fold the 
current behavior of the 'image' object into it to - in a similar way.


The end result here would be a single object which is a generalization 
of two existing objects - image and graphic - but without the 
backwards-compatibility baggage we currently have.


In terms of using this new object in a consistent way to our current 
model, we propose (subsequently) to generalize the types of objects 
which can be referenced by imageSource and icon properties - allowing 
them to use any object which 'knows how to be used as an icon'. 
Currently, only the image object has this knowledge - but we can extend 
to other objects by getting them to implement the appropriate internal 
interface. This would mean that you could just replace the images you 
use currently for icons and such, with the new control which supports 
SVG and use SVG instead.


Given the potential future path of this particular feature, we also 
propose to eventually give it an actual control type - rather than 
widget (although it will still be a widget). i.e. We think it is has 
such future potential that being able to do ' "foo"' in script 
will be very useful (this is almost a requirement if it is to eventually 
'replace' the image and graphic objects). [ Note: we have also been 
considering this for the browser widget too! ].


Thus with all that in mind - we are proposing 'picture' as the name of 
the new SVG capable control, with the following ideal roadmap:


  a) we would integrate the 'prototype' implemented for SVG as 
'com.livecode.widget.picture'


  b) we would add a 'picture' noun to the language as the control type 
for that widget


  c) we would add icon reference support, allowing it to be used in 
place of an image


  d) we would add graphic-like shape properties, allowing you to use it 
in place of a graphic


  e) we would add support to the image tag in svg, and image-like image 
properties, allowing it to be used in place of an image


  f) we would gradually expand support for the range of SVG it can 
directly render (gradients and layers are high on the hit list here)


In terms of timescale, we are currently looking at delivering 'just' (a) 
for 9.0 (although I do have my eye on at least (c) too - we'll have to 
see how other things we still need to finish for 9 go). The rest all 
break down into