Add Relief

[davelab6]

https://github.com/isdat-type/relief

A skeleton font that will need outlining.

• Contacted designer
• QA repo
• QA font with FB
• QA font with eyes
• Sent to-do
• Mastering
• Build system
• Package

[RosaWagner]

Personal note
The font in single line with open path. Simon is working on a ufostroker filter to export the font with close contours using MFEK math lib.

in venv:

• gftools
• pip install ufostroker

then cmd is: fontmake -f --filter 'ufostroker::StrokeFilter(Segmentwise=True,Width=40,pre=True,StartCap="circle", EndCap="circle",JoinType="round")' -g Relief.glyphs --filter DecomposeTransformedComponentsFilter --overlaps-backend pathops -o ttf --output-dir ../fonts/ttf

[RosaWagner]

These are the problems so far that block us for onbaording this project:

Issue with diagonals joining with short segments:
closed issues but unfortunately unsolved: MFEK/math.rlib#16

Issue with decomposed transformed components filters:
open issue: simoncozens/ufostroker#2

using ufostroker 0.2.3

Note to @davelab6:
The idea for this project is to avoid multiple sources for multiple exports — even if the authors decided to make another repo for the font they actually published (https://github.com/isdat-type/Relief-SingleLine). But we are in a dead end for few months now, so their idea is to outline the source to make a releasable font for GF, that would be called "Relief" instead of "Relief SingleLine". This is not ideal solution but they are eager to move forward on the onboarding process since there is no movement on our end to improve the tooling.

Their other idea is to use Glyphs/fontforge/robofont to export TT binaries, which we can't do for reasons explained in GF specifications.

cc @isdat-type

[isdat-type]

From our own tests, the Expand Stroke function in FontForge seems to remain the best rendering from our skeletal / monolinear drawings, see screenshots (even slightly better than Noodler script on Glyphs App and similar to Outliner script in Robofont). Can Ufostroker use the script library behind Expand Stroke in FontForge to improve the TTF / Fontmake / MFEK export process? Apparently @ctrlcctrlv already mentioned similar remarks earlier.

[ctrlcctrlv]

I replied at MFEK/math.rlib#16 (comment).

I am only interested in potentially bringing FontForge's stroke function into MFEKstroke to the extent that it makes nib stroking possible, if I don't end up solving that in pure Rust first.

[davelab6]

@simoncozens I wonder if this would be interesting for your builder2 work :)

[simoncozens]

If we have a good stroker, then this ties in a lot with Dotter; in fact the hard bit is already done as we are using stroking in builder2 in SIL projects.

The problem here is we're blocked on the current output of ufostroker being suboptimal for small path segments. Porting the fontforge expand stroke logic might move us forward, but that's a big job.