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

[Bernhard Pieber]

Hi Juan, Hi Luciano,

This is great! Many icons work well.

What's most amazing: The Ink Marker even works when I move it! ;-)

(IconMorph new pathData: 'm272-104-38-38-42 42q-19 19-46.5 19.5T100-100q-19-19-19-46t19-46l42-42-38-40 554-554q12-12 29-12t29 12l112 112q12 12 12 29t-12 29L272-104Zm172-396L216-274l58 58 226-228-56-56Z') openInWorld

I guess the drawing artifacts have nothing to do with the pathData parsing, right?

The class category of IconMorph is named Widgetst. I guess this is a typo.

Thanks für working on this!

Cheers,
Bernhard

> Am 25.06.2026 um 17:00 schrieb Juan Vuletich via Cuis-dev :
>
> Hi Luciano,
>
> On 2026-06-25 5:16 AM, Luciano Notarfrancesco via Cuis-dev wrote:
>> 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.
>
> Most important to me, using TTF forces you to use text metrics
> arguments, when you're actually doing graphics and text metrics are
> maningless here.
>
>>
>> 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.
>
> Yes. We need to add support for the rest of the commands. It is in my
> ToDo list now.
>
>> 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...
>
> You're right. Just pushed 2 updates for that. We never actually needed
> literal Float64Arrays anyway.
>
>>
>> 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'
>
> Just pushed your IconMorph as an update. Included this as a class
> example method.
>
> Thanks!
>
>>
>> Cheers,
>> Luciano
>
> --
> Juan Vuletich
> www.cuis.st
> github.com/jvuletich
> researchgate.net/profile/Juan-Vuletich
> independent.academia.edu/JuanVuletich
> patents.justia.com/inventor/juan-manuel-vuletich
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260626/2fc1eb2a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-2.png
Type: image/png
Size: 37467 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260626/2fc1eb2a/attachment-0001.png>