The mystery of the failing fonts

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Post Reply
Message
Author
User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

The mystery of the failing fonts

#1 Post by MochiMoppel »

In most Puppies clicking on a TTF font file in ROX-Filer will trigger Thunor's pfontview tool, showing a preview of the selected font - maybe.
Back in 2012, when Thunor developed the tool, he received a bug report . The preview of some fonts would display the default Sans but not the designated font. Thunor called them "fonts that gtk/Pango doesn't like" and out of frustration developed sfontview, a better working but less attractive binary. So the buggy pfontview lives on to this date as the default font viewer.

The same issue came up in the recent Font Preview thread. Again many people - including me - scratched their heads and wild theories about the possible cause were discussed.

I decided to take a closer look.
One of my problem fonts is called "Comic Book" and according to the fc-query tools everything looks normal:
  • Pattern has 19 elts (size 32)
    family: "Comic Book"
    familylang: "en"
    style: "Normal"
    stylelang: "en"
    fullname: "Comic Book Normal"
    fullnamelang: "en"
However when I try to open gxmessage with the command
gxmessage -fn "Comic Book Bold 10" Hello
the message text is rendered with DejaVu Sans, not Comic Book. No luck either with "Comic Book 10" or just "Comic Book"

On the other hand a seemingly more complicated
gxmessage -fn "Nimbus Sans L Bold 10" Hello
would work perfectly.

What's going on here?
I found it strange that the GTK font dialog appears to have no problems with my Comic Book and would show a correct preview. Maybe its return values can give a clue?

With yad installed the easiest way to find out is to open a console and type "yad --font". From the resulting dialog I selected family "Nimbus Sans L" with style "Bold"

Code: Select all

# yad --font
Nimbus Sans L Bold 10
Nothing to see here. Looks as expected.

Now the same with "Comic Book" and style "Bold" :

Code: Select all

# yad --font
Comic Book, Bold 10
:!: Noticed something? There is a comma!

Subsequently I tried
gxmessage -fn "Comic Book, Bold 10" Hello
Success! Also "Comic Book, 10" works.
So all we need is a comma after the name! Halleluja! An undocumented feature? Not at all.

According to the Pango documentation
  • "font_name must have the form "[FAMILY-LIST] [STYLE-OPTIONS] [SIZE]", where FAMILY-LIST is a comma separated list of families optionally terminated by a comma, STYLE_OPTIONS is a whitespace separated list of words where each WORD describes one of style, variant, weight, or stretch, and SIZE is an decimal number (size in points). Any one of the options may be absent."
Hmm, rather mandatory in this case and not optional, but when there are no STYLE-OPTIONS, like in a plain "Comic Book", why would I need a comma and why does this not work without a comma?

Pango's documentation can explain this too. Above mentioned WORDs describing the element of STYLE_OPTIONS are defined. Here is a list:
  • Styles:
    normal (same as also recognized 'regular' and 'roman')
    italic
    oblique

    Variants:
    normal
    small-caps

    Weights:
    thin
    ultralight
    light
    semilight
    book
    normal
    medium
    semibold
    bold
    ultrabold
    heavy
    ultraheavy
This means that "Book" is a predefined word and can be part of the STYLE-OPTIONS list that follows the family name. With a font description "Comic Book" Pango would assume that "Comic" is the name and "Book" is the weight. In other words: Pango reads a font description from left to right and assumes everything to be part of the family name until it reaches a comma. When there is no comma it continues until it reaches a word that is in its list of STYLE-OPTION words

Explains also this mystery. A fancy style name like 'R' may be defined in the font, but as long as it is not an official Pango style name Pango will treat it as part of the name. On the other hand Pango doesn't check if an official style name is actually supported by the font. Even a completely bogus style name is OK ("Comic Book, blabla") as long as a comma separates it from the family name. In this case Pango reverts to the font's default style.

Now everything falls into place and can be explained.
A single comma can make all font viewers 100% reliable.

That's all. Have fun!
Attachments
font_syntax.png
(11.38 KiB) Downloaded 214 times

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#2 Post by musher0 »

