FFE/UIFE: replace some font packages with ubuntu-desktop-fonts on the LiveCD

Some questions:

 * Is this package co-installable with the old fonts? It does not have any Conflicts:/Replaces:, and indeed it might be desirable to have that, plus some of the original extra fonts installed?

 * From a very crude perspective, is this just a selection of existing fonts, or new fonts that we didn't previously ship? I. e. would that actually change anything visually, or just remove some redundancy?

If the package is co-installable and just redundancy reduction, this looks appropriate for me.

Yes, this package co-installs with the other font packages. The fonts in question will be on the disk twice when the other packages are also installed, but in different directories, so they shouldn't conflict.

It's a selection of existing fonts (list is in the bug description), with the exception of Takao Gothic, which has not been packaged yet. As we do want this font to be the default font for Japanese, it's important that it gets included.
Other fonts, KacstOne and the indic fonts, have been updated and the latest version from upstream or Debian Unstable has been used. The plan is to sync ttf-indic-fonts from Debian, once it is removed from the seeds in favor of this package.

The KacstOne font has been packaged separately and should be available in Debian Unstable by now. If we can sync that one and push it into Main, we can remove that font from this package.

Short explanation:
ttf-indic-fonts contains a Ubuntu patch to split the default desktop fonts out into a separate ttf-indic-fonts-core package. That one is seeded in the LiveCD. Debian has released a newer version of ttf-indic-fonts. I prefer not to merge the changes and instead use this package to obsolete the Ubuntu diff on ttf-indic-fonts and then sync the package from Debian.

KacstOne was included in the ttf-kacst package. We still have an older version of that package. Upstream has split this font off the package and released a much improved version of KacstOne. Debian has recently updated ttf-kacst (KacstOne has been stripped out) and packaged ttf-kacst-one separately. This font is the preferred desktop font for Arabic. When I created this package, I took the KacstOne font from upstream, since the package was not available in Debian yet at that time. Meanwhile it has been created and uploaded, so, if we can sync it from Debian, put it into Main and seed it on the LiveCD, then I can remove that font again from this package.

Thanks for the explanations. Sounds reasonable, approved. So let's get the package into Ubuntu as quickly as possible.

I would appreciate some more clarification regarding this change.

Is the set of fonts from the ttf-indic-fonts source package that are being included in this package identical to those currently shipped in the ttf-indic-fonts-core binary package? If not, why not? If it is identical, what is the advantage of shipping and maintaining a completely separate copy of these fonts in a separate package rather than continuing to maintain a divergence on the Debian packaging? (Consider that if the ttf-indic-fonts package is still available in the archive, users may wind up with two different copies of the font installed - this may not be a Conflicts/Replaces problem, but it may make debugging of font problems more difficult if the upstream versions of the font are out of sync.) If it's not identical, given the preceding comment, why would we not simply update the contents of ttf-indic-fonts-core to reflect this blueprint?

At a glance, it looks like these indic fonts will be installed by default that aren't currently:

> gargi.ttf ttf-indic-fonts package in Debian/Ubuntu
> Kedage-b.ttf ttf-indic-fonts package in Debian/Ubuntu
> Kedage-n.ttf ttf-indic-fonts package in Debian/Ubuntu
> lohit_bn.ttf ttf-indic-fonts package in Debian/Ubuntu
> Meera_04.ttf ttf-indic-fonts package in Debian/Ubuntu
> Pothana2000.ttf ttf-indic-fonts package in Debian/Ubuntu
> Rekha.ttf ttf-indic-fonts package in Debian/Ubuntu
> Saab.ttf ttf-indic-fonts package in Debian/Ubuntu

khmeros:

> KhmerOSsys.ttf ttf-khmeros package in Debian/Ubuntu
> KhmerOS.ttf ttf-khmeros package in Debian/Ubuntu

This is a subset of the fonts in ttf-khmeros, so the split makes sense; though again I'm concerned about font skew between the multiple copies of this in the archive.

The set of thai fonts is again a subset of the existing package.

