Font not ready yet for GF

[emmamarichal]

Hello @romashamin !

I noticed that there were some missing glyphs in the fonts, like: hungarumlautcomb caroncomb.alt commaturnedabovecomb commaaccentcomb ogonekcomb

I generated the missing glyphs in the source file. I put in pink those generated automatically (automatic alignment), and in yellow those that require design work. Please keep the instance names, the axis mapping and the config.yaml as they are, I had started to prepare all this for export, it is not finished yet. (there is a back up file in my repo, so you can merge this safely)

For the Lcaron, dcaron, lcaron and tcaron, the caron.alt is necessary because it is a different design.

So if you can complete the glyphset, it would be great, then I'll export the fonts :) Thanks a lot!

Cheers, Emma

[romashamin]

Hi @emmamarichal! 🙂

Thank you for your work! I will add the necessary glyphs asap.

However, I’m not sure about new instances’ names.

First, it broke the compatibility with the main font of the family: Martian Grotesk. Both fonts share this naming convention.

Second, Glyphs’ Naming guide recommends keeping names short.

Martian Mono sWd xBd becomes Martian Mono Semi Expanded Extra Bold. After I add italics it will become much longer: Martian Mono Semi Expanded Extra Bold Oblique. Wouldn’t that produce compatibility problems?

Also, with the current naming convention users have concise grouping in design software, like this. If we rename instances it might be harder to work with a big family like Martian.

And, I’m afraid Extra Bold is too heavy to work as Bold. Not sure we can just rename it.

What do you think? Is it possible to keep naming as is?

[romashamin]

Also, I used Axis Mappings on the font’s level before, and changed it to Axis Location on every instance upon the advice of Greg Seifert.

[emmamarichal]

I completely understand the problem this could cause you.

However, I had to follow the Google Fonts specs for instance names, axis mapping etc.. We are obliged to follow a very strict scheme. https://googlefonts.github.io/gf-guide/variable.html#fvar-instances

But I'll look into it anyway, to see how to handle the problem of a too long name with italic. That gives you time to draw the missing glyphs. I'll come back to you if I find a solution :)

[emmamarichal]

Also, I haven't done it here yet, but we will have to add the SemiBold instance (600) to respect the google specs

[emmamarichal]

I think that for the statics, we will have more freedom, but for the variable, we must respect these names and number of instance

[emmamarichal]

@romashamin I checked: the variable fonts should follow the scheme I started to set up in the file. Moreover, with a width axis, there will be only the "normal" styles in the menu. To vary the width, you will have to use the slider. (see the example of DynaPuff on the screenshots).

We'll only be onboarding the variable in any case, so what you can do is export the statics as you wish, and users will have access to them via your repo (there will be the link to your repo on the GoogleFonts sample page).

I'm sorry if this doesn't meet your expectations, but Google Fonts has some specific constraints that can't be overridden. Would you be ok to onboard the font according to these specs?

[romashamin]

@emmamarichal yes, I wasn’t ready for such significant changes 😔

Don’t get me wrong, I’m ready to fit all the QA requirements and provide data and images, but renaming instances, adding instances, and remapping axes... I don’t know.

I mean all these things are my conscious design decisions. They’re part of the design and were made for a purpose.

Since the font is used in production, I don’t think I can afford to maintain a dedicated version for GF.

I’d like to take a pause till tomorrow, if you don’t mind. Maybe I’ll figure out how to handle this situation.

[emmamarichal]

@romashamin Yes no problem, I totally understand your point of view. This is my last week before my vacation, we can discuss this again in September with Rosalie who is more competent than me, maybe we will find a solution (and I hope!) :)

[romashamin]

Maybe I can tweak a little bit stem distribution pattern for the whole family like this:

It’s a sort of tradeoff. Users can say “Hey, the difference between Medium and Semi Bold, Semi Bold and Bold is barely noticeable!” However it definitely can solve the issue with coordinate 600.

I will experiment with this.

[emmamarichal]

Yes of course, you are free to choose the values you want to find the right balance!

[davelab6]

The style names are mandated in the OpenType TTF spec and in the Google Fonts API system internals follow that spec. What you are doing is the CFF (.otf) style of naming which is arbitrary and keyed off the PSName being unique only, which is what Adobe design apps use and therefore what designers tend to assume is correct.

Sadly, if you don't align your ttfs with how the gf system will process them, then the result will be that the copies users obtain from Google will follow the spec and be incompatible with documents made using copies obtained from you.

[romashamin]

Hi there,

The good news: it’s possible to set up two sets of export instances in one Glyphs file. This means I can support two naming conventions.

Horray! 🎉

I made a test version of the font with the new naming convention. In it,

• I set up an additional SemiBold width point (see the Stem Weight Distribution image above).
• Added Localized Family Names parameter in all instances, except the Standard (Medium width class)—all just like Emma did.

I will show the source file later. Could you please take a look at the result variable font?

MartianMono[wdth,wght].ttf.zip

I tested it in Dinamo Font Gauntlet and Adobe Illustrator and noticed that now the list of preset styles looks like this:

Is it an expected behavior?

[romashamin]

Hi @davelab6 and @emmamarichal,

I hope you’re doing well.

I’ve added all the needed Latin glyphs. Here’s the current character set of the Martian Mono 0.9.2:

AÁĂǍÂÄÀĀĄÅǺÃÆǼBCĆČÇĊDÐĎĐḌEÉĚÊËĖÈĒĘẼƏFGĞǦĢĠHĦḤIIJÍÎÏİỊÌĪĮĨJKĶLĹĽĻĿŁMNŃŇŅƝÑŊOÓÔÖỌÒŐŌØǾÕŒPÞQRŔŘŖSŚꞋŠŞȘṢẞTŦŤŢȚṬUÚŬÛÜỤÙŰŪŲŮŨVWẂŴẄẀXYÝŶŸỲȲỸZŹŽŻẒaáăǎâäàāąåǻãæǽbcćčçċdðďđḍeéěêëėèēęẽəfgğǧģġhħḥiıíîïịìijīįĩjȷkķĸlĺľļŀłmnńňņɲñŋoóôöọòőōøǿõœpþqrŕřŗsśꞌšşșṣßtŧťţțṭuúŭûüụùűūųůũvwẃŵẅẁxyýŷÿỳȳỹzźžżẓªº0123456789⁄½¼¾₀₁₂₃₄₅₆₇₈₉⁰¹²³⁴⁵⁶⁷⁸⁹.,:;…!¡?¿·•*#/\-­–—‑_(){}[]‚„“”‘’«»‹›"'ƒ@&¶§©®™°|¦†‡№¢¤$€₽£¥+−×÷=≠><±≈~¬^µ%‰↑→↓←

Also, as I mentioned earlier, I set up the second set of instances with different naming.

All that remains to do is to set up the naming correctly. Please, see my message above.

[emmamarichal]

Hello @romashamin! Yes indeed, we can set up some other instances and deactivate them to export what we want. So it should work! I'll set up that today and next week. Thanks also for completing the glyphset!

[emmamarichal]

Just opened the file, the problem is that we have to have the same names of the masters as the instances, and this has to respect this naming:

• Condensed Thin
• Condensed Regular
• Condensed ExtraBold
• SemiExpanded Thin
• SemiExpanded Regular
• SemiExpanded ExtraBold

Would you be ok?

Also, I saw some Rename Glyphs, and unfortunately, fontmake doesn't export them yet. But I can solve this problem with special layers, we usually do that.

[romashamin]

Hey @emmamarichal,

Thank you for the quick respond.

the problem is that we have to have the same names of the masters as the instances

Hm, I’ve asked about this on Glyphs forum earlier. It seems that master names do not make any difference to the exports.

Also, I saw some Rename Glyphs, and unfortunately, fontmake doesn't export them yet. But I can solve this problem with special layers, we usually do that.

Do you mean “bracket layers” solution? I started with it, and, after I faced problems with it, I switched to the current solution.

Let me try it on my own first—I have to recall what went wrong back then.

[emmamarichal]

@romashamin

I'm pretty sure we can't have different names for masters. Because for example, when we set the "variable font origin", it's linked to the masters that are linked to the instances, so we need a coherence.

Do you mean “bracket layers” solution? I started with it, and, after I faced problems with it, I switched to the current solution. Let me try it on my own first—I have to recall what went wrong back then.

Yes Alternate Layers. For the dollar and the cent, it shouldn’t be a problem, that’s how other fonts that use alternatives work. I’ll do it if you want, it doesn’t take too long 👌

[romashamin]

Okay then 😊

If I can’t rename my masters, we can’t avoid splitting the source file into two versions, right?

Let’s talk about this option then. How can splitting work?

You make a new PR, where:

• You clone the Martian Mono.glyphs to the same folder (?) and rename it to MartianMonoGF.glyphs (I remember you deleted the space in the file name).
• In this MartianMonoGF.glyphs, you apply all the masters renaming and Alternate Layers changes. Also, switch to the second set of instances.

In the future:

• I deliver version 0.9.3, where all the new changes are applied to the original Martian Mono.glyphs.
• You or someone else from GF team makes a PR where they repeat masters renaming and switching to the second set of instances.

Doesn’t seem very efficient to me, but is there another way?

Also, if your setup for Alternate Layers works, I’ll apply it to the original Martian Mono.glyphs to help with cutting the future repetitive work.

@emmamarichal what do you think? Does this plan work for you and Google fonts?

[emmamarichal]

Yes I think it's the best thing we can do if you need to keep your own version. It's not a problem to have 2 folders, one for GF, one for your version. I'll discuss about in my meeting tonight, I let you know :) Thank you for your cooperation! 😄

[vv-monsalve]

Hi @romashamin, I've given a look at the discussed issues, and these are my thoughts/suggestions:

• Bear in mind that once the font gets published on Google Fonts, that version will become the most used one. Thus, I would strongly discourage the use of two different versions. This would only lead to confusion for users, which is not ideal, but also could lead to more issues to attend to.
• GF follows the standards for names and user values for axes registered in the Open Type spec for TTF. So, as Dave says above, applying them will comply with OT standards which would be beneficial for the font project as it would lead to major compatibility across platforms that follow the spec (Operative Systems, browsers, Apps).
• The length of the family name and the style is still a subject of discussion. So far, we've only seen strict Postscript length restrictions associated with backward compatibility for fonts already used in legacy software. We have not received any printing issues for families with longer names.
• Now that you've redefined the weight distribution to include the SemiBold, I don't see a problem with using axis mappings at the font info level to specify that mapping into the Avar table.
• The name of the masters are mandatory under GF production requirements but, as said in your comment above, "master names do not make any difference to the exports." they wouldn't matter when you Export the fonts from Glyphs app, so it shouldn't be an issue.
• After finishing the production adjustments following our requirements, you would only see in the drop-down menus of Apps one list of weight styles (not repeated), and yes, the width options should be accessed using the axis slider. These are the reasons for the restrictions on fvar Instances.
• But, the static instances for all the widths would be added in the zip that you can download from the API. Fredoka could work as a good example, you could download and try it.

[romashamin]

Hello @vv-monsalve,

Thank you for your participation! All of what you said is fair enough 🙌

Unfortunately, I believe we’re in a situation where it’s too late to reconsider the font project’s fundamentals. Martian Mono is the second font in the family along with Martian Grotesk—a paid typeface that already sells on MyFonts and Gumroad and is already in use in digital and print projects.

If I start a new font family, I’ll definitely make it meet the OT spec. However, I’m afraid it’s too late to make incompatible changes for the existing Martian family.

Now I’m trying to focus on ways out of the given circumstances.

Does it somehow confuse some users if we ship two versions of the font? Yes. Well, I have to hope there won’t be that many of them.

---

I don't see a problem with using axis mappings at the font info level to specify that mapping into the Avar table.

If I get things correctly, Glyphs app developers don’t recommend this:

Axis Mappings ... may create faulty entries in the fvar table. We are considering deprecating this method. If possible, use the Axis Location method.

---

Fredoka could work as a good example, you could download and try it.

Thank you for the example. I downloaded and studied it.

First, I see that the font family in Fontgauntlet appears like Fredoka Light:

Second, in the Preset styles list, I can’t pick either Condensed or Expanded styles.

The same in macOS Font Book:

Just to be sure—is that expected behavior?

[romashamin]

Hello @emmamarichal!

I'll discuss about in my meeting tonight, I let you know :)

Have you had a chance to discuss the situation over here? I’d love to get your thoughts on our next steps 😊

[emmamarichal]

Hello @romashamin,

Yes,I asked the team for advice at the meeting, hence Viviana's answer :)

Otherwise, to answer your questions:

If I get things correctly, Glyphs app developers don’t recommend this

Yes, but we don't export fonts directly from Glyphs and we use a stat table (in a config.yaml) that we apply to fonts, so in our case using axis mapping is better.

First, I see that the font family in Fontgauntlet appears like Fredoka Light

Yes, it's normal. Fredoka has only two weight masters: light and bold, and we have to set a variable font origin in our parameters (it will be the default one), that is based on masters, and not on instances. We recommend to have a Regular master to avoid this kind of problem.

Second, in the Preset styles list, I can’t pick either Condensed or Expanded styles.

Indeed, this behavior is expected. This is what @vv-monsalve explains here:

After finishing the production adjustments following our requirements, you would only see in the drop-down menus of Apps one list of weight styles (not repeated), and yes, the width options should be accessed using the axis slider. These are the reasons for the restrictions on fvar Instances.

So the width instances are not available directly from the menu, but only by the slider. If we allowed this axis to be supported, the menus would be much too long for some projects. That's why we propose to download a set of statics in addition to the Variable.

To come back to your project, I understand completely that it is impossible for you to modify it too much, for the various constraints that you have announced. If you don't want to modify it, it's not a problem, we are not obliged to publish it on GF. And we may have in the future, other opportunities to collaborate together :)

[romashamin]

Hi @emmamarichal,

So the width instances are not available directly from the menu, but only by the slider. If we allowed this axis to be supported, the menus would be much too long for some projects.

Thank you very much for the clarification! Now I’m absolutely sure this is a feature, not a bug 🙌

If you don't want to modify it, it's not a problem, we are not obliged to publish it on GF.

I propose not to give up right away 😊

I believe splitting the source file into two versions, where GF will get the dedicated source file, is a solution. I can try to prepare it accordingly to your guidelines (I’d appreciate your help here).

So for me, the decisive question is—does GF agree to support this plan, despite its flaws? If yes, we’ll discuss further steps. Of course, in this case, you can count on my full assistance.

Please, let me know your decision.

[emmamarichal]

Hi @romashamin,

I think I have the solution to this issue (but not in the good way...) I re-read the conversation, and saw that:

Martian Mono is the second font in the family along with Martian Grotesk—a paid typeface that already sells on MyFonts and Gumroad and is already in use in digital and print projects.

Unfortunately, we can't onboard a font that already have a part of its family that isn't open source. https://googlefonts.github.io/gf-guide/onboarding.html#new-fonts "The project must be wholly licensed under the SIL Open Font License v1.1. There must also be no proprietary/restricted-license versions of the project available elsewhere (such as additional weights/styles). Refer to the dedicated chapter to know more about the license file requirements."

I'm sorry, we missed this detail as we were focus on technicals issues. Thank you for your patience, I hope we can work together in the future, at least you will have had some notions about Google Fonts specs haha

