“ERROR, "maybe overlapping" when using custom bdf fonts
caonimah opened this issue · comments
I am really excited to get to know this piece of wonder. I have been looking for a terminal emulator without x, but with unicode and 256 color support for a long long time. ありがとうございます!
Playing with it since yesterday, I find it generally functioning very well. The only problem I ran into was icon and cjk font display. The only Chinese font I got to work correctly was the wenquanyi-unibit. However, if I generate a custom bdf by myself using pcf2bdf or ttf2bdf, it will produce the "ERROR maybe overlapping". I have tried NotoSansCJK SC, FontAwesome (for icons) and a bunch of other random fonts, the results were always the same.
Any suggestions of what might be the cause of the problem? Sorry that I am not a hard-core C programmer myself ...
BTW, the link to the dina font in glyph_builder.sh seems to be broken. Package not found. I don't know if it is just for me. Other fonts I have tried there so far worked pretty well.
Thank you.
Thank you for your feedback.
Playing with it since yesterday, I find it generally functioning very well. The only problem I ran into was icon and cjk font display. The only Chinese font I got to work correctly was the wenquanyi-unibit. However, if I generate a custom bdf by myself using pcf2bdf or ttf2bdf, it will produce the "ERROR maybe overlapping". I have tried NotoSansCJK SC, FontAwesome (for icons) and a bunch of other random fonts, the results were always the same.
Any suggestions of what might be the cause of the problem? Sorry that I am not a hard-core C programmer myself ...
You can combine several bdf fonts only If those fonts size are exactly the same. for example, mkfont_bdf cannot convert from 8x16 font and 8x15 font to one bdf font. and monospace fonts are only available.
I think it's a bit difficult to generate currect font for yaft. So I need to make glyph generation process more easy.
BTW, the link to the dina font in glyph_builder.sh seems to be broken. Package not found. I don't know if it is just for me. Other fonts I have tried there so far worked pretty well.
Original Dina font site is currently unavilable. I'll search another mirror site and fix glyph_builder script.
Fixed dina font problem at 96ea427
Monospace Fonts
and monospace fonts are only available.
I actually noticed this requirement in the makefile before I started playing with it. However, in retrospective I realize that this kind of font topic, especially when CJK fonts are involved, is much more complicated than I expected.
For instance, I thought all Kanji fonts are, due to their nature, inherently "monospace". Nevertheless, I forgot that the latin characters and other symbols included there can be NON-monospace ...
So the next thing I tried was Noto Sans Mono CJK SC, which theoretically should work, but in reality didn't. The reason is that the bdf font I generated from ttf has a minus bbx, so that it can't pass the test in shift_glyph() in bdf.h. And that was also the reason why many other fonts I tried didn't work. I also tried Hanazono Mincho, but also failed due to the non-Kanji parts.
In general, I find it very frustrating to generate a usable bdf font from ttf/otf formats, at least with my current knowledge.
Conversion ttf -> bdf
The temptation of using all those fancy ttf fonts readily available on the market is big. So the first thing I tried to do was to generate bdf from ttf. Another reason was that I couldn't find many pcf or bdf fonts with CJK support.
Here is how I do the conversion
otf2bdf -r 96 -p 12 -c W -l "12352_12543 19968_40689" /path/to/font.ttf -o /path/to/font.bdf
otf2bdf (almost the same as ttf2bdf) seems to be pretty much the only simple tool out there. I can adjust the dpi (-r) and point size (-p) to control the final bitmap font size. However, this kind of manual trial & error is very imprecise and painful. And I just can't get the desired font size of 16x16 no matter how I change the parameter. The closest I could obtained was 16x17 ...
I know this must be a dumb method to do the job. If anybody knows a better alternative, please say.
Bitmap Font Bounding Box
You can combine several bdf fonts only If those fonts size are exactly the same.
I also read this instruction in readme and makefile, but still ran into difficulties. My problem is the following. I want to combine the CJK part of the Wenquanyi Unibit font with the Latin characters and symbols from Tamsyn8x16r. It seems that both have a height of 16, so it should work (??)
FONT -wenquanyi-unibit-medium-r-normal--16-160-75-75-C-80-iso10646-1
SIZE 16 75 75
FONTBOUNDINGBOX 16 16 0 -4
However, from the generated glyph.h I find out that CELL_HEIGHT=18 for the wqy-unibit, therefore these two fonts can't be combined, although both work perfect if compiled individually. But why a 16x16 font has been recognized as 8x18, is something I have yet to understand.
Unicode Icons not possible?
Finally, I did a quick & dirty hack by padding zeros to the glyph bitmap, because i) I just want to confirm that it can actually work and ii) I am eager to see how it looks like in action.
Generally speaking, I want to combine a western good-looking terminal font with a pan CJK font with ALL Kanji, as well as Hiragana and Katakana. Ideally, it can also display fontawesome icons or similar. But it seems that those icons are not monospace, so I can't find a way to make it work.
And here is how far I can go at the moment, with Tamsyn combined with Wqy-Unibit:
Black bar at the bottom
After playing with the color a little bit and applied a base16 dark scheme, I noticed that there is a black bar at the bottom of yaft. And after a few comparing experiments, I can confirm that this only happens when CJK fonts are compiled. What could be the cause of this issue? The font height is 18, not 16. Does that matter?
Thank you for reply.
I'm verry sorry for you to suffer from yaft font problem.
So the next thing I tried was Noto Sans Mono CJK SC, which theoretically should work, but in reality didn't. The reason is that the bdf font I generated from ttf has a minus bbx, so that it can't pass the test in shift_glyph() in bdf.h. And that was also the reason why many other fonts I tried didn't work. I also tried Hanazono Mincho, but also failed due to the non-Kanji parts.
mk_font_bdf does not work for some bdf fonts even If the font is monospaced. Maybe something wrong with code. I'll check it.
otf2bdf (almost the same as ttf2bdf) seems to be pretty much the only simple tool out there. I can adjust the dpi (-r) and point size (-p) to control the final bitmap font size. However, this kind of manual trial & error is very imprecise and painful. And I just can't get the desired font size of 16x16 no matter how I change the parameter. The closest I could obtained was 16x17 ...
If ttf/otf font doesn't have embedded bitmap, it's very difficult to convert from ttf/otf to bdf correctly. And yaft doesn't have antialiasing functionality, so rendering will be dirty.
However, from the generated glyph.h I find out that CELL_HEIGHT=18 for the wqy-unibit, therefore these two fonts can't be combined, although both work perfect if compiled individually. But why a 16x16 font has been recognized as 8x18, is something I have yet to understand.
Maybe bug..., I'll fix it.
Unicode Icons not possible?
If font exists and glyph's codepoint is between U+0000 ~ U+FFFF (yaft supports only Unicode BMP), you can use it.
Black bar at the bottom
If your display resolution is 16x18 (unreal value I know) and font size is 16x16, yaft draw nothing at 2 pixels on bottom.
I'm very sorry for you to suffer from yaft font problem.
I think, if someone in 2018 still voluntarily installs a framebuffer terminal, he is ready to suffer. If he installs it on a Gentoo machine, then he is willing to suffer even more ;)
In my experience, the greatest of obstacle for a normal user to embrace pure software minimalism and do things in the good unix way, is the big knowledge gap between them and the devs.
It is absolutely understandable that an open source developer won't have the time to write up everything and provide detailed beginner tutorials. On the other hand, it would be really helpful if the developer would just put some links to external online resources or keywords of man page about the relevant topics. Concerning this project, for instance, some introductory reading materials about linux framebuffer and fonts would be nice.
Furthermore, I always find it extremely insightful to see how the developer himself uses the tool. At the bare minimum, even merely a few keywords about the major software involved in his workflow would be tremendously helpful. Because many minimalistic software can only shows its real power in combination with other tools. But people who are new to this topic don't know that yet, that's why they ask how to copy paste, how to have tab and multi window support etc.
Here is another question which puzzles me for a long time. How can I type Chinese or Japanese in a terminal without X window system? All those usual input methods seem to require graphical interface (??) EDIT: OK, now I see your answer would be yaskk. I will check it out.
Yes, I'm using yaskk at the moment.
For Japanese text input, there are some choices without graphical environments:
- sentimental-skk (written in python)
- eskk (written in vim script)
- ddskk (written in elisp)
- and yaskk