Preparing Ysabeau for Google Fonts #28
Comments
|
Hi Yanone,
Great, welcome!
OK, that's a bummer, but not a showstopper. I'm seeing two main options:
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 |
|
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. |
|
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 |
|
Cool. Please drop me a hint here when you're done. |
|
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
<#28 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC2DE4VZLCVANTFOLNTET3DWLBYRLANCNFSM6AAAAAASPXXYTY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
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 |
|
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. |
|
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
<#28 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC2DE4SIL62LKNVJHJ3IQB3WLUFQPANCNFSM6AAAAAASPXXYTY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
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? |
Well, the allowable range is 1 to 1,000, but only 9 weights 100 to 900 will be accessible in Workspace apps. I filed googlefonts/axisregistry#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.
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.
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 |
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? |
|
Yes |
|
Great, then let’s go with the 1, 50, … variant! Cheers, Christian |
|
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 |
|
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, |
|
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 |
|
Changing vertical metric parameters, other than UPM, would not affect the scaling of the font. |
|
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
<#28 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC2DE4QW4LKFAVQFILDME5DWTRS33ANCNFSM6AAAAAASPXXYTY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
What's the visual grid? |
|
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
<#28 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC2DE4X6G6FUEUVZMTM76MDWTR6C7ANCNFSM6AAAAAASPXXYTY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
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 |
|
Implemented that in the newest commit (v2.000). |
I think that sounds good. Will take a look soon |
|
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. |
|
Sounds good! Do you think the vertical metrics need some tuning? I don't have the technical background to judge. |
|
I'll take a look. That's part of my work. |
|
Okay, I sent you a PR. After you've merged it, please review DESCRIPTION.en_us.html. 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. |
|
@yanone, there are some problems with some of the Vietnamese accents in your build of Ysabeau. |
|
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 |
|
@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. |
|
@Sayhone721 @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? |
|
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. |
|
OK, done! |
|
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 Please find them in my fork at https://github.com/yanone/Ysabeau/tree/master/fonts/googlefonts/variable Thank you |
|
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 |
Yeah, I get the same problem when I download the fonts from the Github link I sent you. Weird. Try these instead:
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. |
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?
No small caps? In that case, the spin-offs are absolutely crucial... |
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. |
|
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 |
|
I’m out of office until May 2nd because of moving apartments. I can look at it then if it's not too late. |
|
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? |
At a minimum, they should be the same in the families Regular/Italic. There may be some other situations like that so you may want to consider making them all the same. |
|
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. |
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. |
In looking again it is |
|
Hey, apparently Ysabeau got uploaded! Yay! 😬 Though it doesn't seem to work for everyone yet, see issue. Thanks for your work! Cheers, Christian |
|
Hi @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. |
|
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 |
|
Congratulations on getting your beautiful typeface onto google fonts! 🎉 |
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)
The text was updated successfully, but these errors were encountered: