Small fixes to match with the GF specs

[emmamarichal]

Hi @oliverlalan!

Again, congrats and thank you for this amazing project! I took a look at the files, and all is almost perfect.

A few things to update:

• You wanted to change the name right? Don't forget to update the documentation and images as well
• Lcaron dcaron lcaron tcaron should have another design, with an other shape of caron.
• AE spacing (no spacing on the right side)
• Check copyright url: Please consider updating the url from 'https://scripts.sil.org/OFL' to 'https://openfontlicense.org/'. (To check in OFL.txt and in sources (Licence and Licence URL))

Don't hesitate if you have any questions :)
Cheers!

Example of caron:

[oliverlalan]

Hello @emmamarichal,

I am back on track with this!

A few comments:

• Font name: On my list. I’ll update everything once we resolve all design issues.
• Carons: Noted.
• Copyright: Updated.
• Spacing: The font is bitmap-inspired, and due to the constraints of the chosen matrix size, some design limitations are hard to avoid if we want to keep the font’s essence. The issue affects not just the AE character but a few others as well:
  

To maintain the style, it’s critical that the dots fit into the 6x10 grid. Here are three options, each with its own drawbacks:

• Keep the font as it is, at the expense of legibility for a few rarely used characters (my preferred option, as it reflects how these fonts were rendered on old machines).
• Redesign the problematic characters while keeping the same reference grid, which might result in a rare look and/or worse legibility.
• Abandon the monospaced design and adjust the glyph widths based on the columns used for each. This would solve the legibility issues, but the font would no longer be 6x10 or monospaced.
  Let me know your thoughts.

[emmamarichal]

Hi @oliverlalan,
Thank you for your patience!

We think it's indeed better to keep an actual monospace.
But on the other hand, we found a bit weird to have these kind of "space" issue. We can suggest to

• redesign some problematic characters
• make some problematic glyphs wider, but on a "double" width (12x10). So it can works on a table for instance.
• If it's really really complicated to find compromise for some glyphs, we can eventually accept exception, and have no spacing on one of the side.

Let me know what you think about that :)

[oliverlalan]

Hello @emmamarichal,

I would discard the "double" width option for two reasons: First, the problematic glyphs would look way too spaced. And second, and most important, the font would not be technically "monospaced" anymore (I am not a font engineer, but I am quite sure fontbakery checks all glyphs have the same width when the font tables are flagged as monospace).

I would go with the redesign and exceptions alternative. Here it is my proposal:

• Green for the ones that look aesthetically well after redesigned, yellow for the ones that I don't particularly like, but I am okay with updating, and red for the ones that I think should be kept as they are because they would become illegible otherwise.

If you are ok with it, confirm it, and I will update the characters marked with green and yellow, left the red ones as they are, and let you know when all the other issues are closed.

Regards!

[emmamarichal]

Hi @oliverlalan! I'm ok with that, you can go ahead :) Let me know once it's ready to review and onboard!
I'll then fork your repo and send you a PR if I need to bring corrections during my QA!
Thank you!

[oliverlalan]

Hello @emmamarichal !

The font has been updated with all the requested changes (repository and issue renaming included).

You can already fork and do the font QA.

Just let me know if there is anything else you need from my side.

Regards!

[emmamarichal]

Excellent, thanks a lot, I'll take a look asap :)