search

slavfox / Cozette

A bitmap programming font optimized for coziness 💜
MIT License
2.84k stars 42 forks source link

Combining marks support #38

Closed cpkio closed 1 year ago

cpkio commented 3 years ago

Is is possible to get combining diacrytic marks? For example, the text with code points б\u043E\u0301льшую (glyphs converted to UCN for convinience) should look like 2020-11-30_124033 but with Cozette I get 2020-11-30_124433

slavfox commented 3 years ago

There's a lot of combining marks in Unicode, probably more than there are glyphs in Cozette. Which ones do you need?

cpkio commented 3 years ago

U+0300 COMBINING GRAVE ACCENT U+0301 COMBINING ACUTE ACCENT U+030C COMBINING CARON

cpkio commented 3 years ago

Since I have FontForge working, I started thinking about this feature. In regular text flow, a combining mark joins with preceding visible glyph, but a monospaced font like this will probably have to replace the combining mark with space? Is it possible to render combined glyphs without affecting overall string length?

slavfox commented 3 years ago

I've investigated a bit and that seems correct. If the font includes U+0300, a\u0300 will get printed out as "a`", not as "à". I'm going to close this, since it seems that including the combining marks would lead to a strictly worse experience than having the font renderer fall back to a vector font for those.

cpkio commented 3 years ago

I've tested this a bit, and came to some interesting results.

In Windows, combining marks, created in a font, seem to partially «work» even if no special features are added to the font table. Windows just takes a symbol from the font and places it over another glyph. I'm using ConEmu for that, it seems reliable to me. If Windows «knows» the ligature, it will replace the glyph combination with a corresponding glyph from the font, which is expectable. I dont' know if it is possible to set some positioning anchors in Cozette with FontForce so that combining marks would reposition themselves in case of uppercase.

See how it looks for some symbols I've made with small and capital russian о (О) char. The last one (про̽вет) does not show correctly because the u033D has not been drawn. 2021-07-21_220816

I'm testing this because if no combining mark defined, glyph combinations displays badly, even when the combination is known and should be replaced by appropriate glyph.

slavfox commented 3 years ago

Since this is Windows, I'm assuming you're testing CozetteVector. This behavior is expected from vector fonts, but comes at the cost of breaking the bitmap font. As Cozette is a bitmap font first and foremost, the bitmap version always takes priority, and features should never break the bitmap fonts, even if they are an improvement to the vector version.

There's one other possibility that could be investigated is tweaking the bitmap glyph metrics so that combining marks don't advance the cursor - I'm not sure what the exact values should be off the top of my head, but the idea is that, Cozette being a 6px-wide font, the combining mark would be defined with a width of 0 (to not advance the cursor) and start 6px before the left margin.

I'm not sure if that is possible to implement, but it is the only way i can come up with to implement combining marks for the bitmap font.

cpkio commented 3 years ago

You're right, that's CozetteVector. I do expect such combined glyphs to break visual string length vs byte-length, it's ok for most linewise texts. I just dont like garbled looks of chars with combination marks. Will play around with your idea.