Open donmor opened 1 year ago
Looks like Fvwm uses Unicode16BE to fetch characters from an iso10646 pcf font. But according to the log, it was trying to convert UTF-8 to ISO8859-1.
@donmor -- Are you setting BugOpts TransliterateUtf8 On
at all?
Setting BugOpts TransliterateUtf8 On doesn't work at all :(
Hi @donmor
Can you check the latest main
branch, to see if this is still an issue? There's been some font changes made there, and I wonder if this is fixed.
Upfront Information
Expected Behaviour
I'm testing Fvwm these days. I installed
fonts-unifont
andxfonts-unifont
in my environment and set unifont ttf font as the default font of Fvwm, and it works fine. Then I changedDefaultFont xft:Unifont:Medium:size=12
toDefaultFont "-gnu-unifont-*"
and restarted Fvwm, expecting the unifont pcf font work as well.Actual Behaviour
All characters on Fvwm parts messed up. For example,
Restart
was rendered as剥獴慲
. I also tried other pcf fonts that ends up with-iso10646-1
, and Fvwm renders characters as either texts that messed up or dozens of block (so-called tofu).Logging
I found these repeatly in the log file:
Steps to Reproduce
xfonts-unifont
DefaultFont "-gnu-unifont-*"
into it.This also happens with Fvwm2. Actually I'm testing with Fvwm2 from debian repository before, and later installed Fvwm3 from source to check if the problem still exists.
Here's the profile (comments removed to reduce size):
Does Fvwm3 crash?
No. It just render weird characters.
Extra Information
Restart
is52,65,73,74,61,72,74
in bytes, and剥獴慲
is u+5265, u+7374 and u+6172, tossing the last "t" away. And if the source string contains unicode characters, the corresponding parts of rendered bytes gets completely messed up and becomes unrecoverable.