3 ms·

I did test the app for compatibility with Wacom Intuos. "Blob" tool already supports pressure sensitivity [1], as you said it was relatively easy to implement w

I did test the app for compatibility with Wacom Intuos. "Blob" tool already supports pressure sensitivity [1], as you said it was relatively easy to implement with the Pointer Events API. I'm not sure how pressure and tilt information could be used by other tools (other than "Spray") as SVG does not support stroke with variable width. Tracing could be easily implemented using third party libraries [2]. Custom extensions would be initially limited to the "Generators" panel. I haven't thought about the live path effects yet. The hardest part remaining is full support for filters, but I have this feature mostly sorted out in the dev branch and the UI is going to be much nicer than in Inkscape [3][4]. [1] https://i.imgur.com/e08OW5x.png https://i.imgur.com/e08OW5x.png [2] https://boxy-svg.com/ideas/5/vectorize-generator https://boxy-svg.com/ideas/5/vectorize-generator [3] https://i.imgur.com/oGbfa5q.png https://i.imgur.com/oGbfa5q.png [4] https://i.imgur.com/l0IkfKK.png https://i.imgur.com/l0IkfKK.png

chrismorgan 7y ago
Ah, didn’t spot the blob tool. Good show. Inkscape 1.0 adds what’s basically a more powerful version of that, a pressure-sensitive pencil, implemented with the powerstroke live path effect—more powerful, I say, because it’s editable, because it’s not immediately flattening it to what SVG can represent, but is also keeping its own editor information in namespaced attributes. That’s how you can add things like that and mesh gradients before SVG supports the concept. I’m still intensely sceptical of your claim of full feature parity with Inkscape in a year, but I’ll believe parity for >95% of users and use cases. My biggest problem with your app at the moment looks to be that path editing is painful compared with Inkscape. I like to show the outline of the path, and its keyboard and mouse operation also feels just all-round superior at present, and I don’t think that that’s just my greater familiarity with Inkscape showing through. I’d also like more text labels and fewer icons. Iconless labels have no place on something like your filters panel; text labels are objectively superior. I’d say similar for the Defs panel and other such panels. I wish you joy!
- jarek-foksa 7y ago
  On second thought, 100% parity might be a bit overoptimistic as some features such as auto-wrapped text and mesh gradients rely on APIs that must be implemented upstream by Chromium (and those features are not the top priority for Google). But 95% seems sensible to me. There should be an outline shown when you hover a path with the "Edit" tool [1], though it's a bit sloppy and needs more optimization. Most path-related commands are exposed by the "Shape" panel. To convert a node between a smooth and an edge type you must double-click it. The ability to box-transform selected nodes and to move them with arrow keys is missing but should be added soon. My main problem with text labels is that they take a lot of horizontal space. Text labels could be shown only when the panel is wide enough to fit them, or when user hovers the icon (like it's done in Autodesk Graphic). [1] https://i.imgur.com/FgglFOw.gif https://i.imgur.com/FgglFOw.gif
  - chrismorgan 7y ago
    You don’t need upstream support for all features; you can often implement them in older SVG techniques with namespaced extra data to help with editing. That’s how text wrapping has worked in Inkscape historically, though 1.0 is introducing support for the actual defined SVG functionality. Not everything is possible this way; mesh gradients can’t be emulated in vectors, for example—though you could effectively implement a canvas-backed renderer for it to polyfill it; but a lot of functionality can be implemented without upstream support.

chrismorgan 7y ago

Ah, didn’t spot the blob tool. Good show. Inkscape 1.0 adds what’s basically a more powerful version of that, a pressure-sensitive pencil, implemented with the powerstroke live path effect—more powerful, I say, because it’s editable, because it’s not immediately flattening it to what SVG can represent, but is also keeping its own editor information in namespaced attributes. That’s how you can add things like that and mesh gradients before SVG supports the concept. I’m still intensely sceptical of your claim of full feature parity with Inkscape in a year, but I’ll believe parity for >95% of users and use cases. My biggest problem with your app at the moment looks to be that path editing is painful compared with Inkscape. I like to show the outline of the path, and its keyboard and mouse operation also feels just all-round superior at present, and I don’t think that that’s just my greater familiarity with Inkscape showing through. I’d also like more text labels and fewer icons. Iconless labels have no place on something like your filters panel; text labels are objectively superior. I’d say similar for the Defs panel and other such panels. I wish you joy!

jarek-foksa 7y ago
On second thought, 100% parity might be a bit overoptimistic as some features such as auto-wrapped text and mesh gradients rely on APIs that must be implemented upstream by Chromium (and those features are not the top priority for Google). But 95% seems sensible to me. There should be an outline shown when you hover a path with the "Edit" tool [1], though it's a bit sloppy and needs more optimization. Most path-related commands are exposed by the "Shape" panel. To convert a node between a smooth and an edge type you must double-click it. The ability to box-transform selected nodes and to move them with arrow keys is missing but should be added soon. My main problem with text labels is that they take a lot of horizontal space. Text labels could be shown only when the panel is wide enough to fit them, or when user hovers the icon (like it's done in Autodesk Graphic). [1] https://i.imgur.com/FgglFOw.gif https://i.imgur.com/FgglFOw.gif
- chrismorgan 7y ago
  You don’t need upstream support for all features; you can often implement them in older SVG techniques with namespaced extra data to help with editing. That’s how text wrapping has worked in Inkscape historically, though 1.0 is introducing support for the actual defined SVG functionality. Not everything is possible this way; mesh gradients can’t be emulated in vectors, for example—though you could effectively implement a canvas-backed renderer for it to polyfill it; but a lot of functionality can be implemented without upstream support.