Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scope #14

Open
ctrlcctrlv opened this issue May 15, 2021 · 0 comments
Open

Scope #14

ctrlcctrlv opened this issue May 15, 2021 · 0 comments
Labels
meta An issue of scope, goals, maintainership, etc

Comments

@ctrlcctrlv
Copy link

@MatthewBlanchard and I had a good discussion about the scope of MFEKstroke.

Before layers were added to MFEKglif (layers dev branch), this project was used by MFEKglif to "flatten" the VWS out of a .glif file.

That's why VWS is weird here. It's the only one with no CLI API, and this strange description:

(Note: In VWS mode, it is expected that you are using MFEKglif to generate the input files. Therefore, not many helpful command line options are provided. If you wish to use VWS programatically, play with MFEKglif's VWS tool, get some output, and study it; then generate conformant XML.)

That's a clue that VWS is out of scope. It's too complicated to define a CLI API for, and MFEKstroke shouldn't be the one flattening it.

MFEKglif --export should be.

Therefore, I propose:

  • Removing variable_width_stroke.rs and the VWS mode;
  • Keeping VWS documented here, with its screenshot, but noting that it, like the other MFEKglif "flatten"/"export" operations, be done by MFEKglif --export.

That keeps the scope of MFEKstroke laser-focused: a CLI API for MFEKmath / path stroking in .glif files.

@ctrlcctrlv ctrlcctrlv added the meta An issue of scope, goals, maintainership, etc label Sep 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta An issue of scope, goals, maintainership, etc
Projects
None yet
Development

No branches or pull requests

1 participant