I'm a big fan of PaperJS, however, the library doesn't see much activity so we're looking at other tools, like KonvaJS, Fabric, and Pixi. We'd like to replicate the example here:
http://paperjs.org/examples/path-simplification/
in KonvaJS but we're not sure which class is the most appropriate? Should we use the line, which is described as a collection of points with tension, the path tool which is what we use in Paper, or the shape class? Does KonvaJS offer the same type of access to the bezier curve tools and shape border, blue line, found in the above-mentioned paper example?
Konva.Line requires a list of x & y passed into its points property as a simple array, then draws straight lines connecting those points. The tension property can be used to make the straight line joins more curvy.
Konva.Path expects you to provide a data property that is more like a list of SVG drawing instructions, so move, lineto, arc, etc. (See supported instructions list in Konva docs for Konva.Path.data here)
There is no built-in equivalent path-editing features to those in the demo you linked to - so no automatic anchors on the path control points and no Bezier handles. You would have to DIY those. Having said that, it would all be achievable - what I mean is the drawing of the control anchors and lines, the listening for mouse and drag events, and the final passing back of the SVG drawing data to the Konva.Path shape when the path's edit mode ends are all well supported in Konva.
As at May 2022, the Konva lib is well supported, with appropriately frequent (as Goldilocks would want - not too many and not too few), no ill-thought-out breaking changes, issues are responded to, SO posts replied to, and there is a busy Discord channel.
Related
In Visio one of the most fundamental and frustrating annoyances I'm facing is not being able to anchor to the sloping face of the diamond shape.
My organization commonly uses this shape in flow diagrams.
Whether it's a densely connected logic point, which needs more than the 5-6 anchors...
...or a self connecting loop like this:
...I often want to connect to the sloping faces of the diamond shape, but can't seem to find a way to successfully anchor to the sloping part of the shape.
Currently I'm settling for connecting one side, but that leads to frustration when things are repositioned.
I've also explored the Data and Format Shape menus presented by right clicking the shape and the path I'm looking to connect to it as those sounded promising. However, examining those menus, I haven't found anything that looks close to what I need yet.
Seems like there must be a way to do this, though.
Update
I've also tried to redraw the diamond w/ a Pencil in the ribbon's Tools pane under the Shapes dropdown ... but did not have any luck anchoring to the result.
I also have clarified that my question is relating to a basic anchoring need, given my initial example's deviation from traditional UML.
Overview
To anchor to somewhere on a shape face other than the defaults, simply add connector points. (Shift+Ctrl+1, by default)
If this is a common issue, create a master shape with additional connection points to reduce time cost.
Adding Connectors
In Visio 2010 or later:
1.) Enabling Connection Points
Under Views tab, be sure Connection Points in Visual Aids group is CHECKED:
!! NOTE: If this step is ignored, attempts to add points may fail.
2.) Enter Connection Point Edit Mode
Either enter press Shift + Ctrl + 1 or go to Tools group in Home tab and click the x (Connection Point) to enter appropriate edit mode.
3.) Select Shape
Click to select the shape to be edited.
4.) Add a point
Hold Ctrl and then click again on the desired position along the face of the selected shape to add a point.
(Visio 2013 -- after adding a point)
The point is depicted in Visio 2010 as a magenta 'x', while it's depicted as a red square in Visio 2013. The shape itself is thinly outlined, w/ pre-existing connection points shown as blue 'x's in Visio 2010; for Visio 2013, it's instead depicted as a gray bounding box, w/ pre-existing points show in gray for unselected shapes.
You must select the shape before adding the points, however, once selected as many points as are desired may be added.
BEWARE -- once a shape has been selected, you can add connections on other shapes nearby, as well, leading to potentially weird routing.
Complete!
If you don't mind: you are not asking a UML, but a Visio drawing question.
However, I answer in UML context: your drawing does not make sense. Removing the No path will just make it a more valid one. Then it should be an Action called Wait for something that continues only when a something happens. You take a decision only if there's something to decide, not to stop the control flow until an event happens.
In response to your chat question (use of UML): Everything depends. Whether or not you stick with the UML specification (actually the ISO source is available for free at the author's site) is your decision. UML itself leaves great ways to adapt the language to your domain by using profiles. Whenever you deviate from the standard you have to document that and people need to be trained accordingly.
I have to admit that the UML specification is no bedtime lecture. However, there are great sources to learn from (e.g. lots of examples are found here). I for myself work with UML in practice for more than 20 years and have to say that it was worth the time learning it. Always remember that UML is a language and like any language it needs to be spoken actively to convey ideas effectively. Here in Germany we have so many dialects and a general High German. People with a certain idiom can talk to each of their peers without issue, but people from north and south are better served to use the common idiom since their own dialects differ quite fundamentally.
I'm taking an introductory graphics course, and while I intuitively understand that converting a click or touch into object coordinates will make the math much cleaner, reduce the chances for human error, and potentially make debugging easier, none of these are actually a very good explanation, conceptually, of why object coordinate spaces are used in selection tests, as opposed to simply using world coordinates for the test - rather, they're just observations of what tends to happen when object coordinates are used. So I ask: why?
A selection test involves comparing the click coordinates, which you get in window coordinates, against lots and lots of object features, which are represented in object coordinates.
You need to transform them into the same coordinate system in order to do the checks, so you can EITHER transform the one simple click point OR you can transform all the various object features.
Transforming one point or line is just a lot easier that transforming a whole bunch of object features of various types.
There are cases where the location of a specific object or point may not be known within a world coordinate system, but is known relative to some other coordinate system.
To summarize an example from my course text, consider the idea of two different towns, one using a grid system for its layout, and the other using what I can only describe as the New England we-made-cow-trails-into-roads method. A government employee is tasked with creating a layout of the area which includes them, and in doing so has to convert the two coordinate systems into a third, which encompasses the other two.
Sometimes, using a world atlas just isn't practical to get across the street, and so something much more local (and relevant) is used instead, as it provides much more detail over a much smaller area.
The text also explains that it may be more than simply impractical to use a given coordinate system - it may yield results that are improbable or just plain wrong. This is evidenced in the evolution of the geocentric and heliocentric models of the universe - the distance of the stars from us was calculated with very different results using the two models.
Thinking of my own example, the best that comes to mind would be something like your own internal organs - from the outside, you don't know for sure exactly the shape, size, and structure of each of them, but your own body does. In order to be able to access that information, you need to look inside the body (ideally in a way that doesn't kill you). It's not something that is plainly observable from outside.
Does anyone know if it is possible to combine (for example) different CGContext paths to create a new combined shape as in this example?
Thanks!
I found a library that does Union operations on CGPaths:
https://bitbucket.org/martinwinter/vectorbooleancg
I haven't tried it yet, but the author of the CG branch of Vectorbool, Martin Winter, states that the union operation should be usable in its current form on iOS. I will add information when I get around to trying to implement it.
I doubt that there is an Apple lib that supports this feature.
What you need is a so called "union of two (or more) polygons", sometimes called boolean operations on polygons.
I would convert the CGPath to a polygon, probably you start creating a point array that contains your polygon points. That means to not use CGPathAddEllipse, but to approximate the shapes , by e.g a regular polygon with something between 64 and 256 vertices.
You can easily calculate the points of a circle or ellipse for yourself (using something similar to a*cos(t), b*sin(t) see wikipedia for ellipse "parameter formula")
Then you take one of the c libraries that provide these "union operation".
One of that is the LEDA lib.
I have a map that I converted from a raster graphic into an SVG file by converting the differently coloured areas into paths.
I know how to do a basic point-in-polygon check given an array of edges, but the svg:path elements represent multiple polygons as well as masks (to account for seas etc) and extracting that information by parsing the d attribute seems rather heavy-handed.
Is there a JS library that allows me to simplify that check? I basically want to create random points and then check whether they are on land (i.e. inside the polygons) or water (i.e. outside).
As SVG elements seem to allow for mouse event handling, I would think that this shouldn't be much of a problem (i.e. if you can tell whether the mouse pointer is on top of an element, you are already solving the point-in-polygon problem).
EDIT: Complicating the matter a bit, I should mention that the svg:path elements seem to be based on curves rather than lines, so just parsing the d attribute to create an array of edges doesn't seem to be an option.
As the elements can take a fill attribute, a ghetto approach of rendering the SVG on a canvas and then finding the colour value of the pixel at the given point could work, but that seems like a really, really awful way to do it.
The answers on Hit-testing SVG shapes? may help you in this quest. There are issues with missing browser support, but you could perhaps use svgroot.checkIntersection to hit test a small (perhaps even 0 width/height would work?) rectangle within your polygon shape.
The approach I suggested as a last resort seems to be the easiest solution for this problem.
I found a nice JS library that makes it easy to render SVG on a canvas. With the SVG rendered, all it takes is a call to the 2D context's getImageData method for a 1x1 region at the point you want to check. I guess it helps to create a copy of the SVG with colour coding to make the check easier if your SVG is more complex than the one I'm using (you'll have to check the RGBA value byte-by-byte).
This feels terribly hackish as you're actually inspecting the pixels of a raster image, but the performance seems to be decent enough and the colour checks can be written in a way that allows for impurities (e.g. near the edges).
I guess if you want relative coordinates you could try creating a 1-to-1 sized canvas and then divide the pixel coordinates by the canvas dimensions.
If somebody comes up with a better answer, I'll accept it instead. Until then, this one serves as a placeholder in case someone comes here with the same problem looking for an easy solution.
I work for a ticketing agency and we print out tickets on our own ticket printer. I have been straight coding the ticket designs and storing the templates in a database. If we need a new field adding to a ticket I manually add it and use the arcane co-ordinate system to estimate where the fields should go and how much the other fields need to move by to accomodate new info.
We always planned to make this system automate with a simple (I stress the word simple) graphical editor. Basically we don't forsee tickets changing radically in shape any time soon, we have one size of ticket and the ticket printer firmware is super simple because it's more of an industrial machine, it has about 10 fonts and some really basic sizing interactions.
I need to make this editor display a rectangle of the dimensions by pixel of the tickets (can even be actual size) and have a resizable grid which can toggle between superimposition and invisibility on top of the ticket rectangle and represented by dots rather than lines.
Then I want to be able to represent fields by drawing rectangles filled with the letter "x" that show the maximum size of the field (to prevent overlaps). These fields should be selectable, draggable and droppable in a snap to grid fashion.
I've worked out the maths of it but I have no idea how to draw rectangles and then draw grids in layers and then put further rectangles full of 'x'es on top of those. I also don't really know much about changing drawn positions in accordance with mouse events. It's simply not something I've ever had to do.
All the tutorials I've seen so far presume that you already know a lot about using the draw objects and are seeking to extend a basic knowledge of these things. I just need pointing in the direction of a good tutorial in manipulating floating objects in a picturebox in the first place.
Any ideas?
For those of you in need of a guide to this unusual (at least those of us with a BIS background) field I would heartily endorse:
https://web.archive.org/web/20141230145656/http://bobpowell.net/faqmain.aspx
I am now happily drawing graphical interfaces and getting them to respond to control inputs with not too much hassle.