Font doesn't render properly, appears as squares (pango 1:1.44.1-1 breaks font)

[D-Vaillant]

I'm not certain that this is an issue specific to just this font but it's the only one that's been affected from what I can tell.

Other .bdf fonts in the same location render properly, Tamzen appears in fc-list. The font was working fine until I updated some packages through AUR.

[mugman174]

Is the font installed on the client?

[D-Vaillant]

Edited the OP. The font was previously installed properly and should still be installed properly (it's in /usr/share/fonts, I reran fc-cache, other fonts work properly.)

[D-Vaillant]

Okay, I figured it out. Downgrading from pango 1:1.44.1-1 to 1:1.43.0-2 made the font start rendering properly again, so there's definitely something that breaks the font going on there.

[mugman174]

Report that to the pango website.

[ccfb3ee765a58cae]

Tamzen should probably provide bitmap OTFs now that this change has taken place. Seems like the only way forward with the GNOME developer's unnecessary rigidity on this matter.

[pierre-ac]

Bringing back the otb format (dropped in Tamzen-1.11.4) would fix this issue.

[leshow]

Also bit by this, the I don't think that pango considers this a bug and so they aren't going to 'fix' it.

tamzen still renders messed up for me wherever pango is used

[lcpz]

Bringing back the otb format (dropped in Tamzen-1.11.4) would fix this issue.

Unfortunately, the result is ugly. This is the OTB rendering of medium style in sizes 10, 13 and 20:

Seems that size 13 is the template and every other is just a down/upper scale.

I am not a font expert, but I've made a fork for Arch Linux. I hope this could be the start of a full port.

[ghost]

Arch users can work around this as follows

yay -S fonttosfnt

move all the .bdf files into a directory, and run the following script

#!/bin/sh
for file in *.bdf; do
    NAME=$(echo $file | sed -e 's/\.bdf//g')
    echo $file
    echo $NAME
    fonttosfnt -v -o $NAME.otb -- $file
done

Now you have the .otb files. Install as usual (copy to the correct folder, then run fc-cache -f)

I don't really have time to figure out the build system for this project, so if someone else wants to do that and put together the pull request I've at least verified that it can be done. (probably better than creating a fork, as the AUR package builds from this repo)

[ghost]

I would add that presently it looks like Alacritty can render these otb files correctly, but pango doesn't. It looks like pango is adding 1 pixel more between characters than it should. sigh

[sunaku]

Thanks @j-n-f , I've applied your suggestion in the issue-25 branch and also added the generated *.otb files there (under otb/ folder). Please try it out and let me know if you find any problems.

[sunaku]

@D-Vaillant could you help verify? :innocent: There is only Pango 1.42 available in the distro I use (Void Linux).

[D-Vaillant]

I’ve been using it and it works so far; I can check version specifics in a bit. LightDM isn’t liking the font still but I’ll figure out why.

On May 8, 2020, at 12:59, Suraj N. Kurapati notifications@github.com wrote:

 @D-Vaillant could you help verify? 😇 There is only Pango 1.42 available in the distro I use (Void Linux).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[sunaku]

Thanks for confirming. I also tested this locally and found that the old Pango 1.42 supports it too. :heavy_check_mark:

These fonts are now merged into master at commit 7477526d941c25962c30a2493cf55557cc18e987. Closing.