Package Details: acroread-fonts-systemwide 1:DC_2022.001.20117-1

Git Clone URL: https://aur.archlinux.org/acroread-fonts-systemwide.git (read-only, click to copy)
Package Base: acroread-fonts-systemwide
Description: Fonts from Adobe Acrobat Reader DC
Upstream URL: https://helpx.adobe.com/acrobat/kb/windows-font-packs-32-bit-reader.html
Keywords: devanagari font minion myriad
Licenses: custom
Conflicts: acroread-font-chinese-simplified, acroread-fonts, ttf-adobe-fonts, ttf-adobe-fonts-cjkext
Submitter: None
Maintainer: eugene
Last Packager: eugene
Votes: 112
Popularity: 0.39
First Submitted: 2009-08-20 21:32 (UTC)
Last Updated: 2022-05-24 18:12 (UTC)

Latest Comments

1 2 Next › Last »

prettyvanilla commented on 2020-07-01 23:50 (UTC)

Please update to the most recent upstream release and remove the dependencies as per the recent font packaging changes in the official repos, thanks!

dreieck commented on 2018-05-02 13:07 (UTC)

May you add provides=("acroread-fonts=${pkgver}" "ttf-adobe-fonts=${pkgver}" "ttf-adobe-fonts-cjkext=${pkgver}" "acroread-font-chinese-simplified=${pkgver}") to the PKGBUILD?

Or is it not applicable?

colinkeenan commented on 2016-03-24 02:08 (UTC)

Thanks. Can see updates now.

Marcel_K commented on 2016-03-23 23:02 (UTC)

There's an epoch system in Arch, which I can set to 1 (> default 0). I'll do so shortly.

colinkeenan commented on 2016-03-23 20:31 (UTC)

I haven't been updating this package on archlinuxcn because the check for new versions was failing to realize new versions were coming out. I just realized this issue and uploaded a new version to archlinuxcn, but nobody will know unless they install it directly: sudo pacman -S acroread-fonts-systemwide warning: downgrading package acroread-fonts-systemwide (11.0.10-1 => DC_2015.007.20033-1) This is because pacman considers the old version (11.0.10-1) to be newer than the new version (DC_2015.007.20033-1). Can you make a numbering system that is greater than 11.0.10-1? Like, can you just start with 12DC instead of just DC?

colinkeenan commented on 2015-02-26 03:20 (UTC)

Thanks. Got it built and uploading to archlinuxcn. Also added p7zip920 to archlinuxcn.

Marcel_K commented on 2015-02-25 18:21 (UTC)

FYI, it's a bug in p7zip, which will be fixed in its next version. https://sourceforge.net/p/sevenzip/bugs/1487/

Marcel_K commented on 2015-02-25 13:55 (UTC)

Thanks for the report. It was not only a too long switch you bumped upon, but it turned out that p7zip was changed after the last major update, so that we can't extract the files anymore. I uploaded an older version of p7zip to the AUR and made it a makedepend, so you can now rebuild this package again. I'll try to find a neater solution than relying on an old(er) version of p7zip.

colinkeenan commented on 2015-02-25 07:35 (UTC)

I had previously built the version available on 12/1/14, and it had the same 7z command in it. I had to do a fresh install on Christmas, and didn't get around to working on updating this until now. The version I build on 12/1 is on archlinuxcn, so I've got that one re-installed. I'm responsible for updating it, but can't due to this "Too long switch" on the 7z command.

colinkeenan commented on 2015-02-25 06:09 (UTC)

Command Line Error: Too long switch: -yir!131 ==> ERROR: A failure occurred in prepare(). Aborting... It doesn't like "7z -yir!131 ..."