Vector images?

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Vector images?

Richmond Mathewson-2
Why do I have a feeling that the ability to import vector images as
vector graphics
was meant to be one of the goals of the kickstarter?

Richmond.

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Vector images?

Colin Holgate-3
My guess is that it’s because it might have been a goal in the Kickstarter campaign. That may be why they added the SVG Widget. You should try it.


> On Oct 9, 2015, at 12:57 PM, Richmond <[hidden email]> wrote:
>
> Why do I have a feeling that the ability to import vector images as vector graphics
> was meant to be one of the goals of the kickstarter?

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Vector images?

Richmond Mathewson-2
On 09/10/15 20:08, Colin Holgate wrote:
> My guess is that it’s because it might have been a goal in the Kickstarter campaign. That may be why they added the SVG Widget. You should try it.
Well, I did and could not for the life of me work out how it worked.

I ended up with what looked like a Communist star, and no indication how
I could import, for the sake of argument,
a dollar sign in .svg format.

Richmond.

>
>> On Oct 9, 2015, at 12:57 PM, Richmond <[hidden email]> wrote:
>>
>> Why do I have a feeling that the ability to import vector images as vector graphics
>> was meant to be one of the goals of the kickstarter?
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Vector images?

Colin Holgate-3
Click on the star and you can choose from a long list of built in images. The dollar sign looking one is near the bottom.

Failing that, you can open an SVG file in a text editor, and copy the path data part, to paste into the iconPath field in LiveCode.

Now, they should add a Source option, which could do the retrieving of the path data for you. That would be handy.


> On Oct 9, 2015, at 1:21 PM, Richmond <[hidden email]> wrote:
>
> On 09/10/15 20:08, Colin Holgate wrote:
>> My guess is that it’s because it might have been a goal in the Kickstarter campaign. That may be why they added the SVG Widget. You should try it.
> Well, I did and could not for the life of me work out how it worked.
>
> I ended up with what looked like a Communist star, and no indication how I could import, for the sake of argument,
> a dollar sign in .svg format.
>
> Richmond.
>
>>
>>> On Oct 9, 2015, at 12:57 PM, Richmond <[hidden email]> wrote:
>>>
>>> Why do I have a feeling that the ability to import vector images as vector graphics
>>> was meant to be one of the goals of the kickstarter?
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Vector images?

Richmond Mathewson-2
On 09/10/15 20:33, Colin Holgate wrote:
> Click on the star and you can choose from a long list of built in images. The dollar sign looking one is near the bottom.
>
> Failing that, you can open an SVG file in a text editor, and copy the path data part, to paste into the iconPath field in LiveCode.
>
> Now, they should add a Source option, which could do the retrieving of the path data for you. That would be handy.

I am probably expecting too much: I was expecting the ability to import
an svg file to be present in the

File / Import as Control / Image file  menu item.

And why, forbye, is that not the case? The way it is implemented is
awkward, non-logical, and, frankly bloody-minded.

R.

>
>
>> On Oct 9, 2015, at 1:21 PM, Richmond <[hidden email]> wrote:
>>
>> On 09/10/15 20:08, Colin Holgate wrote:
>>> My guess is that it’s because it might have been a goal in the Kickstarter campaign. That may be why they added the SVG Widget. You should try it.
>> Well, I did and could not for the life of me work out how it worked.
>>
>> I ended up with what looked like a Communist star, and no indication how I could import, for the sake of argument,
>> a dollar sign in .svg format.
>>
>> Richmond.
>>
>>>> On Oct 9, 2015, at 12:57 PM, Richmond <[hidden email]> wrote:
>>>>
>>>> Why do I have a feeling that the ability to import vector images as vector graphics
>>>> was meant to be one of the goals of the kickstarter?
>>> _______________________________________________
>>> use-livecode mailing list
>>> [hidden email]
>>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Vector images?

Ali Lloyd-2
That seems sensible. You could file an enhancement request ;-)

To be honest it's more a case of "not everything has been done yet" than
"we think you ought to do it this long-winded way".

On Fri, Oct 9, 2015 at 7:33 PM Richmond <[hidden email]> wrote:

> On 09/10/15 20:33, Colin Holgate wrote:
> > Click on the star and you can choose from a long list of built in
> images. The dollar sign looking one is near the bottom.
> >
> > Failing that, you can open an SVG file in a text editor, and copy the
> path data part, to paste into the iconPath field in LiveCode.
> >
> > Now, they should add a Source option, which could do the retrieving of
> the path data for you. That would be handy.
>
> I am probably expecting too much: I was expecting the ability to import
> an svg file to be present in the
>
> File / Import as Control / Image file  menu item.
>
> And why, forbye, is that not the case? The way it is implemented is
> awkward, non-logical, and, frankly bloody-minded.
>
> R.
>
> >
> >
> >> On Oct 9, 2015, at 1:21 PM, Richmond <[hidden email]>
> wrote:
> >>
> >> On 09/10/15 20:08, Colin Holgate wrote:
> >>> My guess is that it’s because it might have been a goal in the
> Kickstarter campaign. That may be why they added the SVG Widget. You should
> try it.
> >> Well, I did and could not for the life of me work out how it worked.
> >>
> >> I ended up with what looked like a Communist star, and no indication
> how I could import, for the sake of argument,
> >> a dollar sign in .svg format.
> >>
> >> Richmond.
> >>
> >>>> On Oct 9, 2015, at 12:57 PM, Richmond <[hidden email]>
> wrote:
> >>>>
> >>>> Why do I have a feeling that the ability to import vector images as
> vector graphics
> >>>> was meant to be one of the goals of the kickstarter?
> >>> _______________________________________________
> >>> use-livecode mailing list
> >>> [hidden email]
> >>> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> >>> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>
> >> _______________________________________________
> >> use-livecode mailing list
> >> [hidden email]
> >> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Vector images?

Mark Waddingham-2
In reply to this post by Richmond Mathewson-2
On 2015-10-09 18:57, Richmond wrote:
> Why do I have a feeling that the ability to import vector images as
> vector graphics
> was meant to be one of the goals of the kickstarter?

Well that very much depends on what you mean by 'vector images' ;)

The exact Kickstarter stretch goal was this:

   Vector Shape Object

   Like the graphic object on steroids. Sub-pixel positioning,
   shape determined by intrinsic properties (i.e. width of rectangle,
   radius of circle etc.). 'Group' type, containing a collection of
   shapes to be nested - and imported/exported in a (subset of) SVG.

There is still some more work needed on the widget's architecture to
make this a reality (mainly related to ensuring that the rect of the
widget is determined by its internal geometry, rather than the other way
round which makes BIG difference if you want to do effective and
tile-able affine transformations and avoid animation 'jitter' from
issues surrounding aligning to an integer grid).

However, after spending some time at a weekend recently playing with a
small subset-SVG-parsing library I found, I've come up with this:
https://github.com/livecode/livecode/pull/3089.

This widget enables rendering of simple SVG files consisting of shapes,
paths, transforms, stroke properties, color fills, linear and radial
gradients. This is nowhere near the whole of SVG, certainly, but is a
useful enough subset for icons and such I'd have thought.

I'm currently working out how we can hook such widgets into the 'icon'
mechanism in the engine - meaning that such a widget could be used as
the source of icons in buttons and imgSrcs in fields. Also, it would be
good if there could be some sharing of the parsed SVG data structures if
multiple SVG widgets reference the same file (a bit like referenced
image objects share in-memory representations to minimize memory cost).

It isn't quite ready for inclusion in a build so it will unlikely be in
DP8 (due this week), I'm hoping it will be ready shortly after that
though.

Just thought people might be interested in this (little) development :)

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Vector images?

Richmond Mathewson-2
On 20/10/15 19:04, Mark Waddingham wrote:

> On 2015-10-09 18:57, Richmond wrote:
>> Why do I have a feeling that the ability to import vector images as
>> vector graphics
>> was meant to be one of the goals of the kickstarter?
>
> Well that very much depends on what you mean by 'vector images' ;)
>
> The exact Kickstarter stretch goal was this:
>
>   Vector Shape Object
>
>   Like the graphic object on steroids. Sub-pixel positioning,
>   shape determined by intrinsic properties (i.e. width of rectangle,
>   radius of circle etc.). 'Group' type, containing a collection of
>   shapes to be nested - and imported/exported in a (subset of) SVG.
>
> There is still some more work needed on the widget's architecture to
> make this a reality (mainly related to ensuring that the rect of the
> widget is determined by its internal geometry, rather than the other
> way round which makes BIG difference if you want to do effective and
> tile-able affine transformations and avoid animation 'jitter' from
> issues surrounding aligning to an integer grid).
>
> However, after spending some time at a weekend recently playing with a
> small subset-SVG-parsing library I found, I've come up with this:
> https://github.com/livecode/livecode/pull/3089.
>
> This widget enables rendering of simple SVG files consisting of
> shapes, paths, transforms, stroke properties, color fills, linear and
> radial gradients. This is nowhere near the whole of SVG, certainly,
> but is a useful enough subset for icons and such I'd have thought.
>
> I'm currently working out how we can hook such widgets into the 'icon'
> mechanism in the engine - meaning that such a widget could be used as
> the source of icons in buttons and imgSrcs in fields. Also, it would
> be good if there could be some sharing of the parsed SVG data
> structures if multiple SVG widgets reference the same file (a bit like
> referenced image objects share in-memory representations to minimize
> memory cost).
>
> It isn't quite ready for inclusion in a build so it will unlikely be
> in DP8 (due this week), I'm hoping it will be ready shortly after that
> though.
>
> Just thought people might be interested in this (little) development :)
>
> Warmest Regards,
>
> Mark.
>

That certainly looks exciting.

What I was wondering about was the ability to make SVG files externally
and then import them, and, similarly, to export
vector graphics from LiveCode in SVG format.

Richmond.

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Vector images?

ScottR
In reply to this post by Mark Waddingham-2
Mark, what you describe sounds great.  Even a subset of SVG capabilities
is very welcome.

But I have to ask, partly because I'm clueless when it comes to low level
programming, but also because I'm curious: does it make sense to have two
"realms" of graphics?  There are card based (native) graphics, and then
there are the graphics inside widgets.  I recall reading that all of the
graphics rendering in LC was going to be moved over to the skia graphics
library.  Is this what enables the display of SVG in widgets or is
graphics rendering in widgets based on something else?  What prevents the
display of SVG graphics outside of a widget?  As it stands, there are
graphics capabilities within widgets that don't apply to native graphics.
Would it not make more sense to have a single universal approach to all
graphics in LC?

And to confirm your comment, yes, some of us people are definitely
interested in your (little) development.

Best Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 10/20/15, 9:04 AM, "use-livecode on behalf of Mark Waddingham"
<[hidden email] on behalf of [hidden email]>
wrote:

