GNU bug report logs - #78461
[PATCH] gnu: font-iosevka: Update to 33.2.2, switch to "Super TTCs".

Previous Next

Full log

Message #14 received at 78461 <at> debbugs.gnu.org (full text, mbox):

From: Hilton Chain <hako <at> ultrarare.space>
To: Andrew Wong <wongandj <at> icloud.com>
Cc: 78461 <at> debbugs.gnu.org, 宋文武 <iyzsong <at> envs.net>
Subject: Re: [bug#78461] [PATCH] gnu: font-iosevka: Update to 33.2.2, switch
 to "Super TTCs".
Date: Sun, 18 May 2025 14:27:31 +0800

Andrew Wong via Guix-patches via <guix-patches <at> gnu.org> writes:

> On 5/17/25 6:32a, Hilton Chain wrote
>> Can you clarify why switching to ‘Super TTC’?  I don't think we have
>> issue managing font files.
>
> The 'Super TTC' format is recommended for desktop use upstream[1], and 
> it ostensibly saves disk space; we already package Iosevka as TTCs, 
> which implies a desktop use-case for the package (upstream recommends 
> the "individual TTFs" format for embedding in applications) and for the 
> most part we group the sub-fonts in the same way as the upstream super 
> TTCs. Therefore, it makes sense to switch for the disk savings and 
> filesystem simplicity.

Makes sense.  But IMO we should build fonts from source eventually and
provide different formats in outputs or parameterizing them.

>> Descriptions will be translated, they must be string literals.
>
> I designed the procedure specifically so that the "description appendix" 
> could be a stand-alone phrase to be translated separately. Is there a 
> caveat I'm missing?

xgettext is set to extract string literal inside ‘description’, but it
will find ‘string-append’ in this case, so the description won't be
extracted at all.

Even if you have managed to extract different parts of the description,
e.g. "a" and "b", Guix UI looks up translation for the resulted string,
e.g. "ab", so it won't be translated either.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.