Package Details: ttf-charis-sil 5.000-4

Git Clone URL: https://aur.archlinux.org/ttf-charis-sil.git (read-only, click to copy)
Package Base: ttf-charis-sil
Description: A transitional serif typeface based on Bitstream Charter.
Upstream URL: https://software.sil.org/charis/
Licenses: custom:OFL
Conflicts: ttf-sil-fonts<=6
Submitter: Markus00000
Maintainer: Markus00000
Last Packager: Markus00000
Votes: 3
Popularity: 0.36
First Submitted: 2018-07-02 15:41
Last Updated: 2020-02-24 12:42

Latest Comments

Markus00000 commented on 2020-03-10 15:52

@caleb Thanks for the explanation regarding font caches. The OFL might qualify as a standard license, but it is not yet included in the licenses package. Until then, custom remains required according to the wiki.

caleb commented on 2020-02-24 13:00

@Markus00000 I don't know where you heard about that cache regen issue, but I think it is obsolete. I've asked in IRC and a TU agreed that there is currently no such benefit. Back when you had to include a hook yourself in a post install script as part of font packaging I think what you are saying would have been true. Now using Arch's hook in fontconfig for new font files it is going to scan everything no matter what you do.

The reason I think it matters to put them in TTF is to force other packages that try to install the same fonts are going to throw file conflict errors rather than silently having multiple versions of the same font and potentially and older version getting used. This was happening with the ttf-sil-fonts package back before I converted it to a meta package, and I see it is still happening with some of the massive google-font compilations. I'd rather know about conflicts rather than getting weird results and unwittingly using different font versions that I installed.

As for the license field, I've been systematically removing the "custom:" prefix from my packages (you found one I haven't gotten to) because OFL now qualifies as a standard license having been included in 2 or more official repository packages. It still needs the file included per package because of the differing reserved name clause, but it qualifies as a standardized license name.

See also this issue I just opened about the OFL FAQ file.

Markus00000 commented on 2020-02-24 12:38

@caleb

use Arch's standard ttf font directory

Is it standard? To give just a few popular examples of packages that install into /usr/share/fonts/<subdir>/: ttf-liberation, adobe-source-*, ttf-croscore, ttf-ubuntu-font-family.

Somebody told me that updating the font cache can only be done on a per-directory basis. Putting all fonts into one directory requires rebuilding the entire cache each time any font is updated.

fix the license name

What should the license name be? I looked at your ttf-sil-alkalami package and it also uses license=('custom:OFL'). The license itself starts with “SIL Open Font License (OFL)”.

adding conflicts=('ttf-sil-fonts<=6')

Will do.

Thanks for you help!

caleb commented on 2020-02-20 12:16

PSA: I've started hosting this (and all other SIL fonts) as prebuilt packages in my repository for those that want to install in using pacman without messing around with building from the AUR.

caleb commented on 2020-02-20 12:14

After a discussion in IRC it seems like adding conflicts=('ttf-sil-fonts<=6') is a good idea. Some people are still going to run into update conflicts, but with this addition at least some AUR helpers and my prebuilt package repository will provide a smooth upgrade path.

caleb commented on 2020-02-18 10:52

@Markus00000 One of the things I would do is use Arch's standard ttf font directory as the destination and fix the license name. I would have removed the obsolete dependencies from before when Arch added hooks to fontconfig/xorg-font-utils, but I see you got that.

Markus00000 commented on 2020-02-15 10:49

@caleb I’ve removed the conflict. What are these “few other minor ways to normalize” the package?

caleb commented on 2020-02-15 09:42

Hey, I just adopted the ttf-sil-fonts package and am in the process of converting it to a meta-package that just depends on all the others. At the very least this needs to not conflict, but it would also be nice if it could be updated in a few other minor ways to normalize it. Would you consider adding me as a co-maintainer so I can take cake of this?