>On 2015-10-09 18:57, Richmond wrote:
>> Why do I have a feeling that the ability to import vector images as
>> vector graphics
>> was meant to be one of the goals of the kickstarter?
>
>Well that very much depends on what you mean by 'vector images' ;)
>
>The exact Kickstarter stretch goal was this:
>
>   Vector Shape Object
>
>   Like the graphic object on steroids. Sub-pixel positioning,
>   shape determined by intrinsic properties (i.e. width of rectangle,
>   radius of circle etc.). 'Group' type, containing a collection of
>   shapes to be nested - and imported/exported in a (subset of) SVG.
>
>There is still some more work needed on the widget's architecture to
>make this a reality (mainly related to ensuring that the rect of the
>widget is determined by its internal geometry, rather than the other way
>round which makes BIG difference if you want to do effective and
>tile-able affine transformations and avoid animation 'jitter' from
>issues surrounding aligning to an integer grid).
>
>However, after spending some time at a weekend recently playing with a
>small subset-SVG-parsing library I found, I've come up with this:
>https://github.com/livecode/livecode/pull/3089.
>
>This widget enables rendering of simple SVG files consisting of shapes,
>paths, transforms, stroke properties, color fills, linear and radial
>gradients. This is nowhere near the whole of SVG, certainly, but is a
>useful enough subset for icons and such I'd have thought.
>
>I'm currently working out how we can hook such widgets into the 'icon'
>mechanism in the engine - meaning that such a widget could be used as
>the source of icons in buttons and imgSrcs in fields. Also, it would be
>good if there could be some sharing of the parsed SVG data structures if
>multiple SVG widgets reference the same file (a bit like referenced
>image objects share in-memory representations to minimize memory cost).
>
>It isn't quite ready for inclusion in a build so it will unlikely be in
>DP8 (due this week), I'm hoping it will be ready shortly after that
>though.
>
>Just thought people might be interested in this (little) development :)
>
>Warmest Regards,
>
>Mark.
>
>--
>Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
>LiveCode: Everyone can create apps
>
>_______________________________________________
>use-livecode mailing list
>[hidden email]
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Vector images?

Richmond Mathewson-2
On 20/10/15 22:35, Scott Rossi wrote:

> Mark, what you describe sounds great.  Even a subset of SVG capabilities
> is very welcome.
>
> But I have to ask, partly because I'm clueless when it comes to low level
> programming, but also because I'm curious: does it make sense to have two
> "realms" of graphics?  There are card based (native) graphics, and then
> there are the graphics inside widgets.  I recall reading that all of the
> graphics rendering in LC was going to be moved over to the skia graphics
> library.  Is this what enables the display of SVG in widgets or is
> graphics rendering in widgets based on something else?  What prevents the
> display of SVG graphics outside of a widget?  As it stands, there are
> graphics capabilities within widgets that don't apply to native graphics.
> Would it not make more sense to have a single universal approach to all
> graphics in LC?

This is a very important question to which the answer really does need
to be "Yes".

Now, I am a person who works at the "kiddy" end of LiveCode who makes no
pretensions to understand
the inner workings of an SVG file as opposed to that of a PNG file.

What I do know is that as there is a menu item to either import or
reference images that would seem
the logical place for SVG images to be handled.

A longish time ago LiveCode (then called Revolution) allowed one to
import EPS vector images
via the menu system: why SVG images need to be handled in a completely
different way vis-a-vis
the GUI entirely escapes me.

>
> And to confirm your comment, yes, some of us people are definitely
> interested in your (little) development.

The ability to import, export, manipulate and, possibly, manufacture SVG
images in LiveCode is not
a "little" development, it is very important.

Vector graphics are part of what we could call "the standard set", and
indeed have been for rather
longer than perhaps most people are aware, and RunRev's decision to drop
EPS image import
seemed odd and wrong at the time it happened: importing SVG images would
serve to rectify
what I, for one, feel was a backward move.

>
> Best Regards,
>
> Scott Rossi
> Creative Director
> Tactile Media, UX/UI Design

More strength to your SVG elbow!

Richmond.

>
>
>
> On 10/20/15, 9:04 AM, "use-livecode on behalf of Mark Waddingham"
> <[hidden email] on behalf of [hidden email]>
> wrote:
>
>> On 2015-10-09 18:57, Richmond wrote:
>>> Why do I have a feeling that the ability to import vector images as
>>> vector graphics
>>> was meant to be one of the goals of the kickstarter?
>> Well that very much depends on what you mean by 'vector images' ;)
>>
>> The exact Kickstarter stretch goal was this:
>>
>>    Vector Shape Object
>>
>>    Like the graphic object on steroids. Sub-pixel positioning,
>>    shape determined by intrinsic properties (i.e. width of rectangle,
>>    radius of circle etc.). 'Group' type, containing a collection of
>>    shapes to be nested - and imported/exported in a (subset of) SVG.
>>
>> There is still some more work needed on the widget's architecture to
>> make this a reality (mainly related to ensuring that the rect of the
>> widget is determined by its internal geometry, rather than the other way
>> round which makes BIG difference if you want to do effective and
>> tile-able affine transformations and avoid animation 'jitter' from
>> issues surrounding aligning to an integer grid).
>>
>> However, after spending some time at a weekend recently playing with a
>> small subset-SVG-parsing library I found, I've come up with this:
>> https://github.com/livecode/livecode/pull/3089.
>>
>> This widget enables rendering of simple SVG files consisting of shapes,
>> paths, transforms, stroke properties, color fills, linear and radial
>> gradients. This is nowhere near the whole of SVG, certainly, but is a
>> useful enough subset for icons and such I'd have thought.
>>
>> I'm currently working out how we can hook such widgets into the 'icon'
>> mechanism in the engine - meaning that such a widget could be used as
>> the source of icons in buttons and imgSrcs in fields. Also, it would be
>> good if there could be some sharing of the parsed SVG data structures if
>> multiple SVG widgets reference the same file (a bit like referenced
>> image objects share in-memory representations to minimize memory cost).
>>
>> It isn't quite ready for inclusion in a build so it will unlikely be in
>> DP8 (due this week), I'm hoping it will be ready shortly after that
>> though.
>>
>> Just thought people might be interested in this (little) development :)
>>
>> Warmest Regards,
>>
>> Mark.
>>
>> --
>> Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
>> LiveCode: Everyone can create apps
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Vector images?