Thanks.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#3 Post by 01micko »

The fix seems to work in Pfontview too but of course would need further testing.

If you are confident with patch command you can run the following command as long as you save the attached gzipped file to /root

Code: Select all

(cd / ; zcat ~/pfontview-show-correct.diff.gz | patch -p0 )
The gzipped file contains the following:
--- /initrd/pup_ro2/usr/bin/pfontview 2019-06-25 12:17:03.000000000 +1000
+++ /usr/bin/pfontview 2020-06-07 06:04:13.168907237 +1000
@@ -118,7 +118,7 @@ style "styleWhiteBg" {
widget "*WhiteBg" style "styleWhiteBg"

style "stylePreview" {
- font_name = "'"$FontFamily $FontStyle $PreviewFontSize"'"
+ font_name = "'"${FontFamily}, $FontStyle $PreviewFontSize"'"
}
widget "*Preview" style "stylePreview"
'
@@ -239,12 +239,12 @@ funcFontQuery $FontSymlink
funcgtkrcCreate

functmpSet PreviewText "`funcrcGet PreviewText`"
-functmpSet Pangrams '<span font="'"$FontFamily $FontStyle 8"'">'"$i18nPangram"'</span>
-<span font="'"$FontFamily $FontStyle 12"'">'"$i18nPangram"'</span>
-<span font="'"$FontFamily $FontStyle 16"'">'"$i18nPangram"'</span>
-<span font="'"$FontFamily $FontStyle 24"'">'"$i18nPangram"'</span>
-<span font="'"$FontFamily $FontStyle 48"'">'"$i18nPangram"'</span>
-<span font="'"$FontFamily $FontStyle 64"'">'"$i18nPangram"'</span>'
+functmpSet Pangrams '<span font="'"${FontFamily}, $FontStyle 8"'">'"$i18nPangram"'</span>
+<span font="'"${FontFamily}, $FontStyle 12"'">'"$i18nPangram"'</span>
+<span font="'"${FontFamily}, $FontStyle 16"'">'"$i18nPangram"'</span>
+<span font="'"${FontFamily}, $FontStyle 24"'">'"$i18nPangram"'</span>
+<span font="'"${FontFamily}, $FontStyle 48"'">'"$i18nPangram"'</span>
+<span font="'"${FontFamily}, $FontStyle 64"'">'"$i18nPangram"'</span>'

echo '
<window title="'$WINDOW_TITLE'" image-name="'$WindowIcon'"
@@ -264,7 +264,7 @@ echo '
</menu>
</menubar>
<vbox border-width="5" space-expand="true" space-fill="true">
- <fontbutton font-name="'$FontFamily $FontStyle $PreviewFontSize'"
+ <fontbutton font-name="'${FontFamily}, $FontStyle $PreviewFontSize'"
use-font="true" use-size="true" show-size="false" title=""
visible="true" sensitive="true" space-expand="false" space-fill="false">
<variable>ftbBig</variable>
Attachments
pfontview-show-correct.diff.gz
download and place in /root. run above code as root
(632 Bytes) Downloaded 86 times
pfontview-fixed.png
(54.04 KiB) Downloaded 135 times
Puppy Linux Blog - contact me for access

step
Posts: 1349
Joined: Fri 04 May 2012, 11:20

#4 Post by step »

Outstanding explanation, MochiMoppel, thank you for solving the mistery.
[url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Fatdog64-810[/url]|[url=http://goo.gl/hqZtiB]+Packages[/url]|[url=http://goo.gl/6dbEzT]Kodi[/url]|[url=http://goo.gl/JQC4Vz]gtkmenuplus[/url]

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#5 Post by MochiMoppel »

01micko wrote:The fix seems to work in Pfontview too but of course would need further testing.
The fix certainly works, but the weak point is Pfontview itself. Supports only ttf/otf but not Type1 pfb fonts and also no ttc files. Fonts containing ampersands also not supported. IMHO this thing needs a full overhaul , if not a rewrite.

Post Reply