New whitespace between digits and colon in time at top of desktop screen

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command only once, as it will automatically gather debugging information, in a terminal:

  apport-collect 2033377

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

apport information

apport information

apport information

apport information

I've added all the relevant information for you.

Thanks. Can you check to see if it was this upload that caused it?
https://launchpad.net/ubuntu/+source/fonts-noto/20201225-2

This isn't an issue in Lunar which has these packages installed:
```
ubuntu@ubuntu:~$ apt list --installed | grep fonts-noto

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

fonts-noto-cjk/lunar,now 1:20220127+repack1-1 all [installed,automatic]
fonts-noto-color-emoji/lunar,now 2.038-1 all [installed,automatic]
fonts-noto-mono/lunar,now 20201225-1build1 all [installed,automatic]
```
However in Mantic:
```
ubuntu@ubuntu:~$ apt list --installed | grep fonts-noto

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

fonts-noto-cjk/mantic,now 1:20220127+repack1-1 all [installed,automatic]
fonts-noto-color-emoji/mantic,now 2.038-1 all [installed,automatic]
fonts-noto-core/mantic,now 20201225-2 all [installed,automatic]
fonts-noto-mono/mantic,now 20201225-2 all [installed,automatic]
```

Does this suffice?

Status changed to 'Confirmed' because the bug affects multiple users.

Bug confirmed in the live session using mantic 20230829.

It's using LANG=C.UTF-8 which may be relevant?

Changing Settings > Language and Region to Australia fixes the bug, which is why the problem was hidden on my usual machines. So the bug seems to occur in the C and en_US locales.

This feels related, but is not a recent change:
https://gitlab.gnome.org/GNOME/gnome-desktop/-/merge_requests/66/diffs

It looks like the unusual colon character is the default (so used by US and C locales):
https://gitlab.gnome.org/GNOME/gnome-desktop/-/merge_requests/66/diffs#5c873de36a1b57f9c8b16c7fb9cd64292a431fb2_154_156

So is it just how the new Ubuntu font renders the USA time separator?

Is this perhaps a new installer bug? Is the mantic installer failing to apply language and region settings?

I'll double check right now and see if it's an issue with the new installer or also present with the legacy installer and report back in a few minutes.

It's an issue in the live session. I'll report back soon regarding an installed system.

Interestingly enough, with an installed system with the legacy installer, the whitespace is now gone, but again, it does happen in the live session.

How would you like me to proceed?

Perhaps confirm the theory that the bug only occurs when $LANG is set to C.UTF-8 or en_US.UTF-8

With legacy install (live session, with whitespace present):
en_US.UTF-8

With legacy install, after install:
en_GB.UTF-8

Non-legacy install, in install process:
C.UTF-8

Non-legacy install, after install:
en_US.UTF-8

Would I be correct in thinking only the second one in that list is free from the bug?

Sorry, that's my bad, I should've clarified. With the legacy install, the whitespace is gone after install but present in the live session and during install. With the non-legacy installer, it's present all the time.

So it looks like the issue is with C.UTF-8, and en_US.UTF-8, but not with en_GB.UTF-8.

I think this is a consequence of failing to customise region settings, which feels like a recent installer change.

I've asked around and the only feedback I've got has been that failing to customise region settings *is* a bug. But at the same time it doesn't make sense for us to mis-render the colon for US English setups.

This makes sense but like you said, why is it only with specific keyboard setups? Would it not make more sense for it to be a regression in a font package? Anyway, if you need any more testing or logs from me, let me know.

Yes it does feel like a regression in the font package which is why this bug is assigned to that. We should find a way to extract the unicode for the colon being used in US English and see what it looks like in the new font to see if just the new font is to blame.

=====================================
ubuntu@ubuntu:~$ echo $LANG
en_US.UTF-8
ubuntu@ubuntu:~$ printf ':' | iconv -t UTF16LE | od -t x2 -An -v | sed 's/ /\\u/g'
\u003a
ubuntu@ubuntu:~$ printf : | hexdump
0000000 003a
0000001
ubuntu@ubuntu:~$

=====================================
ubuntu@ubuntu:~$ echo $LANG
en_GB.UTF-8
ubuntu@ubuntu:~$ printf ':' | iconv -t UTF16LE | od -t x2 -An -v | sed 's/ /\\u/g'
\u003a
ubuntu@ubuntu:~$ printf : | hexdump
0000000 003a
0000001
ubuntu@ubuntu:~$

The unicode characters are the same. So maybe it's not a font regression?

If I understand correctly the offending character is U+2236 ("RATIO") (UTF-8: e2 88 b6) but that's part of the Unicode Mathematical Operators block for which neither the new or old Ubuntu fonts have any support. So it doesn't make sense to blame this on the Ubuntu fonts.

What I think is happening is:

* en_US and C fall back to some other font which has awkward spacing.

* en_GB and other translations change it to a regular colon in the language-pack-gnome-en and language-pack-gnome-en-base packages.

While this approach seems to be very intentional:

  https://gitlab.gnome.org/GNOME/gnome-desktop/-/merge_requests/66/diffs

I don't think it makes sense for the default locale to be displaying a character that our fonts don't support and will trigger an unpredictable fallback. So I'm going to recommend we just patch this to a regular colon. Annoyingly this needs to be done in multiple locations per translation (.po file) depending on the date/time format a section of code is using.

Status changed to 'Confirmed' because the bug affects multiple users.

Somewhat related:
https://github.com/canonical/ubuntu-desktop-installer/issues/2324

Without that installer bug I wouldn't encounter this bug.

Seems LANG isn't the only factor here. My mantic desktop that was installed months ago and updated daily doesn't have the bug even if I force it to US English. Other machines with fresh mantic installs do have the bug.

Why do they mess with that math symbol in gnome-desktop?

Anyway, the issue surfaced because of the font changes I made. Previously DejaVu Sans was used to render the Ratio character, and now, when the fonts-dejavu-core package is not present, DejaVu Sans Mono seems to be used instead. Hence the extra whitespace.

I uploaded a language-selector change so it uses Noto Sans Math for rendering Ratio.

https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/language-selector/commit/?id=fc7ec106

Thanks Gunnar!

This bug was fixed in the package language-selector - 0.224

---------------
language-selector (0.224) mantic; urgency=medium

  * data/pkg_depends:
    - Pull also fcitx5-frontend-qt6 for Chinese (non-GNOME) users.
  * Prefer Noto Sans Math
    - Makes that font used instead of DejaVu Sans Mono for rendering
      the Ratio character in the clock (LP: #2033377).

 -- Gunnar Hjalmarsson <email address hidden> Thu, 07 Sep 2023 20:30:37 +0200

For the record: The different results depending on locale is a "translation" matter. While the default time separator is \u2236, it has been "translated" for e.g. en_GB in Ubuntu into \u003A:

https://translations.launchpad.net/ubuntu/mantic/+source/gnome-desktop/+pots/gnome-desktop-3.0/en_GB/24

$ printf '\u2236\n'
∶
$ printf '\u003A\n'
:

So with the en_GB.UTF-8 locale it displays a regular colon character, which the Ubuntu font can render.

(Daniel: I can't explain how you hid the issue by using en_AU.UTF-8, though.)

> (Daniel: I can't explain how you hid the issue by using en_AU.UTF-8, though.)

Maybe en_AU inherits from en_GB?

Thanks for the fix Gunnar.

The reason I didn't raise it with you earlier was because I figured a better solution would be to:

 1. Patch to revert to a colon in the default US English translation.

 2. Propose to upstream to not use RATIO in future because fonts don't often implement the Mathematical Operators block.

Looks like it's fixed in today's daily image ! Lovely stuff :)

> 1. Patch to revert to a colon in the default US English translation.
>
> 2. Propose to upstream to not use RATIO in future because fonts don't
> often implement the Mathematical Operators block.

Those were my reflexive thoughts too, especially item 2. But then I saw that RATIO has been used for several years at the request of GNOME's design team, and I don't have the energy right now to argue with those folks. :/