> Kinnari-Bold.ttf ttf-thai-tlwg package in Debian/Ubuntu
> Kinnari.ttf ttf-thai-tlwg package in Debian/Ubuntu
> TlwgTypo-Bold.ttf ttf-thai-tlwg package in Debian/Ubuntu
> TlwgTypo.ttf ttf-thai-tlwg package in Debian/Ubuntu
> Waree-Bold.ttf ttf-thai-tlwg package in Debian/Ubuntu
> Waree.ttf ttf-thai-tlwg package in Debian/Ubuntu

ttf-kacst-one - yes, I think it's better to sync this from Debian.

> TakaoPGothic.ttf https://launchpad.net/takao-fonts -- packaging is work in progress

Since this isn't packaged yet, I don't think it matters whether it's in its own package or in a package named ubuntu-desktop-fonts.

Overall, is the subsetting of the existing packages being done to make room for more Indic fonts, or is the goal to simplify the user's options? It's great to save 4MB, but we aren't hurting for space currently; so if the only goal is to make sure we aren't negatively impacting ISO sizes, perhaps there's a way to accomplish this with less package maintenance overhead and reducing the inter-package skew issue?

Steve, I'm open for other options. If you guys think introducing/maintaining ubuntu diffs in those packages makes more sense, surely I can do that. That way we would not have the inter-package skew issue, but would need to merge the packages all the time. It's mostly the packaging stuff which changes, or new fonts getting added to the packages. The fonts themselves are seldom updated, if at all.

The ttf-indic-fonts-core selection is currently not the same as the collection in this package. The list of preferred fonts changed and now largely follows what upstream has specified in their fontconfig files for sans-serif and serif fonts. (Also, Debian has a newer version available than what we ship, the ttf-indic-fonts need to get merged or synced. I took the fonts from the latest Debian package and planned to sync the ttf-indic-fonts packages after this package gets uploaded, to get rid of the ubuntu diff. So, the font versions would be the same as in Debian in Lucid.)

The ttf-kacst-one package is unfortunately not available in the Debian archive yet, so we could either include it into this package, or, if we want to split the original packages, include the new upstream version in there and then split the package... however, that change would be obsolete when the ttf-kacst-one package gets finally synced from Debian (which may be only in Lucid+1).
Actually, if it has been uploaded to Debian already and is just stuck in the queue, we could maybe take it directly from there...?
Currently I use a font version check in the fontconfig file, to check the version of the KacstOne font installed. This makes sure that the newer version in this package gets used and not the older version from the ttf-kacst package.

If it's only the Takao Gothic font being left in here, it would make sense to just create a package for that standalone font and update it later when the rest of the Takao fonts get packaged.

The reason to do this is to limit the number of pre-installed fonts to a necessary minimum in order to have more space for more important stuff, like ibus-pinyin + ibus-pinyin-db-android (~ 1MB), so that we finally have a Chinese input method on the Live CD, or to provide more fonts for more languages (e.g Persian, Urdu, Mongolian) or more language-packs. Also, several users complained that the list of installed fonts is currently too long.

Arne Goetje [2010-03-31 9:40 -0000]:
> Steve, I'm open for other options. If you guys think
> introducing/maintaining ubuntu diffs in those packages makes more sense,
> surely I can do that. That way we would not have the inter-package skew
> issue, but would need to merge the packages all the time.

But wouldn't we need to to that anyway, to apply font changes from the
"master" packages to ubuntu-fonts?

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

I do think it makes more sense to maintain this as Ubuntu diffs against the existing packages instead of duplicating those packages. We have a lot of process in place that helps us track differences between Ubuntu and Debian packages of the same name, which we wouldn't be leveraging if creating a new package.

> (Also, Debian has a newer version available than what we ship,
> the ttf-indic-fonts need to get merged or synced. I took the fonts
> from the latest Debian package and planned to sync the
> ttf-indic-fonts packages after this package gets uploaded, to get
> rid of the ubuntu diff. So, the font versions would be the same
> as in Debian in Lucid.)

I'm happy to have ttf-indic-fonts merged from Debian for this, please consider the FFe for that granted.

[ttf-kacst-one]

> Actually, if it has been uploaded to Debian already and is just
> stuck in the queue, we could maybe take it directly from there...?

