Confusion concerning 3270Medium.ttf spacing=100/ monospace

[ckoe-bccms]

Hello,

I was experimenting with the fonts build from source on debian 9 (stretch), ubuntu 16.04 and ubuntu 18.04 and there is something I do not understand.

Apparently "fc-list :spacing=100" does no longer recognize 3270Medium.ttf and 3270Medium.otf as monospaced fonts ? However, the Narrow and Semi-Narrow variants show up. This appears to be also the case with the fonts from 3270_fonts_4cfe95c.zip.

The 3270Medium.ttf and 3270Medium.otf files from older versions of these fonts I obtained in 2017 (3270_fonts_b3b4b7d.zip) or those from the ubuntu packages (fonts-3270, versions 1.2.11-1 and 1.2.20-1) are listed just fine using "fc-list :spacing=100" .

Probably unrelated to that: But I am also observing a spacing issue with this font when using rxvt-unicode on the debian system. The spacing is much to wide, just as I observe when using a proportional font. Narrow/ Semi-Narrow variants are apparently ignored, there is no change in terminal width. When adjusting the spacing manually "urxvt -letsp -4 -fn "xft:IBM 3270 Narrow:size=14" is needed for a spacing which is basically identical to what an xterm does for the same size. I am not sure where this might come from. On ubuntu with similar urxvt and freetype versions this appears to be fine.

And of course: Thank you very much for making the font available !

Best Regards

Christof

[rbanffy]

Can you attach a screenshot?

[ckoe-bccms]

Hello.

I assume you want a screenshot of the urxvt rendering ? Then please see the attachement. The white-on-black terminal in the background is an xterm with invocation xterm -fa "IBM 3270 Narrow" -fs 12. The black-on-white terminal in the foreground is the urxvt (rxvt-unicode (urxvt) v9.22 - released: 2016-01-23) from debian stable with invocation urxvt -fn "xft:IBM 3270 Narrow:size=12". Please disregard the yellow-on-black terminal with the gimp output in the background.

My .Xresources is

Xft.lcdfilter: lcddefault
Xft.antialias: true
Xft.autohint: 0
Xft.hinting: true
!Xft.hintstyle: hintmedium
Xft.hintstyle: hintnone
Xft.rgba: rgb
Xft.dpi: 131
!URxvt.letterSpace: -5
!URxvt.font: xft:IBM Plex Mono:style=Light:size=11,xft:DejaVu Sans:size=11
!URxvt.font: xft:Liberation Mono:size=11,xft:DejaVu Sans:size=11

In the meantime (note my experimenting with the Liberation Mono font above) I believe that the issue is with this particular urxvt debian build. Compared to the xterm rendering the Liberation Mono is also spaced too wide so that I set "-letsp 2" for it.

Best regards

[rbanffy]

Do you think some attribute in the font could be triggering the behavior in urxvt? The font is published as Type A, TTF and OTF. Can you see if other formats trigger the same behavior?

[ckoe-bccms]

Hello !

I tried to test this by first cleaning out my .fonts and then extracting the ttf, otf, woff and pfm versions from 3270_fonts_4cfe95c.zip individually and starting urxvt with each of them. It does apparently not make a difference which format is used.

One thing I noticed (here all are extracted):

~/.fonts % ls
3270Medium.afm   3270Narrow.afm  3270Narrow.woff     3270SemiNarrow.ttf
3270Medium.otf   3270Narrow.g2n  3270SemiNarrow.afm  3270SemiNarrow.woff
3270Medium.pfm   3270Narrow.otf  3270SemiNarrow.g2n  LICENSE.txt
3270Medium.ttf   3270Narrow.pfm  3270SemiNarrow.otf
3270Medium.woff  3270Narrow.ttf  3270SemiNarrow.pfm

but

fc-list -f "%{family} : %{file}\n" :spacing=100|grep 3270|sort
IBM 3270 : /home/ckoe/.fonts/3270Medium.pfm
IBM 3270 Narrow : /home/ckoe/.fonts/3270Narrow.otf
IBM 3270 Narrow : /home/ckoe/.fonts/3270Narrow.pfm
IBM 3270 Narrow : /home/ckoe/.fonts/3270Narrow.ttf
IBM 3270 Narrow : /home/ckoe/.fonts/3270Narrow.woff
IBM 3270 Semi-Narrow : /home/ckoe/.fonts/3270SemiNarrow.otf
IBM 3270 Semi-Narrow : /home/ckoe/.fonts/3270SemiNarrow.pfm
IBM 3270 Semi-Narrow : /home/ckoe/.fonts/3270SemiNarrow.ttf
IBM 3270 Semi-Narrow : /home/ckoe/.fonts/3270SemiNarrow.woff

So in fact the Medium version is found in the pfm format, but as in the inital report all other other formats do not show up for Medium.

Thank you !

[rbanffy]

There was an issue with the base version - it had a glyph that was wider than the rest. I fixed it and will add a check to the CI tests so it never happens again. I uploaded a new set that has all glyphs at the same width.

BTW, is there a command line option to load the font so I can more easily duplicate your urxvt strangeness?

[ahktenzero]

This issue appears to be back in 3270_fonts_6086dd2.zip, fc-query shows no spacing attribute on the medium style but does on the other two. It looks like the new glyphs added in that commit have a different width to the others.

[ckoe-bccms]

Hello everybody !

@rbanffy thank you very much for fixing the monospace detection problem.

For reproducing the rendering issue I would suggest the following procedure
which I hope you can use. This also contains the answer to your question regarding the
urxvt command line option. Interestingly, now the xterm also shows the
same effect, so this might be freetype related ? Anyway:

I downloaded a recent debian 9 live cd, i.e.
debian-live-9.9.0-amd64-xfce.iso. This runs fine in virtualbox for me or
from any other boot medium. In the running live system then do

sudo apt update; sudo apt install rxvt-unicode-256color fonts-3270

If you start now an urxvt and xterm using

urxvt  -fn "xft:IBM 3270:size=10"
xterm -fa "IBM 3270" -fs 10

as indicated in the attached screenshot you should see the correctly
rendered fonts. Now to demonstrate the problem remove the fonts-3270 package
with

sudo apt remove fonts-3270

Make a new ~/.fonts directory, download the 3270_fonts_6086dd2.zip from
aws and extract it into ~/.fonts.
I removed everything except the otf versions, the debian package
contains the otf versions only. If you now start the terminals with the
same command as above you should see the difference. A secons screenshot
is attached.

I hope this provides a better starting point for diagnosing what is
going on.

Please let me know how I can provide further assistance !

[rbanffy]

Thank you - this helps a lot. I'll look into this as soon as I can,

[rbanffy]

The install target on the Makefile copies the .otf files only. Can you check again with that,
@ckoe-bccms ? It could be something in one of the derived files. The latest build off develop is at https://3270font.s3.amazonaws.com/3270_fonts_b218121.zip

[ckoe-bccms]

Hello @rbanffy ,

I tried it with the zip file extracted into ~/.fonts and building from git head which then installs fonts into ~/.local/share/fonts (I cleaned up ~/.fonts before). I hope that is what you asked me to do, if not please clarify.

I see no change with the urxvt, but the xterm now appears to render correctly. The screenshots are attached. I might be interesting to try with a recent ubuntu and eventually fedora LiveCD again, I will post the result. What do you use the fonts with ? As I wrote earlier I suspect that the problem is the terminal application or freetype.

As a side note: generate_sample_image.py would not work for me. python-pil is installed but it gives

from PIL import Image, ImageDraw, ImageFont
ImportError: No module named 'PIL'

I read on the web that the module name might be different, but did not investigate further. I simply commented it out in the Makefile.

[ckoe-bccms]

Hello again,

testing on fedora 30 was a lot easier than I expected. I also tested ubuntu 19.04. In both cases I used the 3270_fonts_b218121.zip as before with the same terminal invocations as before. As you can see the xterm (in the upper half of the desktop) appears to be fine while urxvt still is too wide.

Thank you again for your help !

[rbanffy]

Could it be that xterm and urxvt are opening different font files?

[ahktenzero]

Regarding the spacing in URxvt, I had the same problem ages a while back when I started using this font but I found a workaround. I believe it's down to differences in the way URxvt calculates the width of the characters rather than anything in the font. There's some discussion about this linked in the Arch wiki on URxvt.

There are options to alter the letter spacing URvxt uses, either setting URxvt.letterSpace X resource or adding the -letsp option to the command line. I use -2 pixels for 12pt text at 93dpi, you will probably need to experiment a bit to find the optimum for your setup.

[ckoe-bccms]

Hello everybody,

sorry for the delay. I could not re-test the font as suggested by @rbanffy yet, but I assume that it is not the problem.

I agree with @ahktenzero that it is probably some problem or feature with urxvt. I used the suggested "-letsp -4" workaround, see my initial report. However, at that time the situation appeared to be inconsistent across different operating systems and on top the monospace property was not detected properly with newer versions (this appears to be fixed). All in all it was a bit confusing.

Let me re-test on ubuntu 16.04 and inside a VM with only one font file format present, I will report back with that information.

Thank you very much for your help !

[ckoe-bccms]

Hello,

sorry for the delay !

I re-tested this now on a fresh fedora 30 workstation live cd in virtualbox. According to the output of "locate" (after running updatedb as root) there is no IBM 3270 font installed in the base image. I the installed again xterm and the rxvt-unicode-256color packages, extracted the fonts from the ...2851f93.zip into ~/.fonts, deleted everything but the otf-versions. Starting urxvt (i.e. rxvt-unicode-256color) and xterm with the font using command line options shows the expected result. Font rendering is too wide with urxvt compared to xterm matching the screenshots posted earlier.

I then tested an ubuntu 16.04.6 desktop live cd with the same method as above and with the same result.

So, if I did not fetch a completely outdated zip-file this did not change.

Now, if @rbanffy thinks that it is likely not the font itself which causes this (when I filed the bug report this was not clear because of the problem fc-list had to detect all variants as monospace) I would try to open a bug report against rxvt.

Thank you again for your help !

[rbanffy]

I think that until this happens with other fonts, 3270font can't be exonerated. It could be font metadata or some other data within the font that triggers misbehavior, but I still need to figure this out.

[rbanffy]

I believe we can put this one to rest now - I added a urxvt rendering test (the way it failed to run a shell script with -e got me stuck for a while) and it seems fine, at least on my Ubuntu box.

[ckoe-bccms]

Hello,

I did not re-test recently with a current font version. This looks fine indeed.

Thank you very much for your effort in reproducing this !

[siflfran]

Just tested this on Debian 10 with fd00815. The problem still exists, ibm3270, 3270 Condensed and 3270 Semi-Condensed are rendered with too much space between letters, passing -letsp -4 to urxvt works around the issue.

[rbanffy]

Thank you. I added urxvt to the rendering test screenshots in hopes to understand what happens.

…

On Thu, Mar 11, 2021 at 10:56 AM siflfran ***@***.***> wrote: Just tested this on Debian 10 with fd00815. The problem still exists, ibm3270 and 3270 Condensed and 3270 Semi-Condensed are rendered with too much space between letters, passing -letsp -4 to urxvt works around the issue. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or unsubscribe.

-- Ricardo Bánffy http://about.me/rbanffy