J. Landman Gay
On 10/20/2015 2:49 PM, Richmond wrote:
> RunRev's decision to drop EPS image import
> seemed odd and wrong at the time it happened

It's still listed in the "import" command in the dictionary. EPS has
always been available only on Linux, so it will fail anywhere else. You
could try it and see if the dictionary is wrong.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Vector images?

Monte Goulding
In reply to this post by Richmond Mathewson-2

> On 21 Oct 2015, at 6:49 am, Richmond <[hidden email]> wrote:
>
> A longish time ago LiveCode (then called Revolution) allowed one to import EPS vector images
> via the menu system: why SVG images need to be handled in a completely different way vis-a-vis
> the GUI entirely escapes me.

I think you are confusing the fact that it is implemented as a widget and how the IDE might or might not integrate it. It seems reasonable to me that widgets that represent files might have some way to hook into the file menu which would give you what you are looking for here.

As far as the two levels of graphics that’s not really the case. Actually we have two levels of drawing with LCB widgets built around providing access to what skia can do.

Cheers

--
M E R Goulding <http://goulding.ws/>
Software development services
Bespoke application development for vertical markets

mergExt <http://mergext.com/> - There's an external for that!

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Vector images?

Mark Waddingham-2
In reply to this post by J. Landman Gay
Unfortunately it was only ever available on UNIX systems which had a 'display postscript' enabled X server. These were never... Cheap.

Sent from my iPhone

> On 20 Oct 2015, at 21:34, J. Landman Gay <[hidden email]> wrote:
>
>> On 10/20/2015 2:49 PM, Richmond wrote:
>> RunRev's decision to drop EPS image import
>> seemed odd and wrong at the time it happened
>
> It's still listed in the "import" command in the dictionary. EPS has always been available only on Linux, so it will fail anywhere else. You could try it and see if the dictionary is wrong.
>
> --
> Jacqueline Landman Gay         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Vector images?

Richmond Mathewson-2
In reply to this post by Monte Goulding
 From a fairly bitchy point of view it does seem odd
that Scratch, a sort of kiddy half-cock programming thing
that strikes me as just the type of dumbing down that does children
ultimately no favours at all can:

Import, Create, and Export SVG files,

while LiveCode cannot (yet???).

http://www.wikihow.com/Import-and-Export-Vector-Images-in-Scratch-2.0

admittedly Scratch uses "an irregular SVG format": still, a lot better
than nothing
(not that you'll see me using Scratch except to rub somebody else's face
it it).

Richmond.

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Vector images?

Richmond Mathewson-2
On 21/10/15 10:27, Richmond wrote:

> From a fairly bitchy point of view it does seem odd
> that Scratch, a sort of kiddy half-cock programming thing
> that strikes me as just the type of dumbing down that does children
> ultimately no favours at all can:
>
> Import, Create, and Export SVG files,
>
> while LiveCode cannot (yet???).
>
> http://www.wikihow.com/Import-and-Export-Vector-Images-in-Scratch-2.0
>
> admittedly Scratch uses "an irregular SVG format": still, a lot better
> than nothing
> (not that you'll see me using Scratch except to rub somebody else's
> face it it).
>
> Richmond.

And . . . http://www.supercard.us/hypercard/

"SuperCard even supports high resolution bitmaps and vector graphics."

what that actually entails is another question.

R.

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Vector images?

Mark Waddingham-2
In reply to this post by Richmond Mathewson-2
On 2015-10-20 21:49, Richmond wrote:
> This is a very important question to which the answer really does need
> to be "Yes".

I think you are confusing the underlying ability to import and render
SVG (which will be used by the components which are created to sit atop
it - which the current development is a step towards), and how that
might be integrated into other parts of the engine and exposed to the
user in various ways.

> What I do know is that as there is a menu item to either import or
> reference images that would seem
> the logical place for SVG images to be handled.

Indeed. The current patch is just the lower-level bit which (a) allows
various bits (well, widgets and potentially other parts of the engine)
to parse and render SVG and (b) a widget which displays an SVG file.

It would make perfect sense for the IDE to have an 'import svg' menu
item or some such.

> A longish time ago LiveCode (then called Revolution) allowed one to
> import EPS vector images
> via the menu system: why SVG images need to be handled in a completely
> different way vis-a-vis
> the GUI entirely escapes me.

I'm sorry - but this has simply never ever been the case. EPS support
only ever existed in UNIX builds of the engine for UNIX platforms which
used Display PostScript.

> The ability to import, export, manipulate and, possibly, manufacture
> SVG images in LiveCode is not
> a "little" development, it is very important.

Indeed - it is important - although how important will depend entirely
on what you are using LiveCode for.

SVG, at the end of the day, is just text. LiveCode is good at processing
text, so certainly export of SVG is something which can be done quite
happily, and well (and indeed quite sensibly) in script. Indeed, there
is even an SVG importer which has been around for a long time (although
it is slightly limited by some restrictions on the LiveCode graphic
object) also written in script.

Now, I'm not saying that having builtin import and rendering of SVG is a
great thing - because it is - however, it is by no means a panacea that
will solve all problems - it will, however, solve specific problems for
specific domains (some of which are, I suspect, ones that you face).

Similarly, an 'export snapshot ... as svg' command would also be useful
to solve specific problems for specific domains but, again, isn't going
to do so for everyone.

> Vector graphics are part of what we could call "the standard set", and
> indeed have been for rather
> longer than perhaps most people are aware, and RunRev's decision to
> drop EPS image import
> seemed odd and wrong at the time it happened: importing SVG images
> would serve to rectify
> what I, for one, feel was a backward move.

