3270font
3270font copied to clipboard
rbanffy
Some letters rendered weirdly when using the OTF and WOFF files
Look at the uppercase W and lowercase p in Workspace. It is more obvious in Backups, the p is lower than the following s.
urxvt:
xterm:
All letters:
BTW，I remember there was no such issue in the previous releases back in 2016 when I first started to use this font. There is no problem with the Nerd patched 3270 font either (I don't know which release of 3270 that the Nerd patch was applied to).
What OS and version of the font are you using? I ask because I added a couple test renderings using some popular terminal programs recently (running on Ubuntu) and none of them show this behavior.
There is no problem for all the previous releases with font files named "3270Medium", "3270Narrow" and "3270SemiNarrow", although they have wide letter spacing issue in urxvt which could be fixed by setting the letterSpace option.
This issue comes with '2.0.3' release in which font files were named "3270-Regular", "3270Condesed-Regular" and "3270SemiCondensed-Regular".
The official Nerd patched font uses 1.2.23 version.
By "latest" do you mean "latest Debian Sid package", "latest source or binary release", or "built from source from the develop branch"?. If you can do it, run a make uninstall clean install samples to generate some terminal screen captures so we can get a better idea of where the problem is - the font may be lacking some attribute to help align the characters). The resulting captures should end up in your build folder. The spacing issue in urxvt may be the same in #49 and, if it persists in Debian Sid with the newest build, it may be a Debian-specific issue.
The "latest" means the latest release from your Github Releases page, which is tagged v2.3.0. Since v2.0.3, the urxvt spacing issue has gone, but the character distorting issue does come with v.2.0.3. Since the spacing issue can be simply worked around by setting letterSpace, I've switched back to using v.2.0.2 release. Next week would be pretty busy for me, but I will try to find some time to have a try if it would really help.
Thank you. I am generating screen captures under Ubuntu and macOS (which are the two desktops I have on hand) and maybe I can generate some under Fedora 33, but I have no Debian Sid box ready so it'd be really helpful. I'll flesh out the contributing instructions and, with some luck, we may get other Debian users on different releases willing to give a hand. I have a feeling I may be exposing some information that throws off some font renderers and not others. Debian Sid is a good one to test against because it shows symptoms before they hit any major distro.
make sample reports:
make: terminator: No such file or directory
make: *** [Makefile:44: sample] Error 127
and gnome-screenshot not found. I only see ./build/3270_sample.png, what files do you exactly need?
But I found some thing interesting that only OTF format has such issue. make install installs the TTF format and everything (glyph rendering, spacing) looks good.
Interesting. It may be something with just the OTF export then. Explains a lot since all the test renderings are being done with the TTF one.
Worth noting this could be related to pixel size. A magazine in Brazil seem to have used the OTF version on their cover at a very large size.
I changed the sample rendered to use TTF, OTF and WOFF. Not sure if it's the font file or the rendering, but OTF and WOFF look considerably worse.
Other examples (from programmingfonts.org)
14 pt
17 pt
At multiples of 10, the issues mostly disappear
I see the same problems (like "h" above baseline, overly-large "5", etc.) when using the OTF fonts on Linux Mint 21.2/Cinnamon. De-installing the OTF and installing the TTF fixed it immediately.
I see the same problems (like "h" above baseline, overly-large "5", etc.) when using the OTF fonts on Linux Mint 21.2/Cinnamon. De-installing the OTF and installing the TTF fixed it immediately.
I think that stopping support for OTF is the way to go here until I figure out what is the issue (I blame FontForge, but need to run more experiments before I can be sure).