Preparing Ysabeau for Google Fonts

[yanone]

Hello,

I'm commissioned to prepare Ysabeau for release on Google Fonts.

There are some aspects of the font which are not following GF specs. I'll start with the most glaring example, which makes Ysabeau unpublishable in its current shape: The weight setup.

You've reused weight classes several times in three instances, but weight classes must be unique, allowing a maximum of 9 instances (from 100 to 900). GF specs also allow weight class 1 and 1000, tho they are currently not yet supported by the API, meaning they will be dropped, but in future updates those could be made available.

See https://googlefonts.github.io/gf-guide/variable.html#wght and https://github.com/googlefonts/axisregistry/blob/main/Lib/axisregistry/data/weight.textproto

Given that you've carefully spaced out the weights across the axis, I'm not sure how to continue.

But tbh, I don't think there's a way around redefining the weights to meet the specs. Any way I look at it, only a maximum of 11 weights are possible for Google Fonts, with only 9 being publishable right away, with the other 2 (1 & 1000) having to wait until they are officially supported (and we shouldn't wait for that)

[CatharsisFonts]

Hi Yanone,

I'm commissioned to prepare Ysabeau for release on Google Fonts.

Great, welcome!

But tbh, I don't think there's a way around redefining the weights to meet the specs.

OK, that's a bummer, but not a showstopper. I'm seeing two main options:

• Redefine the weight axis so as to use only 9 weights.
• Decouple the two lightest weights and offer them as a separate family, «Ysabeau Hairline» (RIBBI). I expect the super dark weights to be more useful for the web than the super light ones, so it wouldn't be much of a change.

A compromise option for the above would be to simply cut the lightest two weights and not publish them on GF. That would leave the GF instances consistent with my GitHub ones. I suppose GF users could still access the Hairline via the Variable Font, right?

Then again, I've always thought that I should have made the «Bold» heavier than it currently is; it's a holdover from when I only had two masters. So even if I get to keep the weight grid as it currently is (in the compromise solution), it might not be bad to come up with a better naming scheme.

Cheers, Christian

[yanone]

So the decision is yours, but here are my opinions, in descending priority:

The weights are spaced out too densely. Few people actually have ever any need for such finely grained weights, and those who really do can use the VF and sliders/precise numerical values. Redefining them and shrinking the amount to 9 is a clean and sensible solution, but it will break compatibility with older documents that use your old setup. You can tell best how big the impact would be to existing users. You can always give it a major version bump (2.0), which in software development signifies a break in compatibility. This change can be communicated transparently to the users. No one is required to use an update.

Skipping over two defined instances but leaving them accessible in the VF through their numeral values is possible, and the cleanest solution if you want to keep full compatibility for at least 9 weights. But keep in mind that you'll likely end up wanting to redefine them anyway, as currently two adjacent weights share the same weight class, one of which you need to remove, so you'll end up with gaps in the weight progression as accessible through named instances. It's those intermediate weights you'd have to skip over and make available indirectly, not the lightest or darkest. So honestly, I don't know how much sense this makes. This feels wrong.

Releasing the two lightest weights as a separate family is very likely not in Google Fonts’ interest, given that GF specifications exist and this font is commissioned (to my knowledge). If you insist I can raise this option with the team for discussion, though.

[CatharsisFonts]

The fine-grained weights make the most sense around the area where you'd want to set text. Light, Regular, and Medium are close to each other, but they make a big difference when setting body copy. I'm not enough of a designer to know whether Light and Medium are still sensible text weights or whether I can give up that triplet.

In any case, it would make sense for (1) the current Regular weight to remain where it is; I believe I tuned it to match the gray value of EB Garamond Regular; (2) the current Bold to remain an instance, though perhaps better called Semibold, simply because it's a master. I suppose we could then toss out one dark and one light weight, or two light weights.

I'm fine with stepping up to v2 and breaking backward compatibility. As I said, I've always wanted to move «Bold» to a heavier instance; this seems like a good opportunity. I have a Legacy folder in the repo where I can put v1 font files for whoever needs them (but technically the older Releases are meant for that).

Cheers, Christian

[yanone]

Cool. Please drop me a hint here when you're done.

[cmahte]

I am a typesetter and drawn to Ysabeau specifically because it has the fine grain in weight. It would be a loss to lose any of the weights. But I'll affirm that the lightest weights generally are for print and maybe light text on dark backgrounds on really huge displays like billboards or the side of buildings. Those special cases, designers can deal with a second font without any issue. Christian's choices for 400, 700 fit right next to EB Garamond (with a slight difference in the exact font size). Having more options in between those is good.

The usefulness of Ysabeau is that it fills a need where a tall sans serif font is needed to contrast against a garamond-tradition serif font. It doesn't need all those weights in any specific use, but it needs those weights to pair against so many different tall fonts that are otherwise alone with no good sans font options.

And with so many weights, it fits right next to EB Garamond, Adobe Garamond, Christian's Cormorant, etc. It's clear to me the weights are carefully considered along these lines and why there are so many... so it fits with many Garamond fonts, and doesn't look to heavy or light mixing sans to serif within a single sentence.

Set some text side by side, maybe 2 paragraphs, and maybe intermixing words. Then zoom out to a few percent above greeking (where the letters disappear) and they should look the same, not noticeably darker or lighter, bigger or smaller. If one or the other looks bigger or lighter, it will distract the reader from the content. So many choices allows for the font to be beautiful when you want to see it, but then disappear completely when you want to read.

Compare Ysabeau as the alternate font against these: where the serif font is main body text. EB Garamond Cormorant Baskerville by ANRT Sorts Mill Goudy by Barry Schwartz Fanwood by Barry Schwartz

Compare Ysabeaus as the main where the serif font is used in titles, sections, numbering, etc. Libre Bodini all of the above.

Ysabeau has the fine grain to fit both Cormorant and EB Garamond weight-wise, so that in a dense paragraph, emphasizing a word can be done differently than listing a title of an article, without it being noticeable, but clear enough that readers intuitively pick up on the difference.

Maybe the split should be to make a font that aligns by weight to Cormorant, then another that aligns by weight to EB Garamond.

On Thu, Dec 1, 2022 at 3:53 AM Christian Thalmann @.***> wrote:

The fine-grained weights make the most sense around the area where you'd want to set text. Light, Regular, and Medium are close to each other, but they make a big difference when setting body copy. I'm not enough of a designer to know whether Light and Medium are still sensible text weights or whether I can give up that triplet.

In any case, it would make sense for (1) the current Regular weight to remain where it is; I believe I tuned it to match the gray value of EB Garamond Regular; (2) the current Bold to remain an instance, though perhaps better called Semibold, simply because it's a master. I suppose we could then toss out one dark and one light weight, or two light weights.

I'm fine with stepping up to v2 and breaking backward compatibility. As I said, I've always wanted to move «Bold» to a heavier instance; this seems like a good opportunity. I have a Legacy folder in the repo where I can put v1 font files for whoever needs them (but technically the older Releases are meant for that).

Cheers, Christian

— Reply to this email directly, view it on GitHub https://github.com/CatharsisFonts/Ysabeau/issues/28#issuecomment-1333501911, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2DE4VZLCVANTFOLNTET3DWLBYRLANCNFSM6AAAAAASPXXYTY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[CatharsisFonts]

Hi @cmahte,

good to hear from you. I'm not a typesetter or designer and can't really judge how useful Ysabeau really is. It's great to hear you find it useful! 😬

Wouldn't the variable font of Ysabeau allow you to match the weight of other fonts, and in a more accurate fashion? It sounds like you could use a vertical metrics axis in addition to the weight axis...

I don't like the idea of matching two versions of Ysabeau to Cormorant and EB Garamond; it sounds like there would be lots of conceptual overlap between the two. At least decoupling the Hairline and Extralight would make some conceptual sense since the Hairline is monolinear whereas all other weights are visibly modulated.

Cheers, Christian

[tphinney]

Building different versions of Ysabeau feels like overkill to me. Seems to me that one could just have a single variable font, and make available info on which weights one would use to map best to different weights of Cormorant or EB Garamond. This is a general question of weight mapping across fonts, and if one wants to do it really well, then a variable font + different choices depending on what you are matching it with, are normal.

[cmahte]

I started with that, and will be happy if that's the way Ysabeau is released.

On Sun, Dec 4, 2022 at 3:39 PM Christian Thalmann @.***> wrote:

Hi Michael,

good to hear from you. I'm not a typesetter or designer and can't really judge how useful Ysabeau really is. It's great to hear you find it useful! 😬 Wouldn't the variable font of Ysabeau allow you to match the weight of other fonts, and in a more accurate fashion? It sounds like you could use a vertical metrics axis in addition to the weight axis... I don't like the idea of matching two versions of Ysabeau to Cormorant and EB Garamond; it sounds like there would be lots of conceptual overlap between the two. At least decoupling the Hairline and Extralight would make some conceptual sense since the Hairline is monolinear whereas all other weights are visibly modulated.

Cheers, Christian

— Reply to this email directly, view it on GitHub https://github.com/CatharsisFonts/Ysabeau/issues/28#issuecomment-1336523704, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2DE4SIL62LKNVJHJ3IQB3WLUFQPANCNFSM6AAAAAASPXXYTY . You are receiving this because you commented.Message ID: @.***>

[CatharsisFonts]

It looks to me like the best choice is to keep the current full spectrum of weights for (1) the variable font and (2) the instanced desktop fonts in the repo, and (3) to trim away the bottom two weights for the Google Fonts webfonts. It does seem a bit overkill to publish those two Hairline weights separately; I wouldn't mind if they were available in the VF only.

I probably also should resist the urge to rename the Bold weight if it currently matches EB Garamond's Bold.

@davelab6, is that in keeping with your commission?

[davelab6]

@yanone

allowing a maximum of 9 instances (from 100 to 900

Well, the allowable range is 1 to 1,000, but only 9 weights 100 to 900 will be accessible in Workspace apps.

I filed https://github.com/googlefonts/axisregistry/issues/103 to discuss how to handle weight 1..99 and 901..1000, but, it may be useful to solve this by using the full axis range.

Releasing the two lightest weights as a separate family is very likely not in Google Fonts’ interest, given that GF specifications exist and this font is commissioned (to my knowledge). If you insist I can raise this option with the team for discussion, though.

yes, this was commissioned; for me though, releasing the two lightest weights as a separate family is indeed not in Google Fonts’ interest, because we want to reduce the # of families and use the full range of OpenType technology - axes and features - to provide powerful typography tools based on standards.

@cmahte

It would be a loss to lose any of the weights

I agree, and that's not on the table - you should always be able to access all the weights via the Weight axis. this discussion is really only about the named styles and how to handle them. Your feedback about the cultural context of the named styles, such that this family's bold matches others it will commonly be paired with, is valuable! :) Thanks

[CatharsisFonts]

@davelab6

but, it may be useful to solve this by using the full axis range.

Do you mean by assigning the Hairline to 1 and the Black to 1000? If this means making the Black inaccessible to some usages, that would be unfortunate. I consider the Black one of the more useful instances. Would it be possible to assign the two lightest weights to 1 and 50, respectively?

[davelab6]

Yes

[CatharsisFonts]

@yanone

Great, then let’s go with the 1, 50, … variant!

Cheers, Christian

[CatharsisFonts]

Dear @yanone, dear @davelab6,

I've changed the weight classes as discussed. There are 12 instances per cut, though, so I assigned the heaviest 9 instances to 100–900 and called the lighest 3 instances 1, 25, and 50. I think that's preferable over losing access to the Black. Unfortunately, the Regular and Bold weights no longer match up to weight classes 400 and 700 now, but I suppose that's just a technicality.

Are we ready to proceed?

Happy new year! Cheers, Christian

[yanone]

Hi Christian,

I've reviewed your changes and I'm sorry to say that we're not quite there yet.

The weight classes as shown in https://googlefonts.github.io/gf-guide/variable.html#wght are not negotiable, certainly not for the Regular and Bold. Defining weights in CSS heavily depends on numeric weight values. We need the fonts to deliver the expected results for (at the very least) weights 400 and 700, ideally for all of them.

Before I suggest to remove and redefine weights, I'll play the ball back to you one more time to see if you can find a way to handle your weights that meet the specifications.

Thanks, Yanone

[CatharsisFonts]

Hey,

sorry, I'm currently swamped in dayjob work...

Here's Ysabeau interspersed in EB Garamond:

And in Cormorant Garamond:

The size difference that @cmahte mentioned is pretty noticeable; the line height increases when I change a word to Ysabeau. As for weight, EB Garamond Regular feels closer to Ysabeau Medium than Ysabeau Regular to me, and for Cormorand Garamond Regular, Ysabeau Semilight is the better match. EB Garamond Bold is heavier than Ysabeau Bold, which aligns with my urge to shift Ysabeau Bold upwards. Cormorant Garamond Bold is much lighter than the current Ysabeau Bold and fits pretty well onto Ysabeau Semibold.

In conclusion, I don't think the current weight definitions of Ysabeau are perfect matches to those other typefaces, so it might be worth it to redefine the scale rather than to kick out individual weights and leave gaps in the process.

Is there anything we can do about the size difference, short of rescaling the outlines (which would mess up the Hairline)? Maybe change the UPM? I suppose changing the vertical metric parameters would work as well, but then some Vietnamese accents might get cut off.

Cheers, Christian

[tphinney]

Changing vertical metric parameters, other than UPM, would not affect the scaling of the font.

[cmahte]

For what it's worth, I match any fonts to the visual grid.

For EB Garamond vs Ysabeau EB Garamond is about 8% difference in size. That is I shrink EB Garamond to 96% then further scale the width 93.1% so that the glyphs follow Ysabeau more closely. And also note that LibreOffice doesn't support variable fonts (as far as I know... i'm currently re-coding my stylesheet generator to libreoffice 7.4 and haven't explored opentype yet.) Those are 'weights' embedded into the static fonts for each face.

This chart is for LibreOffice writer, which does not have a scale X and scale Y but does have a Scale X and "shrink" for ordinals.

And the reference grid is Cormorant. So the numbers are what it takes to get EBGaramond to basically overlay Cormorant... and then Cormorant matches Ysabeau. However... since LibreOffice only has 'Shrink', I have to adjust the scaling to the font that fills in the most so the largest is 100" and other values get smaller. It's quite a convoluted way to match fonts, but once they are... typesets do look well designed.

BUT, If someone reading this can follow... Typesetters everywhere would LOVE scalar components in opentype that allow for what in inDesign is "scale X" and "scale Y" (50%-200%), so 1=1 between fonts when setting stylesheets.

EBGaramond/Ysabeau 2010A c

Class Style Font Face ScaleX Shrink Skew Weight Body Black Serif EB Garamond ExtraBold Regular 93.1 96 normal 800 Body Black Serif Italic EB Garamond ExtraBold Italic 92.2 96 italic 800 Body Bold Serif EB Garamond Bold 93.1 96 normal 700 Body Bold Serif Italic EB Garamond Bold Italic 93.1 96 italic 700 Body Book Serif EB Garamond Regular 98.9 96 normal 400 Body Book Serif Italic EB Garamond Italic 98.9 96 italic 400 Body Heavy Serif EB Garamond ExtraBold Regular 93.1 96 normal 800 Body Heavy Serif Italic EB Garamond ExtraBold Italic 92.2 96 italic 800 Body Light Serif Cormorant Garamond Regular 100 100 normal 400 Body Light Serif Italic Cormorant Garamond Italic 100 100 italic 400 Body Medium Serif EB Garamond Medium Regular 97 96 normal 500 Body Medium Serif Italic EB Garamond Medium Italic 97 96 italic 500 Body Semibold Serif EB Garamond SemiBold Regular 95 96 normal 600 Body Semibold Serif Italic EB Garamond SemiBold Italic 95 96 italic 600 Body Space after Verse EB Garamond Regular 48 96 normal 400 Body Thin Serif Cormorant Garamond Light Regular 100 100 normal 300 Body Thin Serif Italic Cormorant Garamond Light Italic 100 100 italic 300 Caption Caption Bold EB Garamond 08 Bold 102 100 normal 700 Caption Caption Bold Italic EB Garamond ExtraBold Italic 90.2 96 italic 700 Caption Caption Italics EB Garamond 08 Italic 102 100 italic 400 Caption Caption Sans Bold Lato Bold 90.9 90 normal 700 Caption Caption Sans Bold Italic Lato Bold Italic 94.5 90 italic 700 Caption Caption Sans Italics Lato Italic 94.5 90 italic 400 Caption Caption Sans Text Lato Regular 90.9 90 normal 400 Caption Caption Text EB Garamond 08 Regular 102 100 normal 400 Sans Black Sans Ysabeau Black Bold 100 100 normal 900 Sans Black Sans Italic Ysabeau Black Bold 100 100 italic 900 Sans Bold Sans Ysabeau Bold 100 100 normal 700 Sans Bold Sans Italic Ysabeau Bold Italic 100 100 italic 700 Sans Book Sans Ysabeau Regular 100 100 normal 400 Sans Book Sans Italic Ysabeau Italic 100 100 italic 400 Sans Heavy Sans Ysabeau Ultrabold Regular 100 100 normal 800 Sans Heavy Sans Italic Ysabeau Bold Italic 100 100 italic bold Sans Light Sans Ysabeau Light Regular 100 100 normal 300 Sans Light Sans Italic Ysabeau Light Italic 100 100 italic 300 Sans Medium Sans Ysabeau Medium Regular 100 100 normal 500 Sans Medium Sans Italic Ysabeau Medium Italic 100 100 italic 500 Sans Semibold Sans Ysabeau Semibold Regular 100 100 normal 600 Sans Semibold Sans Italic Ysabeau Semibold Italic 100 100 italic 600 Sans Thin Sans Ysabeau Hairline Normal 100 100 normal 100 Sans Thin Sans Italic Ysabeau Hairline Italic 100 100 italic 100 Title Black Title Ysabeau Black Bold 100 100 normal 900 Title Black Title Italic Ysabeau Black Bold 100 100 italic 900 Title Bold Title Ysabeau Bold 100 100 normal 700 Title Bold Title Italic Ysabeau Bold Italic 100 100 italic 700 Title Heavy Title Ysabeau Ultrabold Regular 100 100 normal 800 Title Heavy Title Italic Ysabeau Bold Italic 100 100 italic bold Title Light Title Ysabeau Light Regular 100 100 normal 300 Title Light Title Italic Ysabeau Light Italic 100 100 italic 300 Title Medium Title Ysabeau Medium Regular 100 100 normal 500 Title Medium Title Italic Ysabeau Medium Italic 100 100 italic 500 Title Regular Title Ysabeau Regular 100 100 normal 400 Title Regular Title Italic Ysabeau Italic 100 100 italic 400 Title Semibold Title Ysabeau Semibold Regular 100 100 normal 600 Title Semibold Title Italic Ysabeau Semibold Italic 100 100 italic 600 Title Thin Title Ysabeau Hairline Normal 100 100 normal 100 Title Thin Title Italics Ysabeau Hairline Italic 100 100 italic 100 Verse Bold Pen Almendra Bold 92 93 normal 700 Verse Bold Pen Cursive Almendra Bold Italic 96 93 italic 700 Verse Light Pen Almendra Display Regular 93 89 normal bold Verse Light Pen Cursive Almendra Display Regular 93 89 italic bold Verse Medium Pen Almendra Regular 98 93 normal 400 Verse Medium Pen Cursive Almendra Italic 105 93 italic 400

On Sat, Jan 21, 2023 at 4:59 PM Christian Thalmann @.***> wrote:

Hey,

sorry, I'm currently swamped in dayjob work...

Here's Ysabeau interspersed in EB Garamond: [image: Screenshot 2023-01-21 at 23 22 44] https://user-images.githubusercontent.com/13754106/213889338-8bcebcf6-9f55-4907-9a66-8fe52a717835.png

[image: Screenshot 2023-01-21 at 23 23 48] https://user-images.githubusercontent.com/13754106/213889343-1b93c78b-9043-4c2c-80a9-6eb86d39d142.png

And in Cormorant Garamond: [image: Screenshot 2023-01-21 at 23 24 51] https://user-images.githubusercontent.com/13754106/213889388-26785fd6-c503-4add-a5d7-33f658abac93.png

[image: Screenshot 2023-01-21 at 23 25 29] https://user-images.githubusercontent.com/13754106/213889391-9dc43a90-0e1c-48d7-b272-11b1385f2b4c.png

The size difference that @cmahte https://github.com/cmahte mentioned is pretty noticeable; the line height increases when I change a word to Ysabeau. As for weight, EB Garamond Regular feels closer to Ysabeau Medium than Ysabeau Regular to me, and for Cormorand Garamond Regular, Ysabeau Semilight is the better match. EB Garamond Bold is heavier than Ysabeau Bold, which aligns with my urge to shift Ysabeau Bold upwards. Cormorant Garamond Bold is much lighter than the current Ysabeau Bold and fits pretty well onto Ysabeau Semibold.

In conclusion, I don't think the current weight definitions of Ysabeau are perfect matches to those other typefaces, so it might be worth it to redefine the scale rather than to kick out individual weights and leave gaps in the process.

Is there anything we can do about the size difference, short of rescaling the outlines (which would mess up the Hairline)? Maybe change the UPM? I suppose changing the vertical metric parameters would work as well, but then some Vietnamese accents might get cut off.

Cheers, Christian

— Reply to this email directly, view it on GitHub https://github.com/CatharsisFonts/Ysabeau/issues/28#issuecomment-1399349357, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2DE4QW4LKFAVQFILDME5DWTRS33ANCNFSM6AAAAAASPXXYTY . You are receiving this because you were mentioned.Message ID: @.***>

[CatharsisFonts]

What's the visual grid?

[cmahte]

Grid is a way of saying "be able to change the font mid-sentence without slapping the reader in the face with suddenly different specs..." Font changes are supposed to communicate something like a title or emphasis. They get ugly if words suddenly take more or less room. Pro fonts usually come with a full set of serif and sans that have this all ready-made. But in the world of free, just slapping a sans and serif together doesn't work, so most typography on free fonts only uses 1 font per paragraph. I reduce the problem by calibrating. (reduce, not solve.... )

For height, I consider mostly the x-height. The ascender and descender have to be close or the fonts don't belong together. but if the ascenders/descenders aren't exactly the same but close "matching" isn't exactly the x-height, but it's the biggest factor. This means force the x-height in both font's to the same exact size by adjusting the "shrink" for the font that isn't Cormorant.

For width, I consider all of the letters (a-z, A-Z, 0-9 and punctuation) but calibrate the width to 10 Capital X glyphs. That is, force XXXXXXXXXX to be the same width at the same font size by adjusting the none Cormorant font in X) But after calibrating X... the whole alphabet should have the same width and if it doesn't I figure out why. And if it's a letter that will be prominent in the composition, I adjust. If its W or J... Oh well it isn't perfect.

