Package Base Details: otf-alegreya

Git Clone URL: (read-only, click to copy)
Submitter: haawda
Maintainer: akobel
Last Packager: akobel
Votes: 11
Popularity: 0.59
First Submitted: 2014-06-23 23:18 (UTC)
Last Updated: 2018-11-05 17:43 (UTC)

Latest Comments

1 2 Next › Last »

haawda commented on 2016-07-07 06:37 (UTC)


akobel commented on 2016-07-04 22:03 (UTC) (edited on 2016-07-04 22:44 (UTC) by akobel)

Why does the otf-alegreya package contain some TTF versions as well? For some reason, this seems to confuse LuaLaTeX - probably the PEBKAC, but still. I see that the "hand hinted" in the ttf directory name suggests that they offer some benefit, but this is not the case for everybody and should be reserved for a ttf-alegreya, right? @Ketsuban: FWIW, the current version on Github of Alegreya-libre (used here) contains at least some kerning pairs (e.g., "To"). Unfortunately, I have no reliable source of all differences between the libre and the pro version. Rumor I've read is that - only the latter has kerning, but obviously that's at least partially untrue; - libre lacks some accented characters (which?); or - that it lacks automatic ligature support, which I cannot confirm nor refuse: LuaLaTeX shows ligatures, but I'm not sure whether it does so by introspecting the font and inserting those characters directly, or whether it leaves the job to the font...

Ketsuban commented on 2015-04-24 18:46 (UTC)

Incidentally, users of this package should be made aware that the version of Alegreya available on Fontsquirrel lacks kerning. There's currently a pull request to update the version on Google's font service to that supplied by Adobe's team which also improved the hinting.

Ketsuban commented on 2015-04-04 13:01 (UTC)

The more I dig, the more interesting it gets. The Arch packaging standards say that any package whose license isn't in /usr/share/licenses/common should be flagged as "custom", optionally giving the name of the license. The OFL isn't in that folder, so the AUR packages tagged as "OFL" (railway-sans-font, railway-sans-font-git, otf-chiq, oldstand-font, otf-orbitron, bdf-bitocra) are technically incorrect. However, the Arch packaging standards also say that any license used by two packages in the community repo is common; ttf-fira-sans and ttf-fira-mono are both "custom:OFL", and there's more where that came from (searching "ttf" gave me ttf-gentium, ttf-inconsolata, ttf-liberation and ttf-linux-libertine-g, plus ttf-hanazono which is "custom" but licensed under the OFL according to the source website). By that rule, "OFL" is a common license and we should all be using it. "custom:OFL" seems like a reasonable compromise until someone sorts things out, since it matches quite a few existing font packages on the AUR... but then I would say that since that's what I went with.

haawda commented on 2015-04-04 12:26 (UTC)

The license is correct as it is.

Voice commented on 2015-04-04 03:12 (UTC)

License is OFL or custom:OFL like aur/ttf-sil-fonts, thank you

haawda commented on 2014-07-10 01:18 (UTC)

Added a conflict to otf-google-fonts-hg. The other packages seem to provide ttf-fonts only. So do the zip-files you mentioned. Thanks for the interesting documenting links.

DaveCode commented on 2014-07-09 06:08 (UTC)

PKGBUILD should add conflicts with Google fonts, and also go ask them to conflict with you. They keep a (huge) list and need help. The author site ( ) doesn't show any free release that I could find, just the commercial pro version. Possibly simpler, md5-able download link at The free version .zip download URL Google supplied me was I don't know if that's constant or variable depending on user session etc. Recent articles of interest.

haawda commented on 2014-07-09 01:07 (UTC)

Sorry, I thought I did already implement a solution (skipping the checksums), but my pkgbuild-mode for emacs, which I used to edit the PKGBUILD, did fool me. I should change that behaviour there. Now fixed.

FjolleJagt commented on 2014-07-08 21:17 (UTC)

It seems to be the licence file which they have in the folder - it appears to have the current timestamp (in a certain timezone) for whenever you download the archive, which causes the archive to have a different md5sum. Not sure if there's a workaround for this.