Again - EPS support was never dropped. It never existed on Windows, Mac
or Linux in the first place.

> More strength to your SVG elbow!

Just to go back to my point above about problem solving and applicable
domain. For you (and many others), I can see why simple SVG import
support is so important. There are a number of tools in the 'producing
graphics' domain which generate SVG, and there are a large number of SVG
files out there which have graphics which are highly suitable for the
uses you are putting LiveCode to.

However it is important to remember that not everyone uses LiveCode to
the same ends - there will probably be as many people on this list who
would see SVG as a much lower priority than <insert feature which would
help their particular problem domain and endeavours with LiveCode>.

Serving such a broad user base with a 'high-level' tool such as ours is
not an easy task as, ultimately, it takes time and human effort to add
any feature that people might want/need. This is a huge part of the
reason for 'why LCB and Widgets' - by making it MUCH easier to extend
the engine in ways that are indistinguishable (or getting that way,
anyway) from anything else in the engine we can get to a situation where
many more people (beyond just 'us' behind the LiveCode Ltd. veil) can
help others solve their LiveCode related problems.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Vector images?

Richmond Mathewson-2
On 21/10/15 10:56, Mark Waddingham wrote:
> On 2015-10-20 21:49, Richmond wrote:
>> This is a very important question to which the answer really does need
>> to be "Yes".
>
> I think you are confusing the underlying ability to import and render
> SVG (which will be used by the components which are created to sit
> atop it - which the current development is a step towards), and how
> that might be integrated into other parts of the engine and exposed to
> the user in various ways.

As an end-user ("bottom feeder" ???) I am concerned largely how that is
"exposed to the user".

I do not doubt your ability to do all the 'magic' (well, to me, at
least, it is magic) in the background.

I am not confusing anything: I know you can manage "the underlying
ability to import and render SVG",
and I am hoping you will expose that to the end-user via the menu for
image import that is already in place in the GUI.

>
>> What I do know is that as there is a menu item to either import or
>> reference images that would seem
>> the logical place for SVG images to be handled.
>
> Indeed. The current patch is just the lower-level bit which (a) allows
> various bits (well, widgets and potentially other parts of the engine)
> to parse and render SVG and (b) a widget which displays an SVG file.
>
> It would make perfect sense for the IDE to have an 'import svg' menu
> item or some such.
>
>> A longish time ago LiveCode (then called Revolution) allowed one to
>> import EPS vector images
>> via the menu system: why SVG images need to be handled in a completely
>> different way vis-a-vis
>> the GUI entirely escapes me.
>
> I'm sorry - but this has simply never ever been the case. EPS support
> only ever existed in UNIX builds of the engine for UNIX platforms
> which used Display PostScript.

You got me there :)

>
>> The ability to import, export, manipulate and, possibly, manufacture
>> SVG images in LiveCode is not
>> a "little" development, it is very important.
>
> Indeed - it is important - although how important will depend entirely
> on what you are using LiveCode for.

Well, vector images are very widely used, and they do have the advantage
over bitmapped ones in that they don't go "all fuzzy"
when they are resized: that, at the very least, is a big plus, and IF
(??????) the Geometry Manager is 'whatever' vector images
would sit very nicely with that.

>
> SVG, at the end of the day, is just text.

Well, aren't all 'documents'

> LiveCode is good at processing text, so certainly export of SVG is
> something which can be done quite happily, and well (and indeed quite
> sensibly) in script. Indeed, there is even an SVG importer which has
> been around for a long time (although it is slightly limited by some
> restrictions on the LiveCode graphic object) also written in script.

Alejandro . . .

>
> Now, I'm not saying that having builtin import and rendering of SVG is
> a great thing - because it is - however, it is by no means a panacea
> that will solve all problems - it will, however, solve specific
> problems for specific domains (some of which are, I suspect, ones that
> you face).

I only suffer, except when I forget my "place in the world", from a need
to churn out really extremely moronic programs for content
delivery and reinforcement to 4-14 year-old EFL learners: and those
could all be done with RR/LC version 2.

If LiveCode were to stop functioning and go "poof" off the face of the
Earth, although it would be extremely sad, I would be able to continue
churning out those silly little programs with LC 2 - 4.5 on my
out-of-date computers at least until I either retire, die, or go bonkers
(well, um,
some people may think that last one has already happened) whichever
comes first.

I use RR/LC 4.5 for my Devawriter Pro {Devanagari Sanskrit], PISMO
[Cyrillic and Glagolitic Slavic] and Grendel [Anglo-Saxon, OHG and runes].

So, anything, post version 4.5 comes as an extremely happy bonus for me.
So, notwithstanding all my fairly in-your-face criticisms, I think
LiveCode rocks-its-socks; especially as a teaching medium for
introducing young children to programming concepts.

I would tell any teachers who are "financially challenged" [= skint] to
get their hands on either a second-hand PPC Mac or a second-hand intel
machine and install Mac OS 104/5 or a Debian derivative (respectively)
and use RR/LiveCode for everything; coupled with GIMP.

>
> Similarly, an 'export snapshot ... as svg' command would also be
> useful to solve specific problems for specific domains but, again,
> isn't going to do so for everyone.

Well, we all know what attempting to keep everybody happy at the same
time results in: something that makes most people fed up.

>
>> Vector graphics are part of what we could call "the standard set", and
>> indeed have been for rather
>> longer than perhaps most people are aware, and RunRev's decision to
>> drop EPS image import
>> seemed odd and wrong at the time it happened: importing SVG images
>> would serve to rectify
>> what I, for one, feel was a backward move.
>
> Again - EPS support was never dropped. It never existed on Windows,
> Mac or Linux in the first place.