It's non-trivial to get access to new packages *in* the queue, due to legal concerns, but you could contact the maintainers (listed at http://ftp-master.debian.org/new/ttf-kacst-one_3.0-1.html) and request a copy.

(It's probably best to upload this to lucid as 3.0-0ubuntu1 or 3.0-1~build1, in case the uploaders themselves no longer have the exactly identical source package.)

> If it's only the Takao Gothic font being left in here, it would make
> sense to just create a package for that standalone font and
> update it later when the rest of the Takao fonts get packaged.

I agree.

As long as this is implemented on top of the existing source packages, then FFe granted - please go ahead.

ttf-indic-fonts merge is here: https://code.edge.launchpad.net/~arnegoetje/ubuntu/lucid/ttf-indic-fonts/merge-from-sid/+merge/23333

ttf-kacst-one has been accepted in debian unstable. Sync request is here: https://launchpad.net/bugs/562407

ttf-kacst-one synced into main, see bug 562407. ttf-indic-fonts merge is in Lucid already. So I suppose ttf-kacst-one needs to be added to language-support-* or language-selector* at least, or should we change the seeds to add this in favor of another font package?

Thanks!

Martin Pitt wrote:
> ttf-kacst-one synced into main, see bug 562407. ttf-indic-fonts merge is
> in Lucid already. So I suppose ttf-kacst-one needs to be added to
> language-support-* or language-selector* at least, or should we change
> the seeds to add this in favor of another font package?

Please replace the ttf-kacst package with ttf-kacst-one in the seeds.

In addition to the ttf-indic-fonts-core package, please also seed
ttf-punjabi-fonts, since that one only contains 2 fonts and therefor it
doesn't make sense to move them into ttf-indic-fonts-core.

How is the space situation? Do we need to split the ttf-thai-tlwg and
ttf-khmeros packages?

ttf-takao-gothic has not been uploaded into Debian yet, but I could get
it from the svn on alioth... however, that package is quite large (12MB)
, as it contains 3 fonts, of which we only need one for the LiveCD. So,
I can split that package into -core and -extra and prepare it for
upload, if you agree. (That would replace the ttf-vlgothic package in
the seeds.)

Arne Goetje [2010-04-15 14:02 -0000]:
> Please replace the ttf-kacst package with ttf-kacst-one in the seeds.

Will do once it builds (it was dep-wait on python-fontforge; promoted
now)

ttf-kacst is 940 kB, while t-k-one is just a mere 33 kB. Is that
alright?

> In addition to the ttf-indic-fonts-core package, please also seed
> ttf-punjabi-fonts, since that one only contains 2 fonts and therefor it
> doesn't make sense to move them into ttf-indic-fonts-core.

Seeded. (It's tiny)

> How is the space situation?

695 MiB ATM, and we have 4 (amd64)/6 (i386) langpacks. I. e. "full"
and "removing even more langpacks would be really bad".

> Do we need to split the ttf-thai-tlwg and ttf-khmeros packages?

We don't ship ttf-khmeros at all right now. ttf-thai-tlwg is 3 MB, so
if that can be reduced it would certainly be nice. But I don't think
it should happen for lucid still: We have bigger fish to fry right now
and don't want to introduce a potential font support regression just
to save 1 or 2 MB (which wouldn't even be enough for a new langpack).
For maverick and onwards it's a nice potential space saving, though,
if/when we are back in CD space trouble. So we should certainly shelve
this idea, thanks!

> ttf-takao-gothic has not been uploaded into Debian yet, but I could get
> it from the svn on alioth... however, that package is quite large (12MB)
> , as it contains 3 fonts, of which we only need one for the LiveCD. So,
> I can split that package into -core and -extra and prepare it for
> upload, if you agree. (That would replace the ttf-vlgothic package in
> the seeds.)

ttf-vlgothic is indeed a hog (5 MB); how big is the one font that we
need from ttf-takao-gothic? How much different are they compared to
the two in ttf-vlgothic?

3852276 VL-Gothic-Regular.ttf
3974300 VL-PGothic-Regular.ttf

Could we split out/drop one of them to get a similar effect?

Thanks,

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

On Fri, Apr 16, 2010 at 09:51:29AM -0000, Martin Pitt wrote:
> Arne Goetje [2010-04-15 14:02 -0000]:
> > Please replace the ttf-kacst package with ttf-kacst-one in the seeds.

> Will do once it builds (it was dep-wait on python-fontforge; promoted
> now)

Built fine, this is seeded now.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

BTW, as these changes affect all of the desktop metapackages, we really need to get any remaining changes to the font sets finished in the next day or two so that we're settled in time for RC ISO mastering.

What is the status of packaging for takao-gothic? Provided that the package is split into -core and -extra, I'm happy to review this in the NEW queue if it gets uploaded; I don't want us to be paralyzed here by second-guessing each other and miss the window for getting these in.

Since ttf-khmeros is already in the archive and just needs a package split, I'll look at this myself and submit it to the queue.

ttf-khmeros uploaded. Before the split:
928K pool/main/t/ttf-khmeros/ttf-khmeros_5.0-3_all.deb

after the split:
716K ttf-khmeros_5.0-3ubuntu1_all.deb
216K ttf-khmeros-core_5.0-3ubuntu1_all.deb

Looks like this should be fine as far as space, so uploading to the queue. (BTW Martin: you said we have 4 and 6 langpacks on the CDs, but we actually have 5 and 7...?)

Whoops, overlooked Martin's comments about not changing the thai fonts for this cycle. Closing this task.

Steve Langasek [2010-04-17 9:43 -0000]:
> Looks like this should be fine as far as space, so uploading to the
> queue. (BTW Martin: you said we have 4 and 6 langpacks on the CDs, but
> we actually have 5 and 7...?)

Ah, I didn't count -en :-)

OK, I have split the ttf-takao-gothic package from svn on alioth and put it on chinstrap:
https://chinstrap.canonical.com/~arne/ttf-takao/

The source package builds three binary packages:
ttf-takao-pgothic -> this one we want to have seeded in the Live CD, approx 4 MB; replacement for ttf-vlgothic
ttf-takao-gothic -> will get pulled by language-support-fonts-ja, needs to be in main
ttf-takao-mincho -> will get pulled by language-selector-fonts-ja, needs to be in main.

I will update fontconfig now with new CJK font preferences and ttf-kacst-one for Arabic.
Further I want to retire fontconfig-voodoo from language-selector. That stuff will be replaced by the CJK changes in fontconfig.

This bug was fixed in the package ttf-khmeros - 5.0-3ubuntu1

---------------
ttf-khmeros (5.0-3ubuntu1) lucid; urgency=low

  * Split KhmerOSsys.ttf and KhmerOS.ttf into a ttf-khmeros-core package, for
    installation by default on the desktop. LP: #535582.
 -- Steve Langasek <email address hidden> Sat, 17 Apr 2010 02:42:56 -0700

desktop-common seeds were changed to replace vlgothic with takao-pgothic and include khmeros-core.

I tihnk there are still some package uploads needed related to the ttf-takao fonts, which have all been seeded in main; pointing this at the relevant packages.

Also need to change the fontconfig settings in language-selector for fontconfig-voodoo to include Takao fonts for Japanese and wqy-microhei for Chinese.

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

---------------
language-selector (0.5.7) lucid; urgency=low

  * Change fontconfig settings:
    - zh-*: reorder font priority lists, put DejaVu and Bitstream Vera in front
    (LP: #149944)
    - zh-*: add WenQuanYi Microhei, Droid Sans Fallback and HYSong
    - ja: add entries for Takao and IPA fonts, reorder and merge
    required rendering options from the 29-language-selector-ja-jp.conf file
    (LP: #535582)
    - update 30-cjk-aliases.conf to include localized font names and fonts used
    in Windows 7.
 -- Arne Goetje <email address hidden> Wed, 21 Apr 2010 17:49:18 +0200

language-support-fonts-ja (1:10.04+20100420) lucid; urgency=low

  * Automatic update to latest translation data.
  * Added: ttf-takao-gothic, ttf-takao-mincho
  * Removed: ttf-sazanami-mincho, ttf-vlgothic

 -- Ubuntu automatic language-pack builder <<email address hidden> (ubuntu-langpack) > Tue, 20 Apr 2010 17:10:00 +0100