LiveCode Forums.

Hi Al,

tested successfully with several SVGs from Wikipedia (especially world maps and several map projections).
Great and nifty work, a lot of thanks (to you and LC's Ian Macphail for the base-SVGL from livecodeshare).
This library will be especially useful for the "HTML5-branch" of LC.

hh

p.s. The "answer file" is broken, at least buggy in LC 8. Simply remove the "with filter"-part.

[Edit: Corrected "(at least buggy in LC 8" & ")" to ", at least buggy in LC 8." in order to avoid the smiley "LC " made by phpBB. Klaus, this is really nasty ...]

Ian MacPhail's stack looks, superficially, similar to Alejandro's: however, once one
opens an SVG file one can see the difference:
The one on the left is from Ian's stack, that on the right from Alejandro's.

If one does a compare-and-contrast exercise with their button scripts one can really appreciate the
work that Alejandro has done:

Richmond, you are right.
Yes, of course, I saw a lot of enhancements by Al and I appreciate these. I'm only a few years with LC and found in old 'collections' very valuable stuff, also from Al. My note is just an appraisal of the basic work of LC-Ian from 2009(!), I used for the SVG-path to LC-polygons part. It doesn't qualify Al's work as less valuable (was at least not at all intended to do that).

Alejandro, I find you could post your work, that is from my point of view already far beyond "alpha", in the more visible Community projects subforum.

Thanks again, count me to your 'followers'. If I'll get a problem with your library that I can locate, I'll tell you.

Hermann

Hi All,

Many Thanks for your kind words, but remember that
this is just an updated version of Ian McPhail's stack
SVGL: http://livecodeshare.runrev.com/stack/112/SVGL

As explained by Mark Waddingham:
"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."
http://lists.runrev.com/pipermail/use-l ... 20199.html

In another message thread, Mark Waddingham explained really well
the issues around importing and displaying SVG:
http://lists.runrev.com/pipermail/use-l ... 20198.html

Please, notice the following: Livecode vector graphics only use integer
(1,2,3,4,5...) for displaying graphics strokes (borders). This limitation
could be a barrier to import and display faithfully many professional
illustrations created or exported to SVG format.

A better option for LC8 developers is using the widget architecture that could
render an exact display of imported SVG... but for all LC7 users and
developers SVGL still is our best choice.

Attached to this message is a small update of SVGL (Not SVGL + Gradients).
Please test this updated version of SVGL, first importing all 3 included svg
in folder and then with any other svg that you download from OpenClipart.org

Again, many thanks for keeping alive your interest in this topic!
Have a nice day!

Alejandro

Hi Alejandro.

Al wrote:Please, notice the following: Livecode vector graphics only use integer
(1,2,3,4,5...) for displaying graphics strokes (borders). This limitation
could be a barrier to import and display faithfully many professional
illustrations created or exported to SVG format.

How do you mean that?

Floating points of a graphic could be stored (as the 'model') in a property of the graphic, so that for following computations these (floating) "truePoints" can be used, and then let the engine round again, at least and last the GPU will do that. This could avoid to fortify the rounding error of the current display.

Otherwise I would be glad to know how to divide the pixels on my screen

Hermann

Keep on with your good work!

Hi Hermann,
Many Thanks for your kind words!

Floating points of a graphic could be stored (as the 'model') in a property of the graphic,
so that for following computations these (floating) "truePoints" can be used, and then let the
engine round again, at least and last the GPU will do that. This could avoid to fortify the rounding
error of the current display. Otherwise I would be glad to know how to divide the pixels on my screen
Keep on with your good work!

Yes, this is the method that I used in the stack "penTool".
Maybe the name that I choose was "realPoints" for storing
floating point values in a custom property of the graphic
and "screenPoints" for another custom property used
to store coordinates to set the points of the graphic.

Hopefully, after SVGL + Gradients is completed, vector graphics with gradients
and transparency will be more widely used as Interface elements, backgrounds
and interactive graphics reducing the bulk of bitmaps needed today to display
a professional looking appearance in our stacks.

Alejandro

Buenos dias Alejandro,

I remember the stack but not it's scripts.
But I remember especially, that you even realized the editing of "paths". This is so good that you could also make standalones out of this!? [For HTML5 wait a while, it's currently for such complicated stacks not easy to find out what is needed and not (yet) implemented. But they have it already at a fairly good status.]

I now found the link to your stacks in an old post, let me cite it here again.

Which version of penTool is the most applicable to our discussion?
Isn't some of this work joinable with your current work? There are so much useful functions and routines. If you need assistance for the "mini-porting" to LC, then I could try to help you.

Al wrote:Hi Herman,
After Yahoo closed Geocities, Andre Garzia and Richard Gaskin kindly offered space to host my stack:

http://andregarzia.on-rev.com/alejandro/stacks/
http://at.livecodejournal.com/stacks/

If you are going to test these stacks, please use them in complete isolation (that is, no other stack open). Many of these stacks worked in MetaCard and Revolution, but have not been updated for LiveCode.

Be prepared for a massive dosage of spaghetti code!!!!

Hermann

Hi Hermann

Sorry for answering many days after your message,
but it is now, sunday, that I feel better after been
with headaches, body aches and fever for many
days.

But I remember especially, that you even realized the editing of "paths". This is so good that you could also make standalones out of this!? [For HTML5 wait a while, it's currently for such complicated stacks not easy to find out what is needed and not (yet) implemented. But they have it already at a fairly good status.]

Which version of penTool is the most applicable to our discussion?
Isn't some of this work joinable with your current work? There are so much useful functions and routines. If you need assistance for the "mini-porting" to LC, then I could try to help you.

This would be great! Many, Many Thanks.
Actually, I recommend to use the code of this stack as starting point:
http://andregarzia.on-rev.com/alejandro ... pt_v02.zip

There are many enhancement and options that I would like to test.
Hopefully, these would be useful for all developers in this platform.

Alejandro

Alejandro,
you are kind of "Mr. Understatement". To say it with (or not with) Bob S. and Richmond M.: This stack blows up one's kilt.

It is already on such a high level, compact and tough, now don't overload it. Make a list of 'basic' additions first and then realize it 'first things first'. Take the lead, there are already some places where I could come in (smoothing, split/combine subpaths).

I'll come back as soon as I finished reading your scripts (and detailed comments, thanks).

Hermann

Hi Hermann,

After working for many hours in the stack penTool,
I had come to the realization that LiveCode
DOES NOT need a full fleged vector graphics editor
within the IDE. In fact, I suspect that such inclusion
would be detrimental to the whole LiveCode stacks
creation experience.

Notice that Livecode IDE does not offers an
Image Editor, although images are used in
almost every stack. Livecode IDE does not
includes either an Audio or Video Editor...
Ideally, vector graphics should get the
same options to edit them in an external
editor and read back into LC, just as images,
audio and video.

What kind of basic functions should offer
LC to work with vector graphics?

A good method could be to import svg files as an image object with
transparent background similar to a PNG image.

Import svg within rect (0,0,400,500)
Import svg at 25% scale
SVGRotate clockwise 35 svg
SVGScale 250 svg
SVGFlipH svg
SVGFlipV svg
SVGSkew 15 svg
Export svgCode to file...
Put svgCode of svg into...
Get the svgCode of svg ...
Set the svgCode of svg to...

Just some ideas that needs more careful and detailed
consideration to discuss possible pitfalls or drawbacks
in their implementation.

Alejandro

Hi Alejandro,

I think that is what they call a widget in LC8

some of what you propose is in

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

Have a look. That is not the full SVG specifications, but a good start. And from what I hear it should appear before 8.0 goes final.

Kind regards
Bernd

Hi Bern,

bn wrote: I think that is what they call a widget in LC8
some of what you propose is in
https://github.com/livecode/livecode/pull/3089
Have a look. That is not the full SVG specifications, but a good start.
And from what I hear it should appear before 8.0 goes final.

Many Thanks for posting this link, Bernd.
This is an essential page to bookmark
and visit before bringing this topic to
the forums or mail list.

I would recommed that LC target SVG Tiny 1.1
specification to import svg in every platform:
http://www.w3.org/TR/SVGMobile/

Alejandro

I'm not sure why, but I seem unable to import an SVG file generated by Karbon [ https://www.calligra.org/karbon/ ].

unsupported attribute: stroke-linejoin: miter
unsupported attribute: stroke-miterlimit: 2.00000000000
unsupported attribute: fill-rule: evenodd
unsupported attribute: stroke-linecap: square


Here is my file:

All "primitives" provided with the Open Source package 'Dia' [ https://wiki.gnome.org/Apps/Dia/ ]
can be exported from within Dia (the program comes with all the shapes stored
in a strange .shape format) and easily imported using Alejandro's stack.

AND the BIG question is how LiveCode think we are going to import
vector images with this: