[L2Ork-dev] Hello, and a rough plan on how to port K12 mode for GSoC

Coniine Dieu coniinedieu at gmail.com
Fri Mar 29 06:12:36 EDT 2019


Tried converting PNG to SVG and the result is surprisingly nice.

Recipe:
1. Go to http://waifu2x.udp.jp, upscale.
2. Open the upscaled PNG. Trace Bitmap in Inkscape with "Color" mode and
"Smooth" turned off. Try with different numbers of scans.
3. Save as "Optimized SVG".

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: https://tinyurl.com/png-svg-demo

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.

On Thu, Mar 28, 2019 at 9:59 AM Jonathan Wilkes <jon.w.wilkes at gmail.com>
wrote:

> On Wed, Mar 27, 2019 at 9:33 PM Coniine Dieu <coniinedieu at gmail.com>
> wrote:
> >
> > Hi Jonathan,
> >
> > 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?
>
> [draw image] and [ggee/image] both use the same interface for loading
> images in the GUI.
> And [draw image] supports SVG so it shouldn't be difficult to change
> [ggee/image] to support
> them, too.
>
> But this is something that can be done incrementally. For example,
> getting the PNGs to work
> first, then testing by changing one to an SVG.
>
> -Jonathan
>
> >
> > Thanks,
> > Shaoqian
> >
> > On Tue, Mar 26, 2019 at 5:55 AM Jonathan Wilkes <jon.w.wilkes at gmail.com>
> wrote:
> >>
> >> On Mon, Mar 25, 2019 at 1:54 PM Coniine Dieu <coniinedieu at gmail.com>
> wrote:
> >> >
> >> > Hi Jonathan,
> >> >
> >> > Thanks for the quick response.
> >> >
> >> > -- We don't need anything fancy for the tooltips so simple CSS should
> suffice.
> >>
> >> At least for SVG elements, the <title> tag is even easier-- the
> >> browser automatically
> >> hoists the inner text into a tooltip as well as handling the tooltip's
> >> appearance
> >> and placement.
> >>
> >> On the other hand a CSS tooltip gives us automatic text resizing when
> zooming,
> >> which is probably preferable. Just make sure to do some tests with the
> >> corners of
> >> the window to ensure the tip shows up properly.
> >>
> >> >
> >> > -- Yes, I just tested: ggee/image supports relative path and
> @pd_extra works
> >> > indeed if I put the abstractions into the installation folder. I
> wanted to
> >> > create an independent patch so I didn't really check. My bad.
> >>
> >> No problem.
> >>
> >> >
> >> > -- I think we should keep the menus for trivial but necessary entries
> (like
> >> > recently opened files) so we don't clutter the k12 frame. But of
> course, some of
> >> > them can migrate, for the sake of touchscreen too. That leads to--
> >> >
> >> > -- Yes, touchscreen compatibility can be a good objective for the
> third month. I
> >> > wonder if pd has any existing code in charge of touchscreen I can
> study or refer
> >> > to.
> >>
> >> I think what I'm going to do is add touchstart, touchcancel, touchend,
> >> and touchmove
> >> listeners for the document and then just generate the relevant
> mouse-related
> >> events from that. That should at least bring touch up to date with
> >> mouse interaction.
> >> That means it will leverage the same codebase so there's no need for
> separate
> >> code paths aside from the one I mentioned above.
> >>
> >> (Ideally I'd like to use the pointer events API for both touch and
> >> mouse but that
> >> would require an upgrade of nw.js.)
> >>
> >> >
> >> > -- I'll try to convert them into svg and see what happens. If
> anything is too
> >> > complex we can always simplify a bit.
> >>
> >> Sounds good. If you want you could do a single image as a test to make
> sure
> >> the underlying framework supports it.
> >>
> >> >
> >> > I'm excited to know that my plans are feasible. I'll try to finish
> the first
> >> > draft within a few days. Are there any additional information you'd
> like to see
> >> > in the proposal?
> >>
> >> It looks good to me so far. And of course, feel free to keep posting
> >> to the list
> >> here if you have any more questions or run into any issues.
> >>
> >> Best,
> >> Jonathan
> >>
> >> >
> >> > Best,
> >> > Shaoqian
> >> > _______________________________________________
> >> > L2Ork-dev mailing list
> >> > L2Ork-dev at disis.music.vt.edu
> >> > https://disis.music.vt.edu/listinfo/l2ork-dev
> >> _______________________________________________
> >> L2Ork-dev mailing list
> >> L2Ork-dev at disis.music.vt.edu
> >> https://disis.music.vt.edu/listinfo/l2ork-dev
> >
> > _______________________________________________
> > L2Ork-dev mailing list
> > L2Ork-dev at disis.music.vt.edu
> > https://disis.music.vt.edu/listinfo/l2ork-dev
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20190329/ebd22cc8/attachment.html>


More information about the L2Ork-dev mailing list