Closed davelab6 closed 4 months ago
@petrvanblokland replied
It's not "quick" :) Compiling takes a couple of hours. That' why I compile on a glyphset of only 4 glyphs.
The GF team is making good progress with the new rust fontc
compiler, but I'm not sure when it will be ready for COLR compilation... should help tho :)
There's a local folder
_develop/
that I use to compile subsets for testing, which is in.gitignore
, not to pollute the repo too much.
OK cool :)
I added the latest test VF in fonts/BitcountMono_Double2-TEST-VF.ttf
perfect!
Type "abce" in FontGoggles. Currently /e contains the canvas that shows the pixel surroundings for both layers.
Two things I need to add here:
- Add the other main 4 Bitcount axes (slnt, wght, OPEN and SHPE). I'll do that in the weekend for this test font.
That's perfect
- I would like to add more shapes to the layer than just concentric gradients.
Wonderful! @simoncozens PTAL
I think I have a way to dramatically reduce the build time, but it will require some extensive reworking of the build process. But I think this is something we want to do anyway as we add more shapes.
The basic idea is this: the current way we build colour fonts is more or less the same way we build non-colour variable fonts; we define all the "variability" by adding masters. However, I have a tool called paintcompiler which allows you to treat the COLRv1 paints more like an animation tool. Instead of defining what the font looks like at each location, you instead declare how it should vary. This variation information goes straight into the COLR table, without needing to define any masters.
For example, if I want to say that a paint moves up from 0 to 100 as the TRAY axis increases from 0 to 1, I don't create two UFO masters, one at TRAY=0 and one at TRAY=1; instead I simply tell the paint how it should vary:
PaintTranslate(0, {
(("TRAY", 0),): 0,
(("TRAY", 1),): 100,
}, PaintGlyph(...)
It's a different way of working, much more like programming than designing (until we have a nice graphical interface on top one day), but it ought to dramatically cut down on the number of masters that you need to compile, and also gives much more flexibility in specifying the combination of effects that you want to apply.
I think it would be a good idea to move Bitcount in this direction, and I think it would actually simplify a lot of the process, but it would be quite an invasive change.
On May 27, 2023, at 12:53 AM, Dave Crossland @.***> wrote:
@petrvanblokland https://github.com/petrvanblokland replied
It's not "quick" :) Compiling takes a couple of hours. That' why I compile on a glyphset of only 4 glyphs
The GF team is making good progress with the new rust fontc compiler, but I'm not sure when it will be ready for COLR compilation... should help tho :)
Compiling the final VF is only part of the compilation time. What also takes time is the generation of all UFO files, copying from the one source and setting the pixel shapes for each master.
There's a local folder _develop/ that I use to compile subsets for testing, which is in .gitignore, not to pollute the repo too much.
OK cool :)
I moved it to the main sources/ folder now, with a build.py switch to generate with the full glyphset or just an abcde subset for testing. Current there is compiled test VF in sources/vf/Bitcount_Mono_Double4-COLRv1-009.ttf in FontGoggles I added the latest test VF in fonts/BitcountMono_Double2-TEST-VF.ttf
perfect!
Type "abce" in FontGoggles. Currently /e contains the canvas that shows the pixel surroundings for both layers.
Two things I need to add here:
Add the other main 4 Bitcount axes (slnt, wght, OPEN and SHPE). I'll do that in the weekend for this test font. That's perfect
I would like to add more shapes to the layer than just concentric gradients. Wonderful! @simoncozens https://github.com/simoncozens PTAL
Try sources/vf/Bitcount_Mono_Double4-COLRv1-009.ttf in FontGoggles. Pixel shape axes: • slnt = Slant, circles stay circles, verticals slant, pixels positions slant. Note that there is a separate [ss08] OT-feature to make italic shapes, independent of the slanting angle. • wght = Weight, size of the pixels. Default (400) is a pixel size, e.g. circles, where the pixels just touch. Lighter makes separate pixels, bolder makes them overlap. • OPEN = Open pixels, split into 4 quadrants. • SHPE = Shape, the axis enables a catalogue of shapes, fluently blending into the next. In order of appearance: filled circles (0), outline circles (80), filled squares with circle inside (180), filled square with diamond inside (265), outline square (362), filled square (500), plus (620), filled diamond (720), filled star (800), outline star (900), filled square with star inside (1000)
Then there are 6 independent COLRv1 axes that define the coloring of the selected pixel shape. Type /canvas (with the slash) and enable the [calt] OT-feature to show a canvas square as glyph. Different from showing the COLRv1 pattern in each individual pixel, the /canvas glyph show the full em-square with the color layers. There is a small square in the middle that shows the clipping area of the pixel. This was it's easy to select a color pattern and calibrate the position of the layers.
The COLRv1 layers are: • LR1S = Layer1-Scale, defines the scale of layer 1. By default the value is 0, so no colors are show. I don't see a possibility to alter the default value, without adding more masters to the axes (which dramatically will increase the size of the VF file). More about that below in "known issues" • LR1X = Layer1-X. Horizontal position of layer 1. The same problem is here. Since the axis has 2 masters, the default position shows the circle in the middle of pixels. But that does not allow to move the layer to the right of the concentric circles. A work around is to add more circles on the left, but that requires the drawing of multiple elements in the same layer, something I did not manage to get working yet. LR1Y = Layer1-Y. Vertical position of layer 1. The same happens here, it is not possible to have the circles centered in the pixel by default AND use only 2 masters AND allow showing area above the circles (making the layer go down, below the default position) • LR2S = Layer 2 scale (same as LR1S in "independent" layer) • LR2X = Layer 2 horizontal position (same as LR1X in "independent" layer) • LR2Y = Layer 2 vertical position (same as LR1Y in "independent" layer)
See screens below with various axes settings.
Also note there is a number of normal OT-features supporting small-caps, stylistic alternates. For the Bitcount Single variants there is also a condensed available. Currently we only compile the Mono Double for testing the COLRv1 axes. For the other 5 Bitcount variants the color working will be identical.
To do: • Decision about all axis names. • If final file size allows, we could add a third color layer with different shapes to choose from. The layers allow blending of color shapes. That is independent from the collection of shapes that can be on one each separate layer. • Add a manual and visual examples to the documentation and the website.
Known issues to the current COLRv1 state: • Currently each COLRv1 axes has 2 masters. That causes limitations when selecting a default in the middle (e.g. with horizontal and vertical positioning). As mentioned before, a work around is to place multiple shapes on the same layer, so it is less of a problem that the half of the circle on the corner cannot be reached. I tried adding default masters to the X and Y axes, but that increases the number of color masters from 64 (2^6) to 729 (3^6), just for the color masters. Note that Bitcount has a large glyphset, so this adds a lot to the volume (and compile time) • The 6 axes currently make a 6-dimensional cube, with the definition of the corners. This makes the selection of one layer dependent on the selection of another layer. It is visible when layer 1 is positioned, then changing the position of layer 2 will also alter the positions of layer 1. There is not a good way in VF to make truly independent axes if corners of the cubes remain undefined. However, adding them here will dramatically increase the side of the file. It would be nice if VF allowed true independent axes, especially with COLRv1 usage, since the axes that define the black masking shape and the axes that define the color layer don't need to be related. Even so, the two layers are now supposed to have a relation, but in the way VF currently is constructed, to do interact. • How to draw multiple shapes in one layer? (See the current code below. Now multiple shapes are drawn in that layer, but the does not seem to work. Only returning if one is returned.) • The default background color of layer it purple. I need to find a way to make the gray instead.
def getPaintRadialGradient1(s, x, y): layers = [] r1 = { "Format": ot.PaintFormat.PaintRadialGradient, "ColorLine": { "ColorStop": COLOR_STOPS1, # can be more than 2 "Extend": "pad", # pad, repeat, reflect }, "x0": x+50, # Offset into middle of pixel and middle of canvas "y0": y+50, "r0": 1, "x1": x+50, "y1": y+50, "r1": s+1, } r2 = { "Format": ot.PaintFormat.PaintRadialGradient, "ColorLine": { "ColorStop": COLOR_STOPS2, # can be more than 2 "Extend": "pad", # pad, repeat, reflect }, "x0": x+50, # Offset into middle of pixel "y0": y+50, "r0": 1, "x1": x+50, "y1": y+50, "r1": s+1, } layers.append(r1) return layers[0] # @@@@@ This should be changed return (ot.PaintFormat.PaintColrLayers, layers)
—
Reply to this email directly, view it on GitHub https://github.com/petrvanblokland/TYPETR-Bitcount/issues/3#issuecomment-1565044907, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC4DQJTCF63HW673Q3WNZTXIEX5FANCNFSM6AAAAAAYQRTUEY. You are receiving this because you were mentioned.
@petrvanblokland please could you update us on overall project schedule, such that we can plan for the axis registration and onboarding efforts that I have to organize once you are nearly ready to release the project :)
Ok, I'll finishing the color template layers this weekend. Update early next week.
P
On Jul 13, 2023, at 11:27 PM, Dave Crossland @.***> wrote:
@petrvanblokland https://github.com/petrvanblokland please could you update us on overall project schedule, such that we can plan for the axis registration and onboarding efforts that I have to organize once you are nearly ready to release the project :)
— Reply to this email directly, view it on GitHub https://github.com/petrvanblokland/TYPETR-Bitcount/issues/3#issuecomment-1634944406, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC4DQIYIXRAJT54U5DG7XDXQBR4NANCNFSM6AAAAAAYQRTUEY. You are receiving this because you were mentioned.
@petrvanblokland nice :) how are you faring?
Hi Dave,
Going good, I guess I need one more day of calibrating the /canvas previewer and some pixel gradients. Now the /canvas viewer also shows the selected shape of the pixel. And almost all design space location give a nice result (no blanks), so the Axis-Praxis random button works.
With Simon's update generating a new VF only takes a couple of minutes. So much easier to make iterations now.
P

