LiveCode Forums

Peter,
I looked at
http://quality.livecode.com/show_bug.cgi?id=19013
and downloaded the .lcb file from there.
Maybe you could post the .lcb file here for a broader audience.

Thanks for your widget again.

Kind regards

Bernd

Peter,

sorry, I did download your -lcb file from QCC. But I thought it was your tweaked widget script.

So yes, I would appreciate you posting the .lcb file.

Thank you.

Bernd

Below is a tweaked version of the color widget lcb file which seems to run ok under LC 9 dp 4.

There is a somewhat obscure and intermittent bug when using the color picker to change one or other of the path color properties ... a bug report has been filed.

For simply displaying and resizing color widgets however it should work fine. If you install the widget then standard documentation will appear in the dictionary API.

Peter,

thank you very much for posting your widget .lcb file. It is very instructive. Especially the parsing part.

Kind regard
Bernd

(too bad, we did not have more time in Edinburgh at the dinner, the rules for the dinner demanded switching places)

Thanks Bernd the encouragement is appreciated. I have tended to consider myself as a rudimentary Livecoder, but maybe now I have graduated to intermediate class Still plenty to learn!

If we both make it to the next conference then let's aim to take more time to chat over dinner.

Peter et al...

The expected path format is more flexible than you're allowing for.
I made a few changes to allow for some other formats such as

flexible attribute ordering : (style doesn't have to immediately follow path)
hex color assignments : <path ... fill="#1122FF;"></path>

The attached archive has a sample color svg image extracted from my plexmediaserver installation.

... and it shows up nicely in PowerTools' widgets panel.

mwieder wrote:Peter et al...

The expected path format is more flexible than you're allowing for.
I made a few changes to allow for some other formats such as

flexible attribute ordering : (style doesn't have to immediately follow path)
hex color assignments : <path ... fill="#1122FF;"></path>

The attached archive has a sample color svg image extracted from my plexmediaserver installation.

GREAT WORK!!!! It works great on my Linux machine!! Already reviewed on my blog: http://livecodeitalia.blogspot.it/2017/ ... olori.html

Thanks - yes, I can't verify that it works on any other OS, but it's solid on my linux system as well.

And regarding your blog... I didn't create this stack, I just patched Peter's excellent groundwork to allow for more svg path formats generated by other software applications.

Mark, Maximo

Could you share the compiled Widget (complete folder
compressed) using Google Drive or Dropbox?
I could not compiled it in my own setup...

Al

Hmmm... that's a bit distressing. Here's a link to the widget folder in my Dropbox account:

https://www.dropbox.com/sh/elho29amslt7 ... oM8Ma?dl=0

Hi Mark!

Version 8 of this widget works great. I just have to copy these files to a folder
in the extensions directory of LC 8.1.3 and LC IDE recognizes and show this
new widget.

Many, Many Thanks again!

Now, I will return to Ian's SVGL to continue working in the problem
of flattening transforms of svg files...

http://stackoverflow.com/questions/1332 ... -svg-files

Hey Mark

Many thanks for the enhancements and improved flexibility in the parsing routine. While I remain hopeful that full color SVG handling will eventually find its way into the engine directly, its great that you have extended the colour SVG widget code to serve a wider range of users. Much appreciated!

Peter-

My thanks for laying the groundwork for this. I don't know whether you saw Alejandro's post in the use-list, but he made the request for a writeup for the livecode blog on the process. He made the request particularly for me to document what I did, but basically I just made a few patches to your code. I think it would be much more instructive for you to write up your learning and development process, especially for developers trying to come to grips with the new LCB environment: I for one would love to read a blog about how you figured out what needed to be done, how you went about bringing it to fruition, and what the development/debugging process was like.

Thanks PeterT and MarkW for venturing into SVG land! I am able to follow most of what is being done and am also still hopeful
that the original promise of SVG ( the normal full version) will make it into one of the next DP's.

When I originally started working with Ian's import-stack years ago and abandoned it because of irregular scaling of grouped objects
( back and forth) and not really what I wanted, I was happy and grateful to find examples from Trevor and that things were moving forward with
PeterT's files and the amendments that MarkW made.

I do wonder if there is a specific reason that the SVG I get from Illustrator (6) from my graphic
designers are in a different code-format than the ones used in the widget? We tried almost all the options in the black dialog
box that allows one to preview the SVG code but to no avail. ( Preview of those files in a browser works perfectly)
I have started writing a translation stack but there are so many deviations that I wonder if I'm just getting the "wrong kind" of SVG, if such a thing exists.

Here's an example of (part of) an AI SVG from one of my designers :

<path fill="none" stroke="#DBC3A8" stroke-width="4" stroke-linecap="round" stroke-linejoin="round" stroke-miterlimit="10" d="
M31.156,76.394c-0.479,2.518-2.797,7.718-6.375,7.547c-0.244,5.259,7.568,2.549,10.08,1.774c1.063,1.477,0.955,1.093,0.906,2.969
c-0.093,3.741-5.05,11.786-8.158,14.011c3.598,1.155,6.818,0.793,10.057-0.779c1.556-0.754,2.429,3.63,3.371,1.989
c0.67-1.172,0.965-2.669,1.851-3.025c2.006-0.806,1.741,1.575,0.971,3.815c-0.299,0.87-3.935-0.169-3.496,0.666
c0.889,1.687,12.732-2.656,14.602-2.563c2.4,0.121,5.234-1.138,7.421-1.971c3.583-1.363,11.54-3.976,13.062-8.023
c1.981-5.271-3.353-14.267-6.363-18.199c-5.783-7.551-12.35-13.914-20.309-19.21c-5.474-3.642-9.123-5.121-14.863-3.011
c-3.238,1.19-7.317,0.709-8.387,4.311c-0.599,2.024,1.123,6.136,1.334,8.167c0.33,3.208-0.816,5.175,2.334,7.333
C30.808,73.302,31.547,74.338,31.156,76.394z"/>

And here's (part of) the default color SVG from PeterT :

<path d="M45.241,55.471C43.938,55.493 39.789,55.203 35.927,54.14C31.413,52.898 25.806,52.903 21.29,54.14C17.398,55.206
13.769,55.494 11.976,55.471C5.142,55.383 0,48.52 0,41.499C0,33.815 6.287,27.527 13.972,27.527L43.246,27.527C50.93,27.528
57,33.815 57,41.499C57,48.52 52.075,55.355 45.241,55.471Z" style="fill:rgb(203,212,216);fill-rule:nonzero;"/>

Styles are relegated to the end here and notation is quite different from what Illustrator spits out via the "View code" window. Values are treated
differently ( the one between quotes, the other not) items separated by quoting vs. separated by ;

So parsing (my massive amount) of SVG files becomes practically impossible until I figure out why the svg-code differs so extensively. Needless to say
that the original complete SVG is at least 50 times that bit up above with all kinds of neat graphic tricks and paths.
Is this generally speaking a weak point of SVG? Like mentioned above :I started work on an offset/find/replace script that parses and tried to get it to work
with the existing color widget but there are too many exceptions and loose ends ( strokes not showing, miters and line-joins not showing etc)

That is why of course the scope of my question runs a bit deeper and I do apologise if this has been brought up, chewed through and solved somewhere I did not look :

What version of SVG code and notation is the SVG widget or built-in SVG object in LiveCode going to adopt? Will it be able to handle
different notations like above? If not will there be a strict parsing scheme for which I can write a translator?

It would be a rather frustrating business to start a massive translation-job only to find out that the end result will not work with the
RunRev Team's solution. That sort of also answers the obvious question : Why don't I just work on the parser in the existing widget from PeterT
( and the adopted parser from MarkW).
Exactly for the same reason : Will it "hold" ?

Mark? Ian?

warmest regards and thanks from sunny Berlin

Frans