Have a nice day, Emma

[romashamin]

I'm sorry, we missed this detail as we were focus on technicals issues.

@emmamarichal actually we’ve discussed this with @davelab6 and agreed that this is not the problem. Something changed?

[RosaWagner]

Hi @romashamin, is there a public record of this exception to the requirements? If not, we would need @davelab6 to add a comment in the issue tracker about it https://github.com/google/fonts/issues/4610#issuecomment-1286645144

[romashamin]

is there a public record of this exception to the requirements?

We discussed this via email

[davelab6]

Sorry Emma that I didn't pass down that discussion. I commented on that issue to do so, now :)

Viviana already explained the problem having a gf specific version, but, given you are OK with the tradeoffs here, it is fine for me to have a separate source for the separate version.

@romashamin kindly, the team here is well aware of glyphsapp recommendations but our requirements remain primary for our own distribution. There's similar variety of opinion about vertical metrics, I believe, and we have fontbakery profiles to account for the multiplicity of views about how fonts should be made :)

[RosaWagner]

I asked @emmamarichal to try first the compromise on exporting 2 sets of fonts from the same sources files to avoid duplicated sources. As @vv-monsalve pointed, it only get out of sync in time otherwise, and a nightmare to upgrade. If there is too much issues with that compromise, then we'll make a second source, but only if @romashamin can cross fingers on his heart he gonna maintain both with equal love.

[emmamarichal]

Hi everyone, I'm closing this PR, I'll open a new one once the font is ready (I'm working on it), it will be clearer.

[romashamin]

Folks, I’m sincerely sorry for the silence—I have a lot to do at my regular job these days.

Let me please describe the idea of living with two sources. I believe it’s important to be on the same page before starting.

Step 1. We duplicate the current source file, rename it to, let’s say, Martian Mono GF.glyphs, and apply all the needed adjustments to it.

Step 2. I’m working on the update in the original source file.

Step 3. We repeat step 1 for the new original source when its new version is ready.

We repeat steps 2 and 3 for every version update.

The repetitive work here is applying adjustments to every freshly duplicated Martian Mono GF.glyphs.

@emmamarichal @RosaWagner @davelab6 does this sound like a plan?

P. S. I’m going to ask people on the Glyphs app forum for advice—maybe there’s a chance to automate the adjustment work, at least partially.

[emmamarichal]

Hello @romashamin, I have started working on the file. The changes between your file and our specs are:

• font infos: parameters added: isFixedPitch (for mono), and Axis Mapping. The VersionString is removed. And the license is written a bit differently. (Copyright 2020 The Martian Mono Project Authors (https://github.com/evilmartians/mono))
• Master names: Condensed Thin instead of Cn Th for example
• Instances added, but yours are still there, they are just not activated.
• Features: rlig desactivate (but not removed), and alternate layers added instead. Removed threechars and twochars classes that created a bug during export.

I'm not done yet, so maybe we'll have a few more changes. These are pretty quick differences to set up, because now that they are done, you just copy and paste. I'll write a document that explains the process to do when you submit an update.

Otherwise, for your Martian Mono.glyphs file, I could just copy and paste my Martian Mono GF.glyphs file, and uncheck the settings that I have in place, and rename the masters, so that when you want to update it on Google, you just have to check everything back in. What do you think about it?

So: 1- I set up the file for GF + I give you a copy for you with all my set up unchecked and deactivate + renamed masters in your way (so you can keep your own set up) 2- You make your changes 3- You make a copy that have my set up checked and activated (you can follow my instruction that I'll write, to be sure) 4- I just have to check that the sets ups are good and export font

[RosaWagner]

• It would be preferable to have the same license string in every sources.
• Axis location feature is supported by glyphsLib, it's way less practical than gftools' Axis Mapping, but if Romain wants to keep it is is possible.

[romashamin]

As far as I can see, most of the adjustments can be incorporated into the original source file. And after I make a copy of it with new changes, I can activate them, make a few more renames, et cetera.

That sounds perfect, @emmamarichal thank you very much! Let’s stick to it as a general plan.

One more thing: I have the Martian Mono.glyphs file which is far ahead of the one placed in the repo (I’ve been working on Cyrillics for a few months).

How best to proceed right now to get it updated?

It would be preferable to have the same license string in every sources.

@RosaWagner done.

Axis location feature is supported by glyphsLib, it's way less practical than gftools' Axis Mapping, but if Romain wants to keep it is is possible.

Let me please investigate it on the weekend. If it works the same, it’d be perfect. I have no personal preferences here.

[RosaWagner]

It works the same only if you export with gftools, Glyphs doesn't support their own Axis Mapping parameter very well, they chose Axis Location parameter instead.

[emmamarichal]

@romashamin I just made a try with axis location and it works well, so indeed, it will be easier to use them!

About cyrillic, is it ready now? You can update the repo, I'll apply my changes on the new file :)

[emmamarichal]

Also, using components to create glyphs create problems in export (e.g. A, H etc.). Here is an example with Cyrillic that I didn't correct yet since there are not ready:

This is not a big problem, I can list the problematic glyphs and decompose them for export (and I keep a version of the file with the components so you can work as you wish).

The only problem is that when I decompose, it creates spacing problems, and I can't update the values: it seems to be stuck. I have never used this kind of components, do you know how to avoid this kind of problem? @RosaWagner maybe?

https://user-images.githubusercontent.com/64773544/202731583-09b9545f-16ef-4d3a-b355-0714bf3215d2.mov

[romashamin]

@emmamarichal nope, the Cyrillic script is wip.

Hey, what about this. Download the file with the latest updates: Martian Mono.glyphs.zip

Apply your changes and send it back to me. I will wait for it and then I continue my work in that file. (Since this moment I’m on pause with glyphs drawing, and waiting for the updated file.)

Also, using components to create glyphs create problems in export

If there’s no solution, please, let me know—I can get rid of them in the original source file. I figured out that in monospaced fonts components hinder more than help. So it’s not a big problem.

[emmamarichal]

Ok, I merged your last changes, and I'll send you a PR with my changes on the file you sent me, please don't modify your repo in the meantime. You should receive the PR today :)

• if you can decompose the glyphs that are made with smart components (so not accents, fractions, etc.), only A, H, hbar, euro, yen, and most of cyrillic, that would be great, thank you!
• tell me when it's done, and I will export the fonts so we can onboard at least this version (we can onboard the version with the cyrillic later)
• if you prefere to wait for the cyrillic, we can! In that case, tell me when this is done :)

[romashamin]

and I'll send you a PR with my changes on the file you sent me, please don't modify your repo in the meantime. You should receive the PR today :)

@emmamarichal deal!

if you can decompose the glyphs that are made with smart components (so not accents, fractions, etc.), only A, H, hbar, euro, yen, and most of cyrillic, that would be great, thank you!

Sure I can! I’ll do it then.

if you prefere to wait for the cyrillic

No-no, I prefer not to wait for 0.9.3. Give me please this weekend—I’ll decompose all smart components in the source file that is currently placed in repo (which is version 0.9.2). I’ll push the update and ping you.

Thank you!

[romashamin]

Hi @emmamarichal!

I pushed the updated Martian Mono.glyphs: https://github.com/evilmartians/mono/commit/b05977888a0d4c88fde75b39d0fc62839c418312

I tried to incorporate all the changes I found in the MartianMono.glyphs:

• Copy-pasted Axis Mappings custom parameter.
• Ensured that ALL the glyphs in the file were set up with a width of 600 or 750 points.
• Added and turned ON the isFixedPitch custom parameter.
• Decomposed all smart components. Please, let me know if I forgot something.
• Set up alternate layers for dollar and cent with [126<wg].

Please check if everything is correct.

[emmamarichal]

@romashamin Thanks a lot! I'll take a look asap :)