I still feel that Vector graphibs should be automatically "in the list":
SuperCard seems to cope with them, and has for quite some time.

>
>> More strength to your SVG elbow!
>
> Just to go back to my point above about problem solving and applicable
> domain. For you (and many others), I can see why simple SVG import
> support is so important. There are a number of tools in the 'producing
> graphics' domain which generate SVG, and there are a large number of
> SVG files out there which have graphics which are highly suitable for
> the uses you are putting LiveCode to.
>
> However it is important to remember that not everyone uses LiveCode to
> the same ends - there will probably be as many people on this list who
> would see SVG as a much lower priority than <insert feature which
> would help their particular problem domain and endeavours with LiveCode>.

Indeed.

But they are as entitled to bang-on about what they would like just as
much as I am entitled to bang on about graphics.

If they don't that is not my fault, and possibly their loss.

As my grandfather said; "There is never any harm in asking."

>
> Serving such a broad user base with a 'high-level' tool such as ours
> is not an easy task as, ultimately, it takes time and human effort to
> add any feature that people might want/need.

I share your pain. I have about 60 sets of parents who are perpetually
bothering me because "little Ivan" has got knitting classes from 4-5,
and they cannot understand that I cannot reschedule 12 kids for the sake
of just one of them. I have a smaller number of people to keep happy,
but I have a smaller income; so that probably squares us.

But, unless one wants to go and live on one's own with a fat bank
account to takes of one's needs (I wish !!!!), one has to do all that
juggling to
keep as many people happy as possible without putting other people's
noses out of joint.

> This is a huge part of the reason for 'why LCB and Widgets' - by
> making it MUCH easier to extend the engine in ways that are
> indistinguishable (or getting that way, anyway) from anything else in
> the engine we can get to a situation where many more people (beyond
> just 'us' behind the LiveCode Ltd. veil) can help others solve their
> LiveCode related problems.
>
> Warmest Regards,
>
> Mark.
>

Thanks so much for writing such a well thought-out reply to my post.

Richmond.

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Vector images?

Mark Waddingham-2
In reply to this post by ScottR
On 2015-10-20 21:35, Scott Rossi wrote:

> Mark, what you describe sounds great.  Even a subset of SVG
> capabilities
> is very welcome.
>
> But I have to ask, partly because I'm clueless when it comes to low
> level
> programming, but also because I'm curious: does it make sense to have
> two
> "realms" of graphics?  There are card based (native) graphics, and then
> there are the graphics inside widgets.  I recall reading that all of
> the
> graphics rendering in LC was going to be moved over to the skia
> graphics
> library.  Is this what enables the display of SVG in widgets or is
> graphics rendering in widgets based on something else?  What prevents
> the
> display of SVG graphics outside of a widget?  As it stands, there are
> graphics capabilities within widgets that don't apply to native
> graphics.
> Would it not make more sense to have a single universal approach to all
> graphics in LC?

There are a number of things to answer in your question, so I shall
attempt to do so (apologies in advance, what follows is quite long - I
thought it useful to provide a fair amount of background - answers to
your direct questions are at the end!)

--

First and foremost, the most important thing to bear in mind is that
widgets are a way to write engine controls in both a way which is an
order of magnitude easier than doing so in C++ *and* in a much more
accessible way (the number of people in the community at present who
either have the necessary knowledge and/or interest in writing C++ is
very very small). So, widgets are not special, they aren't doing
anything the engine doesn't already have the facilities for - they just
allow said facilities to be exposed at the LiveCode Script level in a
much easier and quicker way than we could ever do in C++.

--

Moving on from that, the current 'stack' we have inside the engine for
graphics is as follows:

Skia (entirely internal - not exposed at any level)
   => This is the 'rasterization' engine - it essentially converts 'paint
this shape here' requests into actual pixels). It is a rather large and
fiddly C++ class library which we have, over time, managed to persuade
to work in the ways that we need it to.

LibGraphics (internal engine API - available for use by the engine)
   => This is a high-level, standard, PostScript-like C API allowing
paths to be stroked and filled with various kinds of paints,
transparency layers to be used and composited with bitmap effects,
images to be rendered etc. It is very similar to CoreGraphics (but
actually has a number of features beyond which CG offers). e.g.
      MCGContextCreate(-> myContext)
      MCGContextSetRGBAFillColor(myContext, 1, 0, 0, 0.5)
      MCGContextAddRectangle(myContext, [0, 0, 400, 400])
      MCGContextFill(myContext)

Above this we actually have two abstractions which sit side-by-side:

MCGraphicsContext (internal engine compatibility class - available for
use by the 'classic' engine controls)
   => This is a wrapper around LibGraphics which emulates the old
graphics abstraction in the engine and is used by all existing engine
controls.

Canvas (LCB syntax extension - available for use by LCB)
   => This is a thin wrapper around LibGraphics providing 'nice' syntax
to LCB to allow widgets to paint themselves:
     set the fill paint of this canvas to color [1, 0, 0, 0.5]
     fill rectangle [0, 0, 400, 400] on this canvas

So - all the existing ('classic') engine controls internally use an old
abstraction called MCGraphicsContext, whilst all new 'engine' controls
use Canvas (if written in LCB) or LibGraphics directly (if written in
C++ - however, we do not intend to write any new engine controls in C++
as we have LCB - it would be a somewhat large 'waste of effort').

--

