[Fedora-packaging] Re: Subpackaging the Noto CJK fonts

On 10 April 2018 at 13:34, Jens-Ulrik Petersen <petersen(a)redhat.com&gt; wrote:

>  For Fedora 28 we have Changes to make Google Noto CJK fonts the
> default
>  for Chinese, Japanese and Korean. This provides a number of advantages
>  include new Serif faces, and Mono fonts for terminals etc.
>
>  However it comes at a cost: there are 7 weights for each of the Sans and
>  Serif fonts for each of the four languages.  Additionally the Mono fonts
>  are only available in very large CJK coverage versions.
>
>  See https://bugzilla.redhat.com/show_bug.cgi?id=1562315
>  and https://pagure.io/fedora-workstation/issue/46 for size details.
>
>  We would like to propose an exception for google-noto-cjk-fonts for Fedora
>  28 where we will subpackage the extra weight variants to save a lot of
>  space on the Live images and other media.
>
>  This will reduce Live images by about 250MB or more by only shipping the
>  Regular and Bold weights, or even more if we only shipped Regular.
>  Otherwise we will see a big impact on iso sizes across the distro which
>  could aversely affect the release.
>
>  For Fedora 29 we plan to move to the more compact OpenType Collection
>  version of the fonts which will provide a considerable saving, but it seems
>  too late to make a such a big change now for F28.
>
>  Since East Asian fonts are so large, I think it makes sense to have a
>  packaging exception for CJK fonts to allow the subpackaging of weight
>  variants: it could be done with metapackages to make it more obvious (we
>  could even do one package per weight and have a meta package that pulls
>  them all in, if that makes it more clear and discoverable).
>  

Agree with mentioned issue. If we want to give value to users from proposed
change i think we need to do some tweaking. Last time i installed all Noto
CJK fonts and size was around 1GB+.   As a non-CJK user, i definitely not
required entire collection of CJK fonts but only 1 variant is sufficient to
avoid Tofu.

Will be nice if we can allow this exception to sub-packaging at variant
level for this release and try other options for FY19 (.ttc)

-
Pravin