search

MFEK / math.rlib

A library which supplies mathematics and algorithms for manipulating beziers.
Apache License 2.0
7 stars 4 forks source link

joined and unjoined corner don't have the same stroke result #17

Closed RosaWagner closed 2 years ago

RosaWagner commented 2 years ago

"Joined" is yellow in the screenshots

By joined and unjoined in source I mean:

Capture d’écran 2021-10-20 à 12 26 53

And these are different results after export:

  1. joined looks better

    Capture d’écran 2021-10-20 à 12 25 52

  2. unjoined looks better

    Capture d’écran 2021-10-20 à 12 30 46

In any case, whatever the points are joined are not, it should be the same result, right?

ctrlcctrlv commented 2 years ago

Sorry Rosalie, I'm struggling a bit to understand this issue, by unjoined you really mean two paths which intersect or nearly intersect, right?

No, you should not expect that "unjoined" result should be the same, especially if the end points of the "unjoined" paths are not exactly equal. Because, MFEKstroke will draw a cap, not a join.

I recommend pre-processing to forcably join all "near joins" at path terminals.

RosaWagner commented 2 years ago

By unjointed I mean the two points share the exact same coordinates, but the path is open, not closed. So intersect may be the right term then.

ctrlcctrlv commented 2 years ago

If it is a single path, then why do you have two points where you could have one?

I am very unfamiliar with Glyphsapp so I don't know that I quite understand what the images show, to me it looks like there are two paths meeting almost at the same point.

As far as I know a closed path and an open path should be treated identically regarding joining behavior, however if you have two points at the same location that will definitely lead to weird joining behavior and you should try to clean that up as much as possible.

I suppose that MFEKstroke could do some preprocessing and attempt to eliminate such cases (i.e. if you have two corner points on the same location make them a single corner point) but I believe that this was not done on purpose so that it would be easier to interpolate different outputs from MFEKstroke, where sometimes one Master will have the points at different locations and another Master will have them at the same.

RosaWagner commented 2 years ago

I made a video to show the entire path, tell me if it is clearer this way :) First the path is closed, then I open it by "breaking" a corner point, so then they are two different points at the same location, from the same path.

https://user-images.githubusercontent.com/12222436/138258473-f59cfa54-1bc4-4546-b131-ea5386005749.mov

I don't exactly know the motivation behind it, but the path are optimised for CNC machine, and I kind of guess that it gives instructions to the machine to where it should go up and down in more complex outlines.

As far as I know a closed path and an open path should be treated identically regarding joining behavior, however if you have two points at the same location that will definitely lead to weird joining behavior and you should try to clean that up as much as possible.

So your advice would be to separate the two points of one unit for example? I can try and see. The idea is to avoid having two sources (like one for the CNC and one for the fake stroked version), so i can't tell the author to join all the corner points.

RosaWagner commented 2 years ago

Thanks a lot for your help on this 🙏 I personally struggle to find the correct term in english to describe the issue.

ctrlcctrlv commented 2 years ago

No problem, I'm sorry that I don't have more experience with Glyphs, I've only worked with FontForge and my own font editing software (and of course the various APIs written by Google, Simon and others)

MatthewBlanchard commented 2 years ago

I'm going to add a mode for caps and joins that just outputs circles for CWS and this should fix this problem.

ctrlcctrlv commented 2 years ago

That should work if the points exactly overlap, I'm not sure that this can be guaranteed, I would still recommend some cleanup and I don't really understand why a milling router would find it more efficient to lift up the stylus then come back down and draw another path, but I will leave it to your experience.

Just make sure that the points exactly overlap or I believe you will still get quite strange output.

ctrlcctrlv commented 2 years ago

Now that I'm maintainer, I make the following observations:

Therefore, closing as duplicate of #16 soon to be itself closed by --segmentwise.

davelab6 commented 2 years ago

I'd like to request reopening this issue; @RosaWagner chatted with me today about releasing "Relief" (https://github.com/google/fonts/issues/3271) and currently this stroker still isn't useful for that release :) I'd like to offer to host a call so we 3 can discuss it.

ctrlcctrlv commented 2 years ago

@davelab6 I'm only seeing this now for some reason—sorry—that I'm looking into #27. Is your comment different than the issue at https://github.com/MFEK/math.rlib/issues/27#issuecomment-1104605712 ?