<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Tried converting PNG to SVG and the result is surprisingly nice.</div><div><br></div><div>Recipe:</div><div>1. Go to <a href="http://waifu2x.udp.jp">http://waifu2x.udp.jp</a>, upscale.</div><div>2. Open the upscaled PNG. Trace Bitmap in Inkscape with "Color" mode and "Smooth" turned off. Try with different numbers of scans.</div><div>3. Save as "Optimized SVG".</div><div><br></div><div>When using less numbers of scans, the file is small (down to 15 KB), and the result has a cute cartoon/crayon feel in it. Thus using SVG is definitely a viable option. Here's a Google Drive link to the files I've tested: <a href="https://tinyurl.com/png-svg-demo">https://tinyurl.com/png-svg-demo</a></div><div><br></div><div>However I'm not sure how [draw image] works. I tried having [struct svg-test float x float y], and then [draw image path-to-my.svg]. When I create [svg-test], it becomes a tiny transparent object that apparently doesn't display the SVG. I wonder what am I doing wrong here.</div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 28, 2019 at 9:59 AM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com">jon.w.wilkes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Mar 27, 2019 at 9:33 PM Coniine Dieu <<a href="mailto:coniinedieu@gmail.com" target="_blank">coniinedieu@gmail.com</a>> wrote:<br>
><br>
> Hi Jonathan,<br>
><br>
> Currently as we are using PNG files for k12 abstractions, we use [image] to load it. However I'm not sure how to do the same for SVG files since it seems that both [image] and [ggee/image] do not support it. I am wondering, if we are using SVG files for k12 abstractions, does that mean we have to write new objects that loads SVG files? Or are there other ways to do this?<br>
<br>
[draw image] and [ggee/image] both use the same interface for loading<br>
images in the GUI.<br>
And [draw image] supports SVG so it shouldn't be difficult to change<br>
[ggee/image] to support<br>
them, too.<br>
<br>
But this is something that can be done incrementally. For example,<br>
getting the PNGs to work<br>
first, then testing by changing one to an SVG.<br>
<br>
-Jonathan<br>
<br>
><br>
> Thanks,<br>
> Shaoqian<br>
><br>
> On Tue, Mar 26, 2019 at 5:55 AM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br>
>><br>
>> On Mon, Mar 25, 2019 at 1:54 PM Coniine Dieu <<a href="mailto:coniinedieu@gmail.com" target="_blank">coniinedieu@gmail.com</a>> wrote:<br>
>> ><br>
>> > Hi Jonathan,<br>
>> ><br>
>> > Thanks for the quick response.<br>
>> ><br>
>> > -- We don't need anything fancy for the tooltips so simple CSS should suffice.<br>
>><br>
>> At least for SVG elements, the <title> tag is even easier-- the<br>
>> browser automatically<br>
>> hoists the inner text into a tooltip as well as handling the tooltip's<br>
>> appearance<br>
>> and placement.<br>
>><br>
>> On the other hand a CSS tooltip gives us automatic text resizing when zooming,<br>
>> which is probably preferable. Just make sure to do some tests with the<br>
>> corners of<br>
>> the window to ensure the tip shows up properly.<br>
>><br>
>> ><br>
>> > -- Yes, I just tested: ggee/image supports relative path and @pd_extra works<br>
>> > indeed if I put the abstractions into the installation folder. I wanted to<br>
>> > create an independent patch so I didn't really check. My bad.<br>
>><br>
>> No problem.<br>
>><br>
>> ><br>
>> > -- I think we should keep the menus for trivial but necessary entries (like<br>
>> > recently opened files) so we don't clutter the k12 frame. But of course, some of<br>
>> > them can migrate, for the sake of touchscreen too. That leads to--<br>
>> ><br>
>> > -- Yes, touchscreen compatibility can be a good objective for the third month. I<br>
>> > wonder if pd has any existing code in charge of touchscreen I can study or refer<br>
>> > to.<br>
>><br>
>> I think what I'm going to do is add touchstart, touchcancel, touchend,<br>
>> and touchmove<br>
>> listeners for the document and then just generate the relevant mouse-related<br>
>> events from that. That should at least bring touch up to date with<br>
>> mouse interaction.<br>
>> That means it will leverage the same codebase so there's no need for separate<br>
>> code paths aside from the one I mentioned above.<br>
>><br>
>> (Ideally I'd like to use the pointer events API for both touch and<br>
>> mouse but that<br>
>> would require an upgrade of nw.js.)<br>
>><br>
>> ><br>
>> > -- I'll try to convert them into svg and see what happens. If anything is too<br>
>> > complex we can always simplify a bit.<br>
>><br>
>> Sounds good. If you want you could do a single image as a test to make sure<br>
>> the underlying framework supports it.<br>
>><br>
>> ><br>
>> > I'm excited to know that my plans are feasible. I'll try to finish the first<br>
>> > draft within a few days. Are there any additional information you'd like to see<br>
>> > in the proposal?<br>
>><br>
>> It looks good to me so far. And of course, feel free to keep posting<br>
>> to the list<br>
>> here if you have any more questions or run into any issues.<br>
>><br>
>> Best,<br>
>> Jonathan<br>
>><br>
>> ><br>
>> > Best,<br>
>> > Shaoqian<br>
>> > _______________________________________________<br>
>> > L2Ork-dev mailing list<br>
>> > <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
>> > <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
>> _______________________________________________<br>
>> L2Ork-dev mailing list<br>
>> <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
>> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
><br>
> _______________________________________________<br>
> L2Ork-dev mailing list<br>
> <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div>