On Sat, Jan 21, 2023 at 6:34 PM Christian Thalmann @.***> wrote:

What's the visual grid?

— Reply to this email directly, view it on GitHub https://github.com/CatharsisFonts/Ysabeau/issues/28#issuecomment-1399366496, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2DE4X6G6FUEUVZMTM76MDWTR6C7ANCNFSM6AAAAAASPXXYTY . You are receiving this because you were mentioned.Message ID: @.***>

[CatharsisFonts]

Hi @yanone

I noticed the link you listed includes the weight 1000 ExtraBlack... so then I could stuff the two lightest weights into 1 and 50 and the heaviest weight (currently called «Black») into ExtraBlack. Presumably that would remove the latter from use in contexts where only weights 100–900 are allowed, but if I understand correctly, that's going to be fixed in the long run...?

In any case, that would keep the current Regular and Bold at 400 and 700, respectively, and we could be done with it. If anyone wants to use the blackest weight reliably, I suppose they'll just have to use the variable font.

What do yo think?

Cheers, Christian

[CatharsisFonts]

Implemented that in the newest commit (v2.000).

[yanone]

What do yo think?

I think that sounds good. Will take a look soon

[yanone]

The weight setup looks good as far as I can tell. Thank you.

I would now make a few changes myself in order to create VFs that are suitable for Google Fonts and send you a PR with those changes. At first I'll put those into a separate folder (not overwriting your VFs), and you can later choose to keep either one.

If possible, try to refrain from making changes to the sources yourself until my PR is ready to avoid data conflicts. Should not take long.

[CatharsisFonts]

Sounds good!

Do you think the vertical metrics need some tuning? I don't have the technical background to judge.

[yanone]

I'll take a look. That's part of my work.

[yanone]

Okay, I sent you a PR.

After you've merged it, please review DESCRIPTION.en_us.html. I added a stub from the README, but maybe you could elaborate a bit? (max 2000 characters in total incl. HTML) Please refrain from adding references to you as a designer or your foundry. Those will be found on fonts.google.com underneath the info text as part of the designer info already.

I noticed that even though you already have fonts on GF that you don't actually have a bio yet. Please fill this form for it. Thank you.

[Bronnel721]

@yanone, there are some problems with some of the Vietnamese accents in your build of Ysabeau. https://user-images.githubusercontent.com/92538982/222871413-5244fdad-98eb-445a-b750-f5875413ceaa.mp4 https://user-images.githubusercontent.com/92538982/222871414-fa61512a-0aed-4693-8788-13d76b4d4645.mp4

[CatharsisFonts]

Hi @yanone,

sorry for the delay; Life happened.

I expanded the description a bit; does that work? Is it OK to use some HTML formating?

I also filled in the bio.

Cheers, Christian

[yanone]

@Sayhone721 @CatharsisFonts I’m investigating the accent misalignment. It appears like it’s a fault in the production toolchain, most likely glyphsLib. Will report back.

[yanone]

@Sayhone721 @CatharsisFonts The issue lies with an outdated version of ufo2ft that I used to generate the previous binaries. The issue is solved in the latest version. I generated new fonts and ask to please merge them: https://github.com/CatharsisFonts/Ysabeau/pull/31 Thank you

[CatharsisFonts]

@yanone, I can no longer export Ysabeau with Glyphs because the custom parameter changing the family name for the spin-off instances is no longer there. Did you delete those as part of your work, or did that come from somewhere else? (Such as a cutting-edge Glyphs version?)

BTW, I'm too dumb to figure out how to browse older commits for a file to search for the change...

EDIT: I did figure it out. Apparently the change appeared during your recent work. Would you mind if I added the «local family name» info back into the instances?

[yanone]

I did that, but I'm not 100% sure that it was truly necessary. And anyways I wanted to add them back after I was done and forgot. My apologies.

The reason was that Google Fonts can't deal with any of those instances and will only onboard the first set of standard instances. But since I didn't deactivate the other instances, I'm not sure whether deleting their family names was even any good idea.

Please do add them back. If we ever need to publish an update of Ysabeau, we'll have to look at this topic again. It's possible that we may need to introduce a build script that separates the wanted from the unwanted instances in either a pre or post-build stage to make the font conform to GF specs while at the same time allowing you to generate it in whichever way you like. We've done that before.

[CatharsisFonts]

OK, done!

[yanone]

Hi Christian,

Google Fonts has been struggling with the 3 extra sets that you've defined. Despite similar sets already being out for Cormorant, we've been debating how to produce them practically, since we don't want to generate fonts with Glyphs for quality reasons.

I've dug out and adapted an old script that uses a tool called pyftfeatfreeze to freeze the features, and I want to ask you to analyze the fonts, to what extent they follow your intention. The tools don't follow the same approach as you do in Glyphs where you remove features and rename glyphs. Instead, it reads the feature code and applies the substitutions as they are defined in the features. So it's possible that there are some differences between the two approaches, and while I'm confident, I think you as the author should see whether the new fonts are legit.

Please find them in my fork at https://github.com/yanone/Ysabeau/tree/master/fonts/googlefonts/variable

Thank you

[CatharsisFonts]

Hi @yanone,

I tried to open the fonts in both Axis-Praxis and the Dinamo Font Gauntlet, and failed in both cases. Is there a better way, or does that mean the fonts are broken?

I'd think it's less crucial for Ysabeau to have spin-off fonts than it is for Cormorant, since I consider Cormorant Garamond the main cut of the family whereas in Ysabeau it's the default cut. But I suspect users might be less inclined to use small caps if they have to use OT features to access them.

