Open MayanKoyote opened 4 months ago
Сompessed the basic Latin alphabet letters (and punctuation) and additional letters of the Polish and Brazilian-Portuguese alphabets, the result ( original -> scaled -> compressed ):
nice finding! The GNU Unifont is drawn on a 16px grid for that much of a height, so anything non-integer scaled font size looks squashy on GMenu2X with this type of blocky font. Generally I wouldn't go that way for default font, remember that it is often updated and when we want to grab those changes it means smb else will have to do extra manual work for updates. I'm in for quick scalling it to some integer value for sure!
Dunno what they’ve been adding to the font lately that’s new and useful or may change in the future. And anyway you still have to compress it for Default theme: even with the current font width, neither the build number can be seen nor the descriptions of the settings can be read completely and stuff.
Guess you have a point there, that thinner font fits nicely (you're growing into font master!). Pefectly there should be scrolling effect for longer descriptions in the future.
Dunno what they’ve been adding to the font
Off the record, we're using now outdated Unifont from last year when there was TTF autogenerated type available from official site. Building latest version isn't hard but requires extra time. We should look into automating the process of your work. Could you explain in detail what's the recipe for reducing width?
I don't think this can be fully automated. At least I have no idea how. Unless maybe by comparing the states before and after. Yes, I worked with groups of letters. The letters were divided into groups based on the initial width of the letter. But it was more like working with a pixel font in some visual BDF font editor (or like with tiles in the game "15 Puzzle"). Working with conditional "pixels" on a "grid", rather than lines and vectors and other scalable stuff which is more common for .ttf and FontForge.
Also, if a letter will be redrawn with the next theoretical update of the font (redrawing some particularly crafty ideographs is, as I understand it, the only thing that GNU Unifont has been doing in recent years), then its width could theoretically change, which should potentially transfer it to another group, but will go unnoticed during automatic processing. (Although I didn’t touch the hieroglyphs after scaling, since I understand absolutely nothing about them.)
@MayanKoyote, could you provide list of modified glyphs or before/after fonts so I could only bisect slimmed down glyphs.
When we update the default font, it will be necessary to rebuild custom themes' fonts (upd supplementary unifont glyphs), having in memory that they operate on a different fontSize
:
there should be less blurr on UNIFONT with another SDL_ttf rendering method (gmenu2x will detect Family Name as such).
What I always didn't like about the current Default theme (tho I generally like this theme) is how "soapy" the GNU Unifont font looks. So I took a closer look at the size of one "pixel" of the font (that's 64x64 of somethings) and scaled the font by 112.5% so that the size of that one "pixel" became 72x72 (because why not).
As a result, the letters became a bit clearer/sharper (in my eyes):
![03](https://github.com/MiyooCFW/gmenu2x/assets/43220515/06333446-0bc0-411a-98d0-74e7bbaf6d88)
But they also became a bit larger. Therefore, I armed myself with epic patience (FontForge ><) and compressed (manually) the letters of the Russian alphabet (this can be seen in picture No. 2-2).
Now I'm wondering if it's worth continuing. Theoretically, it doesn’t take that long to compress the basic Latin alphabet (and basic punctuation). But as for the extended Latin alphabet, that’s a different story. I would not like to study all the letters, there are too many of them and they are too crafty. Possibly only those that have already been used in existing translations. (Of course, this does not apply to any of hieroglyphs. But they are naturally compact (I think).)
So, is it worth continuing or not?