[Pkg-fonts-devel] Bug#974537: Bug#974537: fonts-noto-core: Fallback font selection changed and incorrect glyph displayed

[Jonas Smedegaard]

Hi astian,

Thanks for a detailed bugreport!

Quoting astian (2020-11-11 21:31:00)
> With version 20200323-1, when attempting to render code points such as 
> 0x3001 and 0x3002, fontconfig would choose "Noto Sans CJK JP" [0] as 
> fallback for "Monospace".  This was expected behaviour, I want to see 
> Japanese punctuation glyphs.
>   0: /usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc
> 
> Binary packages for version 20200323-1 seem to be gone from the archive
> but version 20181227-1 also shows the wanted behaviour.

Some are here: https://snapshot.debian.org/binary/fonts-noto-core/


> After updating to version 20201027-3 and later also 20201109-1,
> fontconfig chooses "Noto Sans Mongolian" [1].  This results in
> unintended glyphs.
>   1: /usr/share/fonts/truetype/noto/NotoSansMongolian-Regular.ttf

I understand that this changed.  But is it a bug?  I mean, is it 
universally preferred to use Japanese over Mongolian for those 
characters?


> STR:
> 
>   a) Run:
>        $ LANG=en_US.UTF-8 pango-view --font monospace -t $'\u3001'
>      Or even:
>        $ LANG=en_US.UTF-8 pango-view -t $'\u3001'

Oh, that's a neat way to render unicode characters, didn't know that 
one.

Failed for me at first, however, so here is another little trick: locale 
en_US.UTF-8 is not generally enabled, but locale C.UTF-8 is.


>   b) Run:
>        $ fc-match --sort monospace family style file | grep -i -e cjk -e mongo
>      Or even:
>        $ fc-match --sort : family style file | grep -i -e cjk -e mongo




> Expected behaviour:
> 
>   a) The pango-view window shows the Japanese comma glyph (see for
>      example "Noto Sans CJK JP" in fontforge).
> 
>   b) A Japanese font is preferred:
>        Noto Sans CJK JP:style=Regular:file=/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc
>        Noto Sans Mongolian:style=Regular:file=/usr/share/fonts/truetype/noto/NotoSansMongolian-Regular.ttf
> 
> Actual behaviour:
> 
>   a) The pango-view window shows a different glyph (from "Noto Sans
>      Mongolian").
> 
>   b) A Mongolian font is preferred:
>        Noto Sans Mongolian:style=Regular:file=/usr/share/fonts/truetype/noto/NotoSansMongolian-Regular.ttf
>        Noto Sans CJK JP:style=Regular:file=/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc

When I try the above with packages in unstable as of today, I get what 
looks to me as the comma glyph, even though fc-cache indeed shows 
Mongolian as prioritized.


> This looks like a regression and it is one for me, but I guess it 
> could also be a configuration issue involving fontconfig.  I have no 
> custom fontconfig configuration, though, so if somehow this is not 
> considered a regression, perhaps you could recommend a configuration 
> that would restore the previous behaviour for me?

Sorry, I am not clever with fontconfig and the fonts-noto-core package 
includes only a small configuration related to older name Droid: 
/etc/fonts/conf.avail/30-droid-noto.conf

I notice that package fonts-noto-cjk ships a more extensive 
configuration seemingly related to identifying as "monospace": 
/usr/share/fontconfig/conf.avail/70-fonts-noto-cjk.conf

Perhaps it helps to edit that CJK configuration to add binding="strong" 
also to the monospace sections?

Please to report back if that helps, and whether or not you think this 
is universally a preferred setup or we should perhaps introduce some 
flexibility in these packages - i.e. a mechanism to let Mongolians 
prioritize their glyphs and let Japansese prioritize theirs.


Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-fonts-devel/attachments/20201112/4fd6c10b/attachment.sig>