Cheers, Christian

[yanone]

Hi @yanone,

I tried to open the fonts in both Axis-Praxis and the Dinamo Font Gauntlet, and failed in both cases. Is there a better way, or does that mean the fonts are broken?

Yeah, I get the same problem when I download the fonts from the Github link I sent you. Weird. Try these instead: Archiv.zip

I'd think it's less crucial for Ysabeau to have spin-off fonts than it is for Cormorant, since I consider Cormorant Garamond the main cut of the family whereas in Ysabeau it's the default cut. But I suspect users might be less inclined to use small caps if they have to use OT features to access them.

The Google Fonts API currently doesn't expose Small Caps, Stylistic Sets etc to the users. In other words, they get dropped. Including those features is unfortunately a low-priority task for them and isn't likely to arrive before a few years. Until then, we need to publish spin-off sets.

[CatharsisFonts]

Yeah, I get the same problem when I download the fonts from the Github link I sent you. Weird. Try these instead: Archiv.zip

Those work! I'll give them a look.

BTW, I noticed the stylistic sets are not numbered consecutively. That's because I based them off stylistic sets of Cormorant. Should I rename them?

The Google Fonts API currently doesn't expose Small Caps, Stylistic Sets etc to the users. In other words, they get dropped. Including those features is unfortunately a low-priority task for them and isn't likely to arrive before a few years. Until then, we need to publish spin-off sets.

No small caps? In that case, the spin-offs are absolutely crucial...

[yanone]

BTW, I noticed the stylistic sets are not numbered consecutively. That's because I based them off stylistic sets of Cormorant. Should I rename them?

I don't think anyone has an opinion on that really, since they're currently getting stripped of the fonts being served on Google Fonts. Please decide that on your own. Since they are separate families, there is no need to keep them in sync, that's my 2 cents.

[CatharsisFonts]

Hi @yanone,

hope everything's going well on your side...

I tried out the Ysabeau VF on Axis-Praxis and found the following bug:

I was trying out the stylistic alternates of /Q/ (which work as intended!) when I discovered that /Q/i/ will be rendered as overlapping, as if the spacing were off on /Q/. This is not the case in my own version of Ysabeau. Note that no stylistic alternate of /Q/ is used before /i/.

EDIT: The /i/ is not to blame. When sliding the weight from Hairline to Bold, the /Q/ loses about half its advance width and then regains it. I suspect it has to do with /Q/ being made of two components. I tried the /f_f_l/ ligature and found the same behavior, which supports this theory.

Can you fix it?

Cheers, Christian

[yanone]

I’m out of office until May 2nd because of moving apartments. I can look at it then if it's not too late.

[yanone]

I looked at this and can't see what you see.

