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

New build #3

Closed
davelab6 opened this issue May 26, 2023 · 29 comments
Closed

New build #3

davelab6 opened this issue May 26, 2023 · 29 comments
Assignees

Comments

@davelab6
Copy link
Collaborator

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 :)

@davelab6
Copy link
Collaborator Author

@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

@simoncozens
Copy link
Collaborator

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.

@petrvanblokland
Copy link
Owner

petrvanblokland commented Jun 4, 2023 via email

@davelab6
Copy link
Collaborator Author

@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 :)

@petrvanblokland
Copy link
Owner

petrvanblokland commented Jul 14, 2023 via email

@davelab6
Copy link
Collaborator Author

@petrvanblokland nice :) how are you faring?

@petrvanblokland
Copy link
Owner

petrvanblokland commented Jul 19, 2023 via email

@davelab6
Copy link
Collaborator Author

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?

@petrvanblokland
Copy link
Owner

petrvanblokland commented Jul 19, 2023 via email

@vv-monsalve
Copy link
Collaborator

vv-monsalve commented Jul 26, 2023

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.

Shape of glyphs axes

  • 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

Color axes

  • 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

@davelab6
Copy link
Collaborator Author

davelab6 commented Aug 4, 2023

@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

@petrvanblokland
Copy link
Owner

petrvanblokland commented Aug 4, 2023 via email

@petrvanblokland
Copy link
Owner

petrvanblokland commented Aug 5, 2023 via email

@simoncozens
Copy link
Collaborator

Run "make build"

@petrvanblokland
Copy link
Owner

petrvanblokland commented Aug 7, 2023 via email

@simoncozens
Copy link
Collaborator

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.

@davelab6
Copy link
Collaborator Author

davelab6 commented Sep 26, 2023

I chatted with @vv-monsalve and the latest version from Simon (c04ccfe) 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 :)

@davelab6
Copy link
Collaborator Author

davelab6 commented Sep 26, 2023

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.

@petrvanblokland
Copy link
Owner

petrvanblokland commented Sep 26, 2023 via email

@davelab6
Copy link
Collaborator Author

No, I will try to chase down feedback from our side this week, could be late Friday your time :)

@petrvanblokland
Copy link
Owner

petrvanblokland commented Sep 26, 2023 via email

@davelab6
Copy link
Collaborator Author

great - Vivi and I've emailed Evan now with the latest builds so we hope to get you feedback on those shortly :)

@davelab6
Copy link
Collaborator Author

davelab6 commented Oct 2, 2023

No update from Evan yet, I will follow up with him now

@davelab6
Copy link
Collaborator Author

davelab6 commented Oct 6, 2023

So, we need to finalize the structure of the performant layering, and pin down exactly what axes will be in that version, to proceed :)

@petrvanblokland
Copy link
Owner

petrvanblokland commented Oct 6, 2023 via email

@petrvanblokland
Copy link
Owner

petrvanblokland commented Oct 11, 2023 via email

@davelab6
Copy link
Collaborator Author

Any news about the final naming of the axes?

There are now 4 sets of axes finalized here:

googlefonts/axisregistry#116 (comment)

googlefonts/axisregistry#128 (comment)

googlefonts/axisregistry#113 (comment)

googlefonts/axisregistry#117 (comment)

@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

@davelab6
Copy link
Collaborator Author

davelab6 commented Feb 23, 2024

You can elide any of the fonts too, this is just a structural suggestion. But probably Prop should be Proportional

@davelab6 davelab6 closed this as completed Apr 2, 2024
@davelab6
Copy link
Collaborator Author

davelab6 commented Apr 2, 2024

Closing as Viviana has taken over QA for this project now :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants