[Pkg-fonts-devel] fonts-motoya-l-cedar vs. trixie?

[Cyril Brulebois]

Hi/やあ,

It took me much longer than planned before getting back to the buggy
Japanese support we've been having in the graphical installer. Long
story short, Unicode is definitely *not* helping in this particular
area[1], and we end up having weird characters[2] when the Japanese
language is picked up.

  1. https://en.wikipedia.org/wiki/Han_unification
  2. https://heistak.github.io/your-code-displays-japanese-wrong/

Kentaro-san worked on this a lot, teaching us about the issue, proposing
solutions, even exploring ways to keep the size increase to a minimum.
You'll find a number of discussions in the bug report and on the main
merge requests (a number of others have been opened while exploring
ideas):

  https://bugs.debian.org/1037256
  https://salsa.debian.org/installer-team/rootskel-gtk/-/merge_requests/5

I've come back to this topic lately and it looks like sticking to the
MotoyaLCedar font is the best compromise (not as nicely-looking as BIZ
UDPGothic, but much smaller!).

At the moment, I'm using a trick on the debian-installer side to get
this font embedded without the usual “font ships a udeb, d-i lists it,
and boom”:

  https://salsa.debian.org/installer-team/debian-installer/-/commit/ee21b57e30138b044245fe2f7394a942dfec6945
  https://salsa.debian.org/installer-team/debian-installer/-/commit/7aedbaf6cee3abb3333fe146536febea624f21ec

If the addition of a fonts-motoya-l-cedar-udeb would be acceptable, this
would be much slicker:

  https://salsa.debian.org/installer-team/debian-installer/-/commit/c3773974bbd99935f3ed7a9c0f8cb6eb05e2184a

Kentaro-san adjusted the proposed udeb addition following some remarks
of mine, and I've confirmed that the clean approach would work as well
as the dirty one (runtime-wise); as a nice bonus, we get the package
registered in Built-Using just like other font udebs.

If Hideki-san agrees, this could look like this:

  https://salsa.debian.org/fonts-team/fonts-motoya-l-cedar/-/merge_requests/1

The package was last uploaded in 2019, has been in sync between
unstable and testing ever since, and a udeb addition shouldn't
interfere with anything else (that I can think of).


Release team, do you prefer enforcing the no new package rule (which
has been active for many weeks already), and our sticking to the dirty
approach? Or would you be open to having the udeb addition reach trixie
so that things are a little cleaner?

In hindsight, we could have requested an extra udeb for each candidate
font, but I usually prefer coming up with a plan instead of brute
forcing my way through…

I'd totally understand either answer, I know we're way past due
already… I'd just hate not asking after all the time spend on
preliminary work and testing.

Thanks for your time.


Cheers,
-- 
Cyril Brulebois (kibi at debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-fonts-devel/attachments/20250525/3c9fd76c/attachment.sig>