With the above in mind let's look at what SVG support actually entails.
Firstly, SVG is 'just' an interchange format (although a very powerful
and really quite complex one if implemented fully) - it is a high-level
description of marks on a page. It is similar to the representational
power of PostScript (Level 3 - which includes transparency) but is
declarative (i.e. you describe explicitly what the elements are) rather
than imperative (i.e. you run 'code' to generate the elements -
PostScript is a language). SVG is actually (like all W3C standards)
abstract - it is a well-defined data-structure which has a reference
'encoding' as XML. So an SVG rendering 'stack' notionally looks like
this:
     XML Importer - takes SVG XML and converts it to an XML document that
can be manipulated)
     SVG-XML Processor - processes the XML document and produces the SVG
data structure)
     SVG Renderer - takes the SVG data structure and turns it into actual
graphics operations)
     Graphics Library - needs to provide the operations needed to render
SVG primitives

'Unfortunately', Skia does not support SVG rendering directly - it was
going to once it seems, however that aspect was abandoned long ago as
not being worthwhile. I'm guessing this is because full support of SVG
is far outside the realms of a (low-level) graphics (rasterization /
abstraction) library. Instead Skia provides the underlying services for
rasterizing SVG (e.g. the ability to render paths with arbitrary
transforms with various different kinds of paint, process things with
various kinds of filter etc.).

Now, obviously we only use Skia at a very low-level - it is strictly
'hidden' behind our well-defined LibGraphics API (so that, if necessary,
we can change the rasterization engine at some point, or abstract it to
do various other 'neat' things - like 'export snapshot as SVG'). So, the
first part of the work I've done is to add an MCGSvgRef abstraction to
libgraphics. This neatly wraps up the top three things in the above list
- it loads and parses an SVG XML document and then converts it to an
internal form which can be rendered (note that the entire focus here is
rendering - not editing or introspection on the SVG Document). There is
then a simple call to render such a thing (which basically iterates over
the internal form and calls appropriate LibGraphics APIs to do so). (I
should point out that I didn't write the main piece of code which does
the Importing / Processing - that would be
https://github.com/memononen/nanosvg - I wrapped that up in a nice
package and hooked it up to LibGraphics). The C API is actually this
(for those that are interested):

bool MCGSvgCreate(const void *p_data, size_t p_data_size, MCGSvgRef&
r_svg)
MCGSvgRef MCGSvgRetain(MCGSvgRef self)
void MCGSvgRelease(MCGSvgRef self)
bool MCGSvgIsValid(MCGSvgRef self)
MCGRectangle MCGSvgGetViewBox(MCGSvgRef self)
MCGRectangle MCGSvgGetBoundingBox(MCGSvgRef self)
void MCGSvgRender(MCGSvgRef self, MCGContextRef target)

With this nice simple abstraction in place (which is now generally
available as part of the API exposed by LibGraphics to anything in the
engine that might want to use it), I then wrapped it in LCB syntax for
use by widgets. Indeed, it did not need very much syntax:

svg from file <filename>
svg from resource file <filename>
svg from string <xmlstring>
the bounding box of <svg object>
the viewing box of <svg object>
draw [ from <srcRect> of ] <svg object> into <dstRect> of <canvas>

So, at this point, any part of the engine can use the C-based API
mentioned above, and any LCB code can use the 'nice' LCB syntax above.

--

The final piece to the current piece of work is a very simple (it is
around 150 lines of LCB code, including GPL header comments) 'SVG View'
widget which allows you to give it SVG as an XML string, and then tell
it what portion to render into the widgets rect. (Here is the actual
source -
https://github.com/runrevmark/livecode/blob/lcb-canvas_svg/extensions/widgets/svgview/svgview.lcb)

--

Now with that all out of the way, let me see if I can answer your direct
questions...

Q: does it make sense to have two "realms" of graphics? There are card
based (native) graphics, and then there are the graphics inside widgets.
A: There aren't 'two realms of graphics' - what you are seeing is the
graphics 'stack' at different levels. By 'card based graphics' I presume
you mean the 'graphic' object. This is a 'widget' which allows you to
display geometric shapes on a card. It sits on MCGraphicsContext
internally which sits on LibGraphics. Similarly, any widget sits on
Canvas syntax which sits on LibGraphics. Due to the graphics object
current implementation atop MCGraphicsContext it has a number of flaws
which are not fixable without (essentially) rewriting it...

Q: I recall reading that all of the graphics rendering in LC was going
to be moved over to the skia graphics library. Is this what enables the
display of SVG in widgets or is graphics rendering in widgets based on
something else?
A: All graphics rendering in LC has been using Skia since around 6.5.
Existing C++ engine controls do so through the MCGraphicsContext wrapper
around LibGraphics (which actually sits on Skia). SVG rendering support
has been added at the LibGraphics level (using a third-party SVG parser
/ processor), which has then been exposed to the LCB Canvas syntax for
widgets to use.

Q: What prevents the display of SVG graphics outside of a widget?
A: Nothing - the SVG support is available at the LibGraphics level and
so any part of the (C++) engine could use it. Really this question
exposes a slight misunderstanding about widgets. Widgets are no
different from the other engine controls - they are just written in LCB
rather than C++ which means they are a great deal easier and faster to
write *and* most importantly, a great many more people will be able to
write them. (Thus providing, over time, a great many more 'engine'
features for everybody).

Q: As it stands, there are graphics capabilities within widgets that
don't apply to native graphics. Would it not make more sense to have a
single universal approach to all graphics in LC?
A: Internally and from an implementation perspective (whether it be
available at the C++ or LCB level) there is a universal approach to
graphics in LiveCode. However, I think what you are asking here is 'why
does there appear to be more graphics facilities available at the Canvas
API level than we can see through the current graphic object'... The
answer here is simple - because we have not yet rewritten the graphic
object. The current behavior of the graphic object is such that trying
to 'move it forward' into the modern era is, essentially, pointless - it
would have to be done with a big hefty flag saying 'use new behavior'
(as otherwise all existing stacks using it would not work the same as
they did before), and that is equivalent to just rewriting the object
from scratch. This is the much prophesized 'shape' object. Which we will
write in LCB (and, indeed, will actually just be quite a simple
'wrapper' around the Canvas syntax in the first instance at least).

Warmest Regards,

Mark.


--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Vector images?

Mark Waddingham-2
In reply to this post by Richmond Mathewson-2
On 2015-10-21 10:54, Richmond wrote:
> I am not confusing anything: I know you can manage "the underlying
> ability to import and render SVG",
> and I am hoping you will expose that to the end-user via the menu for
> image import that is already in place in the GUI.

Indeed - I can definitely say we will do that... We just need to figure
out the best approach internally for that to be done :)