On Jul 19, 2023, at 2:16 AM, Dave Crossland @.***> wrote:
@petrvanblokland https://github.com/petrvanblokland nice :) how are you faring?
— Reply to this email directly, view it on GitHub https://github.com/petrvanblokland/TYPETR-Bitcount/issues/3#issuecomment-1641181918, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC4DQOCABFMXYUROGEMFF3XQ4RNDANCNFSM6AAAAAAYQRTUEY. You are receiving this because you were mentioned.
Excellent. @vv-monsalve will work with you on the onboarding process, and the axis registration process is probably the first step. Are the number of axes settled?
On Jul 19, 2023, at 4:14 PM, Dave Crossland @.***> wrote:
Excellent. @vv-monsalve https://github.com/vv-monsalve will work with you on the onboarding process, and the axis registration process is probably the first step. Are the number of axes settled?
Yes. 4 + 6 axes. Shape of the pixels: Slant (slnt), Weight (wght = size of pixels), Split pixel into qaudrants (OPEN) and a catalogue of shapes on one axis (SHPE). Color background: Background scale (BG-S), Background horizontal offset (BG-X), Background vertical offset (BG-Y) Color foreground: Foreground scale (FG-S), Foreground horizontal offset (FG-X), Foreground vertical offset (FG-Y)
I'll commit a build for all 4 VF variants today.
Things remaining to do is a bit of tweaking color transparency in the foreground layer, but that does not change much to the system anymore.
P
— Reply to this email directly, view it on GitHub https://github.com/petrvanblokland/TYPETR-Bitcount/issues/3#issuecomment-1642168861, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC4DQPE7OLPUSEYMMQU5CDXQ7TTDANCNFSM6AAAAAAYQRTUEY. You are receiving this because you were mentioned.
Hi @petrvanblokland,
Bitcount has a few axes that can use already registered custom axes or proposed axes. I've drafted some axis issue proposals for the new ones that need to be registered. These proposals are available in the googlefonts/axisregistry repo.
To draft these axis issue proposals, I took into account the discussions in emails, inspected the font, and followed the Axis Registry Protocol specified in the GF Guide.
Please take a look at them and let's continue the discussion on each issue.
wght
= "Weight, size of the pixels. Default (400) is a pixel size, e.g. circles, where the pixels just touch. Lighter makes separate pixels, bolder makes them overlap."
If the axis is adjusting the darkness of strokes or other forms without changing their overall width, inter-letter spacing, kerning, or page layout, and if you want them to actually overlap in bolder positions, then the BleedBLED
axis would be the best choice.
SHPE
= "Shape, the axis enables a catalogue of shapes, fluently blending into the next."
This axis corresponds to the already registered Element Shape ELSH
axis. You can find more details for this axis in its original proposal issue.
OPEN
= "Open pixels, split into 4 quadrants."
Introducing it as Element Expansion ELXP
LR1S
= "Layer1-Scale, defines the scale of layer 1."
Introducing it as Layer SizeLYSZ
LR1X
= "Layer1-X. Horizontal position of layer 1."
Introducing it as Horizontal Position Layer 1 XLY1
LR1Y
= "Layer1-Y. Vertical position of layer 1"
Introducing it as Vertical Position Layer 1 YLY1
Note: Currently the Color axis has been discussed with the "Layer" name. However probably "Paint" could be a better name for them
@petrvanblokland could you make the default instance show color by centering the texture in the clipping mask?
This will substantially simplify how the gf catalog can showcase the font
Do you mean that it's now black & white because that is in the middle of the concentric circle? I can change the pattern so it shows color and put the white-middle point in another element.
On Aug 4, 2023, at 7:42 PM, Dave Crossland @.***> wrote:
@petrvanblokland https://github.com/petrvanblokland could you make the default instance show color by centering the texture in the clipping mask?
— Reply to this email directly, view it on GitHub https://github.com/petrvanblokland/TYPETR-Bitcount/issues/3#issuecomment-1665968608, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC4DQODX54USYAT6IH4KILXTUX7HANCNFSM6AAAAAAYQRTUEY. You are receiving this because you were mentioned.
Hi Simon,
The Bitcount repo does not seem to compile anymore by terminal, or does it? As the directories and files moved, this does not work now:
@.***$ python scripts/build.py
--- Bitcount_Grid_Single4.designspace
... Make design space sources/build/Bitcount_Grid_Single4.designspace
Traceback (most recent call last):
File "/Users/petr/Desktop/TYPETR-git/TYPETR-Bitcount/scripts/build.py", line 51, in
How should the build run from local terminal for testing?
Best, Petr
On Aug 4, 2023, at 7:42 PM, Dave Crossland @.***> wrote:
@petrvanblokland https://github.com/petrvanblokland could you make the default instance show color by centering the texture in the clipping mask?
— Reply to this email directly, view it on GitHub https://github.com/petrvanblokland/TYPETR-Bitcount/issues/3#issuecomment-1665968608, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC4DQODX54USYAT6IH4KILXTUX7HANCNFSM6AAAAAAYQRTUEY. You are receiving this because you were mentioned.
Run "make build"
"make build" gives this error:
touch venv/touchfile
. venv/bin/activate; python3 scripts/first-run.py
Fixing URLs: https://googlefonts.github.io/googlefonts-project-template -> https://petrvanblokland.github.io/TYPETR-Bitcount.git
Fixing URLs: https%3A%2F%2Fraw.githubusercontent.com%2Fgooglefonts%2Fgooglefonts-project-template -> https%3A%2F%2Fraw.githubusercontent.com%2Fpetrvanblokland%2FTYPETR-Bitcount.git
Fixing URLs: https://yourname.github.io/your-font-repository-name -> https://petrvanblokland.github.io/TYPETR-Bitcount.git
Pinning dependencies
. venv/bin/activate; rm -rf fonts/; python3 scripts/build.py
--- Bitcount_Grid_Single4.designspace
... Make design space sources/build/Bitcount_Grid_Single4.designspace
Traceback (most recent call last):
File "/Users/petr/Desktop/TYPETR-git/TYPETR-Bitcount/scripts/build.py", line 51, in
Design space files are located in sources/
On Aug 7, 2023, at 10:00 AM, Simon Cozens @.***> wrote:
Run "make build"
— Reply to this email directly, view it on GitHub https://github.com/petrvanblokland/TYPETR-Bitcount/issues/3#issuecomment-1667382493, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC4DQK5YFD6QAFPETORWDLXUCOCJANCNFSM6AAAAAAYQRTUEY. You are receiving this because you were mentioned.
My fault. I missed out a commit from my PR. For the time being, make a directory called "build" inside sources. Meanwhile I'll add it to the repo.
I chatted with @vv-monsalve and the latest version from Simon (c04ccfe9c19985aa09196366d2cffb5f00845c87) is still very slow to render on macOS, so I am keen to keep this on Github as a "Bitcount Mega" family release, and make a more modest "Bitcount" family that e.g. has a much smaller reference pixel or has a single color "background" layer - whatever keeps the design concept but is more performant :)
I would like to get this published in GF before the end of the year, and therefore working backwards from the publication process cut off date on November 31st, we need to have the release tagged on this repo and this repo made public on October 16th. Is this possible?
That gives 2-3 weeks for the axis registration and 2-3 weeks to push through sandbox to production.
No problem, I can make a lighter one. Maybe iterate a bit still to see how far back it should be simplified. Meanwhile, is there a decision about the axis names?
P
On Sep 26, 2023, at 11:22 PM, Dave Crossland @.***> wrote:
I chatted with @vv-monsalve https://github.com/vv-monsalve and the latest version from Simon (c04ccfe https://github.com/petrvanblokland/TYPETR-Bitcount/commit/c04ccfe9c19985aa09196366d2cffb5f00845c87) is still very slow to render on macOS, so I am keen to keep this on Github as a "Bitcount Mega" family release, and make a more modest "Bitcount" family that has a much smaller reference pixel that is more performant :)
— Reply to this email directly, view it on GitHub https://github.com/petrvanblokland/TYPETR-Bitcount/issues/3#issuecomment-1736321396, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC4DQMIPXFUSVABSP74SHLX4NBQ3ANCNFSM6AAAAAAYQRTUEY. You are receiving this because you were mentioned.
No, I will try to chase down feedback from our side this week, could be late Friday your time :)
On Sep 26, 2023, at 11:25 PM, Dave Crossland @.***> wrote:
I would like to get this published in GF before the end of the year, and therefore working backwards from the publication process cut off date on November 31st, we need to have the release tagged on this repo and this repo made public on October 16th. Is this possible?
Ok, I'll put it in the schedule to update the website, documentation and the lighter version(s) of the layering. As I said in the previous mail, the only external factor still is the final naming of the axes.
P
— Reply to this email directly, view it on GitHub https://github.com/petrvanblokland/TYPETR-Bitcount/issues/3#issuecomment-1736324179, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC4DQJI3QHG2H4A67R2ICLX4NB3HANCNFSM6AAAAAAYQRTUEY. You are receiving this because you were mentioned.
great - Vivi and I've emailed Evan now with the latest builds so we hope to get you feedback on those shortly :)
No update from Evan yet, I will follow up with him now
So, we need to finalize the structure of the performant layering, and pin down exactly what axes will be in that version, to proceed :)
In the more simple VF version that we are making, the axes won't change, so the question is still there. how to name them. We'll just change the complexity of the two layers.
Pixel shaping
wght - Weight slnt - Slant
OPEN - Split pixels in 4 qaudrants SHPE - Continuous catalog of morphin pixel shapes
FOLRv1 layering
FG-S - Scale of foreground layer FG-X - X-offset of foreground layer FG-Y - Y-offset of foreground layer
BG-S - Scale of background layer BG-X - X-offset of background layer BG-Y - Y-offset of background layer
On Oct 6, 2023, at 5:58 PM, Dave Crossland @.***> wrote:
So, we need to finalize the structure of the performant layering, and pin down exactly what axes will be in that version, to proceed :)
— Reply to this email directly, view it on GitHub https://github.com/petrvanblokland/TYPETR-Bitcount/issues/3#issuecomment-1750985692, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC4DQOXZKJYOAAOJRPAL4LX6ATCRAVCNFSM6AAAAAAYQRTUE2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJQHE4DKNRZGI. You are receiving this because you were mentioned.
Hi Dave,
Any news about the final naming of the axes?
P
On Oct 6, 2023, at 6:57 PM, Petr van Blokland @.***> wrote:
In the more simple VF version that we are making, the axes won't change, so the question is still there. how to name them. We'll just change the complexity of the two layers.
Pixel shaping
wght - Weight slnt - Slant
OPEN - Split pixels in 4 qaudrants SHPE - Continuous catalog of morphin pixel shapes
FOLRv1 layering
FG-S - Scale of foreground layer FG-X - X-offset of foreground layer FG-Y - Y-offset of foreground layer
BG-S - Scale of background layer BG-X - X-offset of background layer BG-Y - Y-offset of background layer
On Oct 6, 2023, at 5:58 PM, Dave Crossland @.***> wrote:
So, we need to finalize the structure of the performant layering, and pin down exactly what axes will be in that version, to proceed :)
— Reply to this email directly, view it on GitHub https://github.com/petrvanblokland/TYPETR-Bitcount/issues/3#issuecomment-1750985692, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC4DQOXZKJYOAAOJRPAL4LX6ATCRAVCNFSM6AAAAAAYQRTUE2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJQHE4DKNRZGI. You are receiving this because you were mentioned.
Petr van Blokland Mastodon @. Instagram @petrvanblokland Intentionally not on FaceBook since 1990 and Twitter stopped. @. | designdesign.space | typetr.com mobile +31 6 24 219 502
Claudia Mens | @.*** mobile +31 6 41 367 689
Rotterdamseweg 150-d 2628 AP Delft The Netherlands
Any news about the final naming of the axes?
There are now 4 sets of axes finalized here:
https://github.com/googlefonts/axisregistry/issues/116#issuecomment-1847689488
https://github.com/googlefonts/axisregistry/issues/128#issuecomment-1847577009
https://github.com/googlefonts/axisregistry/issues/113#issuecomment-1847643080
https://github.com/googlefonts/axisregistry/issues/117#issuecomment-1847688410
@vv-monsalve is away from work at the moment, for maybe another few weeks, but these should have all the info you need.
Regarding the filenames, you have:
Bitcount_Grid_Double4-Color[wght,ELXP,ELSH,slnt,SZP1,XPN1,XPN1,SZP2,XPN2,YPN2].ttf
Bitcount_Grid_Single4-Color[wght,ELXP,ELSH,slnt,SZP1,XPN1,XPN1,SZP2,XPN2,YPN2].ttf
Bitcount_Mono_Double4-Color[wght,ELXP,ELSH,slnt,SZP1,XPN1,XPN1,SZP2,XPN2,YPN2].ttf
Bitcount_Mono_Single4-Color[wght,ELXP,ELSH,slnt,SZP1,XPN1,XPN1,SZP2,XPN2,YPN2].ttf
Bitcount_Prop_Double4-Color[wght,ELXP,ELSH,slnt,SZP1,XPN1,XPN1,SZP2,XPN2,YPN2].ttf
Bitcount_Prop_Single4-Color[wght,ELXP,ELSH,slnt,SZP1,XPN1,XPN1,SZP2,XPN2,YPN2].ttf
I suggest:
BitcountGridDouble[wght,ELXP,ELSH,slnt,SZP1,XPN1,XPN1,SZP2,XPN2,YPN2].ttf
BitcountGridSingle[wght,ELXP,ELSH,slnt,SZP1,XPN1,XPN1,SZP2,XPN2,YPN2].ttf
BitcountMonoDouble[wght,ELXP,ELSH,slnt,SZP1,XPN1,XPN1,SZP2,XPN2,YPN2].ttf
BitcountMonoSingle[wght,ELXP,ELSH,slnt,SZP1,XPN1,XPN1,SZP2,XPN2,YPN2].ttf
BitcountDouble[wght,ELXP,ELSH,slnt,SZP1,XPN1,XPN1,SZP2,XPN2,YPN2].ttf
Bitcount[wght,ELXP,ELSH,slnt,SZP1,XPN1,XPN1,SZP2,XPN2,YPN2].ttf
You can elide any of the fonts too, this is just a structural suggestion. But probably Prop should be Proportional
Closing as Viviana has taken over QA for this project now :)
Please could you update the TTFs in
/vf
(and rename the directory to/fonts
) based on the latest sources, so I can show them to the API engineering team for work on the axes registration process :)