Non-latin fonts don't display properly in notifications

marcos-morar · December 23, 2025, 4:42pm

Previously, notifications were handled by their respective qubes, and installing non-latin fonts in those qubes resolved the issue. But now that notifications have become centralized, do we need to install fonts in dom0?

alimirjamali · December 23, 2025, 4:53pm

Sadly by design the new notification daemon/agent eats & replaces a large subset of Unicode characters which are known for security issues (I can provide link to source if needed).

If showing notification with those characters is essential, the best bet would be deleting qubes-notification-agent from template(s) which should show such text like r4.2.x

marcos-morar · December 23, 2025, 5:09pm

Not essential, but having question mark style symbols instead of the actual Unicode characters looks ugly.

alimirjamali · December 23, 2025, 5:34pm

I personally agree. Currently it shows U+FFFD unicode character (�). I would have preferred question mark (?) or even a text suggestion the message contained unicode characters with security issues.

Or even better, I would have preferred this was configurable.

marcos-morar · December 23, 2025, 6:03pm

So the bottom line is, either we have to decentralize notifications again or put up with the ugly question-mark placeholders.

alimirjamali · December 23, 2025, 6:09pm

There is a 3rd way. Compiling notification proxy with filters removed for specific characters you need

It is here:

github.com/QubesOS/qubes-notification-proxy

src/lib.rs

main


      
          if validate_code_point(c.into()) || c == '\t' {
              counter += 1;
              c
          } else if c == '\n' {
              counter = 0;
              lines += 1;
              c
          } else if c == '\r' {
              if iter.peek() == Some(&'\n') {
                  continue;
              }
              counter = 0;
              lines += 1;
              '\n'
          } else {
              // This is U+FFFD REPLACEMENT CHARACTER
              counter += 1;
              '\u{FFFD}'
          },

marcos-morar · December 23, 2025, 6:47pm

It means no third option

alimirjamali · December 23, 2025, 6:53pm

Such an irony that the notification pop-up ate emoji.

But seriously talking, if you open an issue about this (to allow a subset of characters based on user config), I might work on it in long run. It could be done at notification proxy level (which is written in Rust)l or at libqubes-pure level (which is written in C language).

marcos-morar · December 24, 2025, 1:54pm

I’ve opened the issue: #10495

marcos-morar · December 27, 2025, 6:28am

@alimirjamali if I delete qubes-notification-agent from templates, what are the drawbacks?

And if I delete this package from a single template, then only App qubes of that template will display decentralized notifications and all others will remain the same right?

alimirjamali · December 27, 2025, 9:59am

Yes. It should be like this.

It should be also possible to disable qubes-notification-agent for a single AppVM. But I have not studied that much detail.

marcos-morar · December 27, 2025, 12:23pm

By removing qubes-notification-agent, notifications don’t display at all.

In whonix-workstation-18 template, attempting to remove this package via apt remove also tries to remove dist-qubes-gui-all and whonix-workstation-qubes-gui-lxqt.

So, I used dpkg --remove --force-depends qubes-notification-agent instead.

but It broke the package, now when I try to install notification-daemon, system ask me to run apt --fix-broken install to re install qubes-notification-agent.

So it seems I didn’t properly removed the package. The solution in fedora is pretty straight forward by using dnf remove --no-autoremove parameter. Is there any such thing for apt?

marcos-morar · January 1, 2026, 5:51am

No workaround @alimirjamali ?

alimirjamali · January 1, 2026, 8:33am

Sorry for delayed reply. I will look at it.