Could you please clarify which file and combination of OT features (if any) you used? I'm looking at the files of the zip archive I posted further up in this thread.

[kenmcd]

BTW, I noticed the stylistic sets are not numbered consecutively. That's because I based them off stylistic sets of Cormorant. Should I rename them?

At a minimum, they should be the same in the families Regular/Italic. I have been documenting how different fonts localize for Bulgarian, and noticed you also included the same BGR alternates in the stylistic sets. Roman uses ss11 Italic uses ss10 So if a user was using ss11 on some text, and clicked the italic button, that text is no longer going to be Bulgarian alternates.

There may be some other situations like that so you may want to consider making them all the same.

[CatharsisFonts]

Actually, Bulgarian is SS10 in both styles. Roman also had SS11 for the Frankfurt-style Eszett. I've added that to the Italic as well now for consistency.

[CatharsisFonts]

@yanone

I looked at this and can't see what you see.

Could you please clarify which file and combination of OT features (if any) you used? I'm looking at the files of the zip archive I posted further up in this thread.

Apparently this happens with the VFs in the fonts/vf/ directory on GitHub, but not with the ones in your ZIP-file. Phew! Sorry for the confusion.

[kenmcd]

Actually, Bulgarian is SS10 in both styles. Roman also had SS11 for the Frankfurt-style Eszett. I've added that to the Italic as well now for consistency.

In looking again it is ss10 in both. Guess I had a brain fart. Was looking at the variable fonts from the ZIP above. Have got 28 fonts open at once working on this. Guess I need to take a break. Sorry for the confusion.

[CatharsisFonts]

Hey, apparently Ysabeau got uploaded! Yay! 😬

Though it doesn't seem to work for everyone yet, see issue.

Thanks for your work!

Cheers, Christian

[CatharsisFonts]

Hi @yanone, so did you decide to upload the base font before the spin-offs were ready? Will they be added in a later wave? Cheers, Christian

[yanone]

Errm, so, I’m not completely sure why Ysabeau is online and why the others are left behind, as I've been through some life hectic the last couple of weeks. But I'll try like this: I think I was still waiting for your assessment of the spin-off files that I asked for (I checked this thread), while the normal Ysabeau got onboarded in the meantime because I didn't put a hold on it.

[CatharsisFonts]

Heh, yeah, that would explain it. I'm also in the middle of some hectic time over here, preparing to move appartments and for my classes' upcoming matura exams. As a result, I haven't had time to go over the spin-off fonts with a fine comb, and won't have the time for at least another month.

Superficially, though, the fonts look good to me. I propose you onboard them, and if there are any hidden problems, we'll fix them quickly.

Cheers, Christian