Very short segments lead to many extraneous points

[simoncozens]

Consider a glyph designed for CNC routers which cannot change direction quick enough to draw sharp corners; you have to add tiny line segments to help change direction:

Sample glif:

<?xml version="1.0" encoding="UTF-8"?>
<glyph name="A" format="2">
        <advance width="600"/>
        <unicode hex="0041"/>
        <outline>
                <contour>
                        <point x="0" y="150" type="move"/>
                        <point x="100" y="150" type="line"/>
                        <point x="100" y="141" type="line"/>
                        <point x="0" y="0" type="line"/>
                </contour>
        </outline>
</glyph>

Unfortunately when this is stroked with MFEKstroker, you get lots of weird points:

Which (when combined with #15) makes the outline really bad...

Mitigating #15 will fix the problems in the top right, but the bottom right is still urgh.

[simoncozens]

Cc @RosaWagner

[ctrlcctrlv]

please post the full MFEKstroke command line which generated this

[simoncozens]

./target/debug/MFEKstroke CWS --width 75 --input cnc.glif --output cnc-stroked.glif

[ctrlcctrlv]

@simoncozens For such a small patch, my #15 patch to flo_curves sure is providing a lot of benefit even to things I wasn't thinking about at the time:

The difference between left and right is just increased strictness of accuracy. I played around with it a bit to try to make it perfect, but didn't quite get there I'm afraid. Maybe another time. However, certainly this is much better than what you've got.

[ctrlcctrlv]

@simoncozens How does this look?

OK, I did cheat a bit.

While thinking about the problem (how can I get these circle arcs to behave?) I realized, "hey wait a minute, I just want full circles at every place the path ends…that is to say, I want all joins treated as caps. So, why don't I just do that and let the overlap engine deal with it?"

And so that's what I did. Can I add that as an option and close this?

[ctrlcctrlv]

For more information:

FontForge is able to perfectly join the path. I'm not seeing any downsides to this method, and compared to somehow re-adding information about the original points to fix_path—the function in VWS.rs that actually adds the joins and therefore needs to be able to determine a circular arc's center—very simple. I'm quite pleased with it.

[simoncozens]

Yeah, that’s a very nice approach.

[ctrlcctrlv]

@simoncozens You can now simply provide --segmentwise to MFEKstroke. In case you are hooking into this library directly, the commit MFEK/stroke@7fcf9d0 may be instructive.

[simoncozens]

With that change, I'm getting Empty piecewise has no start point.

equal.glif:

<?xml version='1.0' encoding='UTF-8'?>
<glyph name="equal" format="2">
  <advance width="554"/>
  <unicode hex="003D"/>
  <outline>
    <contour>
      <point x="454" y="422" type="move"/>
      <point x="100" y="422" type="line"/>
      <point x="100" y="423" type="line"/>
    </contour>
    <contour>
      <point x="454" y="222" type="move"/>
      <point x="100" y="222" type="line"/>
      <point x="100" y="223" type="line"/>
    </contour>
  </outline>
</glyph>

Command line:
MFEKstroke CWS --segmentwise --input equal.glif --output equal-stroke.glif --width 25

[ctrlcctrlv]

@simoncozens I think I found the issue. See 26e0073

He was using whole units as a check for colocated handles, which is way too large I think.

It works for me now.

[RosaWagner]

Using --segmentwise I am still having this issue
I am using this command: fontmake -f --filter 'ufostroker::StrokeFilter(Segmentwise=True,Width=40,pre=True)' -g Relief.glyphs --filter DecomposeTransformedComponentsFilter --overlaps-backend pathops -o ttf

[ctrlcctrlv]

That strikes me as perhaps being caused by rounding to integer done for TTF format?