[Cuis-dev] Icons with path sequence in vector graphics

[Luciano Notarfrancesco]

Hi Juan,
Thanks for the detailed explanation of the rationale behind your design. I
was considering using TTF icons, but then I thought it was going to be
annoying to have to work with arbitrary code points instead of the actual
fonts, or would require a global mapping name -> icon/codePoint that I also
didn't like much, so I followed your suggestion of doing this instead of
TTF fonts and now I see it's much cleaner and simpler.

I'm still not sure, but at this point I feel that we don't really need the
reified PathCommands (or perhaps they just belong to the SVG package), I'd
prefer to use literal Float32Arrays directly if we added support for the
rest of the commands. BTW, regarding #[], I'd like to suggest to change it
to create Float32Arrays instead of Float64Arrays... apparently all the
current use cases end up converting them to Float32Array anyway, and for
that they use two syntactic suggars: #[] and the backtick, it would be
simpler if #[] produced Float32Arrays instead...

Here's an example of an IconMorph, not necessarily the best implementation
but it shows the idea, you can test it like this:
    IconMorph new pathData: 'M240-200h120v-240h240v240h120v-360L480-740
240-560v360Zm-80 80v-480l320-240 320 240v480H520v-240h-80v240H160Zm320-350Z'

Cheers,
Luciano


On Wed, Jun 24, 2026 at 8:57 PM Juan Vuletich <juan at cuis.st> wrote:

> Hi Luciano,
> On 2026-06-24 9:12 AM, Luciano Notarfrancesco via Cuis-dev wrote:
>
> Got it, in a few lines of code I can fully convert path data in that
> compact standard format to a list of PathCommands, and then I can just
> compose with a transformation for a given height and position and draw it.
> Works great!
>
> Good. Glad it works ok.
>
> Juan, perhaps we should extend VectorEngine>>pathSequence: to support all
> commands? Or your idea is to convert other commands to this reduced subset
> (like converting arcs to a list of bezier curves I guess, etc)?
>
> Let me tell a bit about my thoughts when originally writing this stuff.
>
> There's the choice between reifying the path elements vs just making them
> calls. PathCommand is a reification of the canvas API. I wasn't sure
> whether it would be the preferred way.
>
> Then, for things like #drawHandLarge I preferred to find a more performant
> and memory efficient way to do it, even if less elegant. Remember we're
> coming from BitBlt, where everything is very compact and super fast. So I
> did #pathSequence:, packing everything in a (preferably literal)
> FloatArray. But Arcs, like in
> #arcCenterX:centerY:radiusX:radiusY:start:sweep:rotationCos:rotationSin:
> need trigonometry, that is slower than basic arithmetic, so I left it out.
> You can see in the comment at #pathSequence: that I was worried about
> performance of trigonometric functions. I guess the cost of trigonometry is
> dwarfed by the cost of the actual rendering. Maybe we should add them after
> all.
>
> See #drawHandLarge. I found it rather easy to write the FloatArrays
> manually. It is not really different from the SVG way. Still, I understand
> that the icons font shows that we do need to support the SVG way, and not
> just manually writing the FloatArrays. But backtick compile time
> expressions may be used to turn the SVG like commands into literal
> FloatArrays for performance. We get convenience and performance. If you do
> this:
>
> - You'd leave out the geometry transformation of the literal FloatArray,
> and apply it on each call (usually by giving each transformation its own
> morph to hold it, or we could extend the canvas api if needed). This is of
> course to build a single literal FloatArray for each widget.
>
> - I guess this could be done with little code taking advantage of
> SVGPath>>#buildFromXml:defs: in the SVG package. But it would make this
> code dependent on SVG. This also shows there are repeated ideas between
> PathCommand and SVGPath. Some consolidation could be in order... Food for
> thought.
>
> So, the choice is between your likely clean and nice code for turning the
> SVG like spec into PathCommands, and a more complicated but potentially
> more performance use of #pathSequence:. #pathSequence: may be worth it if
> there is a large number of icons, and many are displayed at once.
>
> Still, turning them into #pathSequence: FloatArrays at compile time is
> worth doing.
>
> In any case, your code for this will be useful in many other scenarios.
> Please consider making it a separate package, part of SVG, or part of the
> base Cuis image!
>
> Please keep the discussion going. This could lead to better code in base
> Cuis and/or packages, not just your great app.
>
> Thanks,
>
> On Wed, Jun 24, 2026 at 2:27 PM Luciano Notarfrancesco <luchiano at gmail.com>
> wrote:
>
>> I've been making my own buttons, knobs, pulldown lists, etc... all sorts
>> of widgets. Some of them draw text, like the label on a button, and I'd
>> like to add optional monochromatic icons. For the sake of simplicity, I'd
>> like to just set the icon as path data, something like this:
>>     M784-120 532-372q-30 24-69 38t-83 14q-109 0-184.5-75.5T120-580q0-109
>> 75.5-184.5T380-840q109 0 184.5 75.5T640-580q0 44-14 83t-38 69l252 252-56
>> 56ZM380-400q75 0 127.5-52.5T560-580q0-75-52.5-127.5T380-760q-75 0-127.5
>> 52.5T200-580q0 75 52.5 127.5T380-400Z
>>
>> I got this from https://fonts.google.com/icons , there you can search
>> the icons you like and click on the image of the icon to copy this path
>> data to the clipboard.
>>
>> Then, say it is the icon for a button, the button morph can draw it
>> scaled depending on the morph height, or on the line spacing of the font
>> used for the label. Seems the simplest solution to me, and it would be just
>> one or two lines of path data when creating the button.
>>
>> My question is, how do I represent this in Cuis? There is PathCommand and
>> subclasses, but it's not used anywhere in the base image or packages, I
>> didn't find any examples. There's also VectorCanvas>>pathSequence: in a
>> different format, more limited (only supports commands M L C Q, I think).
>>
>> What's the correct path for this? What do you suggest?
>>
>> Thanks,
>> Luciano
>>
>>
> --
> Juan Vuletichwww.cuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletich
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260625/97313311/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IconMorph.st
Type: application/octet-stream
Size: 2584 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260625/97313311/attachment-0001.obj>