Coder Social home page Coder Social logo

batsimadz / sankofa-display Goto Github PK

View Code? Open in Web Editor NEW
6.0 5.0 0.0 193.76 MB

Sankofa Display is a typeface that draws inspiration from African art styles, with a focus on straight-line geometric designs.

Home Page: https://www.sankofadisplay.com/

License: SIL Open Font License 1.1

HTML 0.29% Makefile 0.01% Python 94.84% PowerShell 0.02% Shell 0.10% C 1.02% Cython 1.76% XSLT 0.26% C++ 1.44% Meson 0.01% Fortran 0.05% Forth 0.01% CMake 0.10% Roff 0.11% JavaScript 0.01%
african african-languages font google-fonts latin open-source

sankofa-display's People

Contributors

adibdesign avatar batsimadz avatar

Stargazers

 avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

sankofa-display's Issues

acutecomb and gravecomb anchors need shifting

These combining accents, instead of being horizontally aligned so close to their bottom corner, should align noticeably closer (but not at) the middle. So for example the acutecomb has ink from x = 34 to 181, and the anchor at 76 or about 1/4 of the way across the inked part. Try about 20 units further right.

Then do the reverse on the gravecomb. :)

Note: hungarumlautcomb seems about right in this regard, already.

Confusability with "n"

There's a potential misread / confusability issue with lowercase 'n' that needs addressing. The construction can read as an "a" — it's quite similar to the way "a" is drawn in "chancery" styles, for example, and the overall look of a straight stem on the right with a loop attaching on the left reads like an "a" construction.

This is a bit like the earlier comments about more clearly distinguishing between S and 5 (for example), where they may work fine in words and sentences, because there is surrounding context to provide visual guidance to a reader, but in a postcode, they would be confusable.

Here, think about text elements that also don't provide the same level of context, like a URL or an email address. Without those cues, the readers can misread something, like here:
Screen Shot 2023-12-14 at 9 17 35 AM

If you didn't know the system, you might read that as abc.com (which exists), instead of nbc.com. Artificial example, but URLs and email addresses include a lot of abbreviations & acronyms, so it can happen.

A side-effect of this is that the nleg ends up very close in form to the q:
Screen Shot 2023-12-14 at 9 26 08 AM

As far as how to find a solution goes, the triangle shape is part of the issue, I think.... In other letterforms, the full-width / corner-to-corner triangle is used in letters that have a "full size" closed counter, e.g.:
Screen Shot 2023-12-14 at 9 19 41 AM

In a and e, where the closed-counter is only "half" the size, the connection point for the diagonal stroke is different. I think that helps, while staying clearly consistent.

So you could move the connection point (upper-right) inward and that might help. Another option would be to incorporate a short in-stroke mark on the upper-left / left stem. I did a SUPER ROUGH paste-up of that (don't be offended...) on both a right-facing and upward-facing stroke, and I think they contribute something, but wouldn't do it entirely on their own.
Screen Shot 2023-12-14 at 9 28 44 AM

Screen Shot 2023-12-14 at 9 31 31 AM

So, you might feel like either one of those is worth exploring a little, but I suspect it will take a combination of approaches. You certainly still have other well-defined elements in the visual language of the design that you could drawn on, including the dot and the triangle, as well as trying diagonal orientation on the in-stroke position.

The other big option that you have available to you is to play with the width. Consider how narrow the two internal spaces in the "m" are; the "n" is much wider than those, and that may contribute to it feeling less directly-connected to those shapes. So you could work with (a) narrowing the entire "n" glyph and/or narrowing the triangle of the "n" so that it is visually equal/close-to-equal to the one in "m", with some minor adjustment to the total "n" width so that it matched.

In theory, of course, some people might say that you need to be real precisely similar in "n" to "h" and "u" on width, but I don't think the rest of the design really makes that necessary. If you were to add a vertical in-stroke to the top-left of "n", you'd have to consider raising the ascender height to be sure it reads clearly different. But even without that, I don't think the constructions of "h" and "u" (or "m") need additional adjustment.

So there are a few avenues to explore; I suspect incorporating more than one technique will be necessary, but only trying it can really show....

Design feedback (JAN 06, 2024)

These are new feedback on the Glyphs file of Sankofa as of the end of December 2023.
General comments: there are very few tweaks that need to be done. Mainly issues about alignment of the diacritics (might be some missing work with the components and anchor positions).

Sankofa_fb_Lisa_060123.pdf

  • diacritics alignment with each other: they need to be all aligned on the same level.
  • diacritics alignment with their letter: more centered
  • letters with stroke strike through: maybe a more slanted stroke can help by crossing less parts of the letter and bring more legibility?
  • narrower AE and OE
  • narrower J
  • iota: its bottom right serif is too long, it's too assymetrical
  • Lcaron: the commaaccent should be closer to the right side (look a words in Czech language containing that letter to have an in use idea)
  • hooks and horns: they tend to always clash with the following letter. Maybe they could be shorter but starting higher up above the capital height
  • reversed e: they look too similar to the "a". A different structure would help differentiate both.
  • ligatures ffi, ffl, fl: make sure to keep the same spacing in between all letters of these ligatures
  • theta: it is not a superior glyph, it is to the same level and proportions as pi, delta, etc.
  • some strokes are too thin, make sure to have them all consistent by zooming in and out, or using the blur toggle at the bottom of the preview bar
  • currency symbols: there should be the same distance between the two bars of all currency symbols (whenever they do have two)
  • notequal and approximate: these are part of the mathematical symbols just like equal, multiply, etc. , and should be consistent

dotbelowcomb is lighter than the dot above

dotbelowcomb seems to be substantially lighter in weight than the dot above. They should definitely be the same weight. Probably ought to change the dotbelowcomb, as the dot above seems fine.

Octopus testing: mising glyphs

This is a list of glyphs (or base+combining-mark sequences) that show up as missing in Octopus tests with the "African Kern Test Starting with GF African Pri" test file.

The ones where there's a "COMBINING" entry by itself indicate that it's a sequence formed by the previous letter + the combining mark, so those are separated with an extra line to be clearer. Those cases might just be fixable with a check that there is an anchor on both the base and the mark.

glyph   name
ǻ      LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE
ƃ      LATIN SMALL LETTER B WITH TOPBAR

d      LATIN SMALL LETTER D
̪      COMBINING BRIDGE BELOW

ƌ      LATIN SMALL LETTER D WITH TOPBAR
ȡ      LATIN SMALL LETTER D WITH CURL
ĕ      LATIN SMALL LETTER E WITH BREVE
ŏ      LATIN SMALL LETTER O WITH BREVE
ǽ      LATIN SMALL LETTER AE WITH ACUTE
ĭ      LATIN SMALL LETTER I WITH BREVE

ĕ      LATIN SMALL LETTER E WITH BREVE
́      COMBINING ACUTE ACCENT

ƕ      LATIN SMALL LETTER HV
ŀ      LATIN SMALL LETTER L WITH MIDDLE DOT
ẛ      LATIN SMALL LETTER LONG S WITH DOT ABOVE
ſ      LATIN SMALL LETTER LONG S
ȿ      LATIN SMALL LETTER S WITH SWASH TAIL
ẙ      LATIN SMALL LETTER Y WITH RING ABOVE
ʀ      LATIN LETTER SMALL CAPITAL R
ẟ      LATIN SMALL LETTER DELTA
ʼn      LATIN SMALL LETTER N PRECEDED BY APOSTROPHE
ȵ      LATIN SMALL LETTER N WITH CURL

ᵻ      LATIN SMALL CAPITAL LETTER I WITH STROKE
'      APOSTROPHE

ẹ      LATIN SMALL LETTER E WITH DOT BELOW
̣      COMBINING DOT BELOW
́      COMBINING ACUTE ACCENT

l      LATIN SMALL LETTER L
̪      COMBINING BRIDGE BELOW

ĭ      LATIN SMALL LETTER I WITH BREVE
ˠ      MODIFIER LETTER SMALL GAMMA
ʽ      MODIFIER LETTER REVERSED COMMA
ẹ      LATIN SMALL LETTER E WITH DOT BELOW
ʼn      LATIN SMALL LETTER N PRECEDED BY APOSTROPHE

(edit to add some capitals that got cut off accidentally when pasting:)

ʽ      MODIFIER LETTER REVERSED COMMA
Ẹ      LATIN CAPITAL LETTER E WITH DOT BELOW

Ĭ      LATIN CAPITAL LETTER I WITH BREVE
Ĕ      LATIN CAPITAL LETTER E WITH BREVE
Ŏ      LATIN CAPITAL LETTER O WITH BREVE

Ṣ      LATIN CAPITAL LETTER S WITH DOT BELOW
̢      COMBINING RETROFLEX HOOK BELOW

Ȿ      Undefined in range Latin Extended-C <--- CAPITAL S WITH SWASH TAIL, I believe; the lookup utility used may be old

ẟ      LATIN SMALL LETTER DELTA
Ʀ      LATIN LETTER YR
Ŀ      LATIN CAPITAL LETTER L WITH MIDDLE DOT
Ƕ      LATIN CAPITAL LETTER HWAIR

L      LATIN CAPITAL LETTER L
̪      COMBINING BRIDGE BELOW

Ǽ      LATIN CAPITAL LETTER AE WITH ACUTE

Strokes thickness inconsistencies

From the file of Sankofa as of Jan 23, 2024, here are my comments on some inconsistent stroke thicknesses:

  • horizontal bar of Eth (and Dcroat) are different, but they should be the same, and the one on the right seems more consistent with the general letter (the one on the middle has a too thin horizontal stroke)
Capture d’écran 2024-01-23 à 19 24 30
  • Iota-latin is too thick
Capture d’écran 2024-01-23 à 19 24 57
  • top hoop and triangle part of Glottalstop is too thick
Capture d’écran 2024-01-23 à 19 25 45
  • triangle parts of question marks are too thick, and bullet is too thin
Capture d’écran 2024-01-23 à 19 32 29

Numerals feedback

Some feedback on the (full-size) numerals!

Shapes:

  • Forms that have a diagonal at either the top or bottom should get some overshoot, like the letters do. Definitely needed in zero (both), seven (bottom), and nine (bottom), which have a bit of a "floating" feel to them when used in a string. Possibly the tops of 4 and 6 as well, but that needs judging after adding overshoot to the others.
  • The forms that have rectangular counters to them need to balance those counter sizes. Compare the "box" in six and nine to the box in five. (Obviously in this design, the top of five has a triangle in it.)
    • If regularizing that affects the angle of the leg on nine, that leg could descend a bit below the baseline to compensate. Similar option their with the diagonal on six.
  • The foot/base of seven is a bit too far to the left. It shouldn't be centered, but in a row of sevens, it's too far visually.
  • Overall, one is too light.That might be because the dot is slightly too far away, but the overall tonal value is light enough that it might just need something else added to grab the eye of the reader a little more; it could get lost.

Widths:

  • A few of the numerals are noticeably narrower than others; I think the widest is zero at 414 (which is appropriate for this design), but the others need to be closer to each other. That will make spacing them much easier to dial in.

Spacing:

  • All the numerals need to have the same (in this case, literally identical) overall width; i.e., tabular spacing. You can do non-tabular spacing as an OpenType feature if you like.
  • Zero is the widest, which is appropriate. So set a row of zeros, then below that add a sequence of zeros within a line of text, and adjust the sidebearings of zero from there. But once you have that total glyph+sidebearings width, that has to be the total width for all the other numerals too.
    • Like we had chatted about earlier, the numerals kind of behave according to their own rules, readability-wise, so don't let the
      numbers-in-text proofing overrule what looks right in number-to-number proofs for sure.
  • The identical total-widths MAY very well mean that some of the other numerals need to be tweaked so that they don't appear over-crowded or too sparse.
    • Definitely you'll want to test rows of each numeral by itself plus some columns of numerals to assess the visual centering. There's not a lot of shortcuts to take advantage of, beyond the fact that half of the numerals have fairly symmetrical sides..

numerals-NW-feedback

Design goals for .notdef and dotted circle

The .notdef and dotted-circle glyph have some fairly strict requirements on them.

Mainly, they are both supposed to only be seen by the user when something is broken, so you don't want them to blend in too much with the design of the normal glyphs.

Size-wise, the .notdef looks correct; they are generally cap-height and on the baseline. But the texture and stroke-weight may be misleading for this typeface, considering how many rectangular designs there are for the other glyphs. Better to make it a little bolder and more plain (perhaps even entirely plain); people will want it to jump out at them in their documents if they've tried to type something not supported.

The dotted circle is supposed to be similarly plain-looking, so the glyph in the font works there. But it does need to be scaled up to cap-height. Here again, it's going to stick out because of that, but that's what it's supposed to do.

A few glyphs need overshoots

There are a few glyphs that have pointed bases which also need to have the points overshoot down below the baseline.

Mainly where I notice this is in t and l in the lowercase. When you see them in a word, they are floating a bit. Example:
t-and-l

The overshoot that you have for the existing, stereotypically-diagonal shapes like v works fine; probably just overshoot these by the same amount.

However, do check other glyphs that have diagonal pointing-down bases, too: there are some in the extended Latin set that have the same form.

Based on my looking at it in samples, I don't think that the forms that have an "internal triangle" but also have straight stems (like n and h) need this correction, because the stems kind of dominate how they look. This is just an optical effect that I think you see when you have a downward-pointing bit that has nothing else anchoring it on either side.

But certainly feel free to have others weigh in on that!

H centered anchors need to move right to be centered

In the cap H, both the "top" and "center" anchors seems to need to go about 17-18 units to the right to be properly centered. The advance width is 511, and those two anchors are both at x=238, should probably be at about x=255 or 256

This impacts a number of precomposed accented characters indirectly, their diacritics are “off”

cap S reworking

Some folks have noted that the center portion of the cap S could be seen as an undesirable symbol. Although many people have looked at the S without making this observation, I must say that for me at least, once seen it can’t easily be unseen. :(

As you have discussed with Nate, we are looking to see a revised version of the S that does not have this problem.

PROJECT CHECKLIST

This issue tracks checkpoints for the project long term and will be updated by reviewers and QA

MILESTONE 1

  • Concept for design

  • Contract Signing

  • GitHub setup complete

  • PROTOTYPE HamburgefontsivHAMBURGEFONTSIV!., “space char”

  • GoogleFonts Project Template

  • Font Building and producing artifacts in Actions tab?

  • Checking Fontbakery fails?

  • Checking glyph coverage for milestone?

  • Team members and reviewers added as collaborators in the repo

Path direction correction

  • Are all characters interpolating? Select all in font tab and fix path direction shift+command+R

Not necessary in Repo but good for reviewers

  • Proofing with Font Proofer or similar tools.
  • Are proofs of all characters made? Do you have text set in the font? Are you printing and proofing?
  • Are proofs being sent to reviewers for feedback?

Spacing

  • Spacing is tested with spacing strings
  • Capitals are spaced to work with lowercase letters

MILESTONE 2

  • 53+ glyphs
  • Font Building and producing artifacts in Actions tab?
  • Checking Fontbakery fails?

Path direction correction

  • Are all characters interpolating? Select all in font tab and fix path direction shift+command+R

Not necessary in Repo but good for reviewers

  • Proofing with Font Proofer or similar tools.
  • Are proofs of all characters made? Do you have text set in the font? Are you printing and proofing?
  • Proofs are made with randomized text, and tested at the range of sizes defined in the project brief
  • Are proofs being sent to reviewers for feedback?

MILESTONE 3

  • 80+ characters incl. A-Z, a-z, 0-9 in font
  • Diacritics (in sets of western euro, Vietnamese, floating, attached)
  • Special SSA characters/ Diacritics
  • Diacritics are built from combining forms + anchor points
  • Diacritics fit into vertical metrics
  • Font Building and producing artifacts in Actions tab?
  • Checking Fontbakery fails?

Path direction correction

  • Are all characters interpolating? Select all in font tab and fix path direction shift+command+R
  • Are all overlaid diacritics using the same path direction?

Spacing

  • Numerals are tabular spaced

Not necessary in Repo but good for reviewers

  • Proofing with Font Proofer or similar tools.
  • Are proofs of all characters made? Do you have text set in the font? Are you printing and proofing?

MILESTONE 4

  • SSA Google charset ~560 characters x variation axes
  • Font Building and producing artifacts in Actions tab?
  • Checking Fontbakery fails?

Path direction correction

  • Are all characters interpolating? Select all in font tab and fix path direction shift+command+R

Spacing

  • Kerning with Kern On and reviewing kerning (lowercase-lowercase, Capital-lowercase, numerals)

Not necessary in Repo but good for reviewers

  • Proofing with Font Proofer or similar tools.
  • Are proofs of all characters made? Do you have text set in the font? Are you printing and proofing?

MILESTONE 5

  • Additional fixing?

  • Fontbakery Bug Fixes

  • Font Building and producing artifacts in Actions tab?

  • Checking Fontbakery fails?

  • Variable axes build?

  • OpenType smart-font features build?

MILESTONE 6

  • All glyphs complete and known bugs fixed
  • Review with onboarding team

MILESTONE 7

  • Social media promotion, additional static and animated assets
    produced, print-on-demand merchandise available

  • Pull request to Google fonts made? Add font issue to google fonts filed?

Design feedback - (Feb. 29, 2024)

These are design feedback on Sankofa Display from its latest update (Feb. 29, 2024).

  • diacritics misaligned (it is better to move the original diacritic rather than move its component)
Capture d’écran 2024-02-28 à 16 23 48 Capture d’écran 2024-02-28 à 16 26 57

Stroke thickness inconsistencies
Capture d’écran 2024-02-28 à 16 24 45

  • bar in Gstroke too thick
Capture d’écran 2024-02-28 à 16 24 57 - [ ] bar in Hbar too thin Capture d’écran 2024-02-28 à 16 25 12 - [ ] Iota too thick Capture d’écran 2024-02-28 à 16 25 21 - [ ] Eng too thick Capture d’écran 2024-02-28 à 16 29 46 - [ ] horizontal bar of ystroke too thick
  • some glyphs are missing the texture "treatment" of Sankofa??
Capture d’écran 2024-02-28 à 16 29 35 Capture d’écran 2024-02-28 à 16 30 33
  • letters i and j in ij are too far from each other. By decomposing them and readjusting their width, it can make them feel more like the digraph ij instead of two separated letters
Capture d’écran 2024-02-28 à 16 28 07
  • contour directions issue
Capture d’écran 2024-02-28 à 16 30 07
  • Spacing of figures: they seem to be the same on both sides, but figures like /seven, /four or /eight need adjustments and, eventually even kerning to avoid too large white spaces (look at the space between /six and /seven!)
Capture d’écran 2024-02-28 à 16 30 21
  • braces are too "rigid" and are a bit hard to be identified as braces. Maybe something more like the squared brackets + the triangle in the middle?
Capture d’écran 2024-02-28 à 16 31 03

Glyphs proportions and heights

From the file of Sankofa as of Jan 23, 2024, here are my comments on some proportions of glyphs:

  • Chi-latin should be more aligned to the capital height
Capture d’écran 2024-01-23 à 19 24 01
  • Strikethrough in Sobliquestroke is too long (it might just fit within the S instead of going beyond its sides, and can be a bit more upright)
Capture d’écran 2024-01-23 à 19 27 09
  • bottom of Thorn doesn't seem to get to the baseline like P
Capture d’écran 2024-01-23 à 19 27 31 Capture d’écran 2024-01-23 à 19 31 13 75224f8c-bd7b-440d-9722-3543ed8ad5bd">

Kerning pairs

Here is a handful of pairs that could use some kerning adjustment, again based on Octopus tests.

Pairs that are overly close:

al
bu
ca
da
ka
kz
le
lu
Ca
Du
Ea
Za

The left side of a is a frequent culprit in those; with some of them (ka for instance) there is a near-collision at the baseline. Basically it's that the top-left and bottom-left extremes of a are so different that "where the adjacent letter is close" makes a big difference. It might be worth re-examining the left sidebearing of a, but the list above is still a minority of characters. I think that a few kerns may be the faster approach.

And pairs that are not close enough:

kj
in
fin
la
li
lz
ra
rj
rm
ya
Ay
Ba
Da
Di
Li
Pa
Ta

There, too, the atypical a means there are some pairs that need additional attention in this design, where they might not if it was in something real traditional. It's probably worth doing some more tests with Capital-to-lowercase pairs where the capital is one of the letterforms with a very "lozenge"-like right-hand-side — D from the basic Latin, plus several others in the extended glyphsets.

Definitely double-check that all of the diacritic-holding forms of the lowercases are included in kerning groups for lowercase-to-lowercase adjustments, but you might have no choice but to use different groups for the diacritic letters in several of those Capital-to-lowercase adjustments where the diacritic could collide with the cap.

Fontbakery checks needing attention

Several of the Fontbakery checks (via recent report) will likely need addressing. These are currently at "Warn" level.

  • Check the name table strings: both the RFN appearance and the missing space in "SankofaDisplay"
  • Unreachable glyphs: the .alt variants should be handled pretty straightforward in an OpenType feature
  • The decomposed "Lcaron" should stay in composed form unless the design precludes it
  • soft-dotted characters should lose their dots in the diacritic-carry forms

Slightly less vital, but still a really good idea long-term, is registering yourself (or your chosen foundry name) with a VendorID for the achVendID field.

The ScriptLangTags and METADATA subsets are for later, but you can define those, especially if you're interested in ensuring what appears in the meta table. (Both meta and the VendorID aren't super relevant for live fonts served through Google Fonts, but will be useful for people who download the font files.)

The colinearity, semi-horizontal/vertical, jaggyness, and contour-count checks are not of big concern because of the design, but it is important to scan through them and make sure that no unintended artifacts slip through among all the glyphs that are working-as-intended on those factors.

Elements positioning

From the file of Sankofa as of Jan 23, 2024, here are my comments on the positioning of elements with their letters:

  • bar of Gstroke clashes a bit with the loop, could be moved more below, or the loop can be readjusted to be smaller and avoid the black "blob"
Capture d’écran 2024-01-23 à 19 25 23
  • ogonek in idotless_ogonek (middle) isn't placed at the right spot, like how it is in iogonek (right)
Capture d’écran 2024-01-23 à 19 30 38
  • the dot below in ydotbelow can be placed a bit above the descender height, on the right side of y's descender.
Capture d’écran 2024-01-23 à 19 31 59

Letterforms feedback

There has been significant progress since the previous version!

From the status of Sankofa Display as of Dec. 07, 2023, here are some feedback on the letterforms and details (marked in Green in the PDF attached below, Red being comments on the spacing of some letters):
Sankofa_Lisa_231207.pdf

(You can mark each point of this checklist if/when these are done)
2. [ ] j and r - the dot could be more center aligned. And the bottom could be shorter?
3. [ ] k - it looks very narrow compared to most letters. Maybe it needs to have another construction? I saw that you did something different for /kgreenlandic. This could be a nice solution for the /k, with a longer ascender of course.
4. [ ] y - I don't see why the /y couldn't be just a /v with a descender? The triangle part in /y looks much smaller than /v, so brings the impression of a smaller letter when placed into words.
5. [ ] z - every single letter in Sankofa has a strong personality and don't follow the "conventional" structure. Maybe letter /z could have more personality as well?
6. [ ] figures (mentioned in the Numerals feedback issue)
7. [ ] hook (diacritic) - I believe it could be shorter, thus be smaller and better aligned with the other diacritics
8. [ ] tilde - the /tilde looks super long, it could be shorter on its edges to have this "wave" shape specific to the tilde
9. [ ] ogonek - maybe it could be a vertical + horizontal instead of a diagonal + horizontal ? So it is more geometric and simplified?
10. [ ] Alpha-latin - it took me some time to identify that letter as such. It may need some further explorations to find the right structure. Something like what I sketched in the PDF, or something more like a loop?
11. [ ] Beta-latin - I don't think that the bottom "serif" is very useful here. Or, it may need to be longer to it looks very intentional and "here".
12. [ ] cedilla (diacritic) - Looking at the forms of letters with which the /cedilla is used with, there could be two forms of /cedilla: one that is connected with the letter, and another that only has that "hook", so it is not literally attached to the letter. You can have a /cedilla.ss01 or /cedilla.alt for combinations with letters without bottom horizontal stroke like /C (also /H).
13. [ ] Chi-latin - it could be wider, almost like the /X
14. [ ] diacritics on top of /D letters - they should be center aligned, not aligned to the bottom tip
15. [ ] Estroke - to avoid a clash between the stroke and the middle triangle, it would be better to modify the triangle just on this /Estroke, plus rotate the stroke a bit more?
16. [ ] Hturned - be careful that its top doesn't go beyond the capital height!
17. [ ] Iogonek - the ogonek is a part that starts from the bottom right part of a letter.
18. [ ] Jstroke - for this letter only, maybe the dot could be removed so there is more space for the stroke?
19. [ ] Khook - maybe longer hook, or a different orientation of the hook here, can help identifying that letter as a Khook?
20. [ ] commaaccentcomb - it looks too dark and too long compared to the other diacritics (especially compared next to a /macron or /circumflex)
21. [ ] Nlongrightleg - maybe a different construction for that?
22. [ ] Omega-latin - same as 21.
23. [ ] Germandbls - the loop should sit on the baseline
24. [ ] Tdiagonalstroke - the stroke could be rotated a bit more, to have more clarity
25. [ ] Upsilon-latin - I'm not sure that this can be recognised as an Upsilon... it usually is more like a /Y or a /V. What does the other people think?
26. [ ] Gamma-latin - the loop can get to the descender level, so it really looks different from a potential /V
27. [ ] Vturned - why isn't it the /V upside down?
28. [ ] astroke - same comment as for Estroke (15).

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.