> Well, vector images are very widely used, and they do have the
> advantage over bitmapped ones in that they don't go "all fuzzy"
> when they are resized: that, at the very least, is a big plus, and IF
> (??????) the Geometry Manager is 'whatever' vector images
> would sit very nicely with that.

True - but there are dragons here. One might ask the question why Apple
(with all its power, money and technical ability) requires App writers
to make several images at different resolutions in order to make sure
things 'dont go fuzzy' on Retina and other high resolution displays.
They certainly have the where-with-all to implement an SVG rendering
library - like they have done with PDF - available to
C/C++/Objective-C/Swift - and yet they have not.

The only reasonable answer I can come up with (beyond general
intransigence of a behemoth) is that SVG is expensive (time wise) to
render. Far more expensive than scaling and rendering a pre-computed
image.

Now for situations where you are always scaling / transforming and
manipulating your content then this consideration probably largely goes
away (although be prepared for complex SVG not to animate particularly
well on lower end hardware). However, for the most common situation of
icons the balance still probably largely falls towards pre-rendered
images being better.

Ultimately, I'm definitely in the 'simplify things for the app writer'
by way of - let's not make them have to fiddle with PhotoShop or other
tools to generate the icons to make things look nice for the simple
reason that the ability to easily render and snapshot SVG in LiveCode
will mean that an easy script-based solution could always be come up
with to solve any performance issues, at least until such a point the
engine or standalone builder becomes 'clever' enough to do it for you.

>> LiveCode is good at processing text, so certainly export of SVG is
>> something which can be done quite happily, and well (and indeed quite
>> sensibly) in script. Indeed, there is even an SVG importer which has
>> been around for a long time (although it is slightly limited by some
>> restrictions on the LiveCode graphic object) also written in script.
>
> Alejandro . . .

Indeed - that library was the one which was on my mind. Actually, the
first task I set Ian (one of our engineers) to do when he first joined
was to first write something which converted a simple language I had
designed ('SVGL') into vector graphic objects; and then write an SVG ->
SVGL converter. (My ideas for the much prophesized 'shape' object go way
way back). The reason for this was that his first task after getting to
grips with these ideas was implementing gradient fills in the graphic
object - back when there was no existing third-party library we could
leverage to do so (due to commercial licensing requirements).

>> Similarly, an 'export snapshot ... as svg' command would also be
>> useful to solve specific problems for specific domains but, again,
>> isn't going to do so for everyone.
>
> Well, we all know what attempting to keep everybody happy at the same
> time results in: something that makes most people fed up.

True - balancing acts are always prone to the occasional 'wobble'.

> I still feel that Vector graphibs should be automatically "in the
> list": SuperCard seems to cope with them, and has for quite some time.

It always has been really - but there are various technical challenges
involved with it.

I suspect SuperCards 'vector graphics' support is Mac PICTs or similar
(I could be wrong). Given that SuperCard is single-platform, they have
the luxury of being able to use whatever their target platform (Mac)
supports. We, unfortunately, do not have the same amount of flexibility.

> But they are as entitled to bang-on about what they would like just as
> much as I am entitled to bang on about graphics.

I can't argue with that :)

> If they don't that is not my fault, and possibly their loss.
>
> As my grandfather said; "There is never any harm in asking."

Indeed, that is a very good motto to have; and my grandfather always
used to say "Patience is a virtue" :)

> But, unless one wants to go and live on one's own with a fat bank
> account to takes of one's needs (I wish !!!!), one has to do all that
> juggling to
> keep as many people happy as possible without putting other people's
> noses out of joint.

Haha - yes - quite.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Vector images?

Richmond Mathewson-2
On 21/10/15 12:48, Mark Waddingham wrote:

> <snip>
>
>> Well, vector images are very widely used, and they do have the
>> advantage over bitmapped ones in that they don't go "all fuzzy"
>> when they are resized: that, at the very least, is a big plus, and IF
>> (??????) the Geometry Manager is 'whatever' vector images
>> would sit very nicely with that.
>
> True - but there are dragons here. One might ask the question why
> Apple (with all its power, money and technical ability) requires App
> writers to make several images at different resolutions in order to
> make sure things 'dont go fuzzy' on Retina and other high resolution
> displays. They certainly have the where-with-all to implement an SVG
> rendering library - like they have done with PDF - available to
> C/C++/Objective-C/Swift - and yet they have not.
>
> The only reasonable answer I can come up with (beyond general
> intransigence of a behemoth) is that SVG is expensive (time wise) to
> render. Far more expensive than scaling and rendering a pre-computed
> image.
>
<snip>

Of course, you could think about using a different vector image format . . .

I know that SVG "is" the vector graphics standard, but that hasn't
stopped any one adopting
other formats that are, possibly, less complex.

At the risk of sounding totally cretinous (not that that would be for
the first time), both Illustrator and Inkscape
can export EPS files; and if they can do that on Macintosh, Windows and
Linux . . .

Just possibly, as Inkscape is Open Source . . .

Richmond.

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12