Signature Widget Resize Scale

[stam]

Bernd's sample stack contains the xml header from the Affinity app; it works well.
I tried to skinny down that xml and came up with this minimal header:

Code: Select all

<?xml version="1.0"?>
<svg viewBox="0 0 280 91">

Taking out either the xml version or the svg viewBox causes the conversion to fail.

Stellar sleuthing Bob!

The lesson that describes this is clearly missing the <svg viewbox="0 0 width height"> statement... seems likely the lesson needs updating/clarifying (although in actual fact it doesn't actually go into drawingSVGCompile, just how you would export the path data - it's just that you can't use said data without this!).

Do we think this is normal behaviour and any xml path passed to drawingSVGCompile should necessarily contain these 2 statements?
If that's the case then at the very least documentation on drawingSVGCompile should be updated to reflect this, to help prevent headaches...

Or would it be worth a bug report/enhancement request for drawingSVGCompile?
The 1st statement is fixed/standard text and the handler could just prepend this to the svg xml path, the second just needs width/height, which could be passed as parameters to drawingSVGCompile?

S.

[bn]

I think it is not really the fault of the drawing library. It expects a reasonable header including "viewbox". Even affinity defaulted to a size of 1200 x 1200 because of the missing "viewBox". And that would not really be an option for the drawing library.
The sloppy lesson needs updating.

Though the drawing library could catch the missing viewbox and exit more gracefully.

Kind regards
Bernd

[bn]

For what it is worth:

I thought that getting a scalable image from the Signature widget is nice. But maybe there is a need to cut the surrounding empty space of the signature since not all signatures take the whole of the widget space. It would be easier to handle.

without adjustment:

with adjustment

SignatureImageAdjusted.png (21.83 KiB) Viewed 1549 times

So I expanded the stack to provide an option to adjust the image to the bounds of non-transparent pixel via a checkbox.

The stack uses an intermediary snaphshot to track the alphadata of that snapshot for the bounds of non transparent pixel.

Also I used merge to a slightly modified simple SVG header including "svg width height" because these are useful to scale the image.
Merge is a command that fits this scenario perfectly

Code: Select all

<?xml version="1.0"?>
<svg width="[[tWidth]]" height="[[tHeight]]" viewBox="[[tLeft]] [[tTop]] [[tRight]] [[tBot]]">

Due to limitations of the treeviw widget that stack is hard to debug. LC hangs when the debugger is trying to display non-printing characters like numToByte(0) which is what the alphaData uses to mark transparent pixel.

https://quality.livecode.com/show_bug.cgi?id=19157
https://github.com/livecode/livecode/pull/7125

I had to hack my version of treeview to debug the stack. (I added the above patch and recompiled treeview)

If anyone finds this version of convertSignature useful I would like to hear it...

Kind regards
Bernd


.

[bobcole]

The title of this thread and the original posting refer to "Resize Scale."
With that in mind, I explored creating a double size signature from the original.
The stack below doubles the size of the original signature in a separate signature widget.

Each of the points in the original signature's pathData is multiplied by a 2.0 scale factor creating a revised pathData.
There are Lines (L) and Curves (C) in the original pathData. Each has a starting point. Lines have one ending point (of course) but Curves have three more points after the starting point. All of these must be multiplied by the scale factor (2.0).

The larger Signature Widget's pathData is set to the revised pathData.
It appears to work. Perhaps this could be the foundation of a resize script.
FYI,
Bob

SignatureDoubled.livecode.zip

(44.66 KiB) Downloaded 58 times