| Git Clone URL: | https://aur.archlinux.org/ttf-ms-win11-auto.git (read-only, click to copy) |
|---|---|
| Package Base: | ttf-ms-win11-auto |
| Description: | Microsoft Windows 11 TrueType fonts |
| Upstream URL: | https://www.microsoft.com/typography/fonts/product.aspx?PID=164 |
| Licenses: | custom |
| Conflicts: | ttf-ms-fonts, ttf-tahoma, ttf-vista-fonts |
| Provides: | emoji-font, ttf-font, ttf-ms-fonts, ttf-ms-win11, ttf-tahoma |
| Submitter: | octocorvus |
| Maintainer: | octocorvus (kode54) |
| Last Packager: | kode54 |
| Votes: | 81 |
| Popularity: | 4.63 |
| First Submitted: | 2022-05-06 13:39 (UTC) |
| Last Updated: | 2024-11-16 00:25 (UTC) |
Stumbled on the error
httpdirfs: error while loading shared libraries: libgumbo.so.1: cannot open shared object file: No such file or directory
Solved this after installing gumbo-parser and rebuilding httpdirfs like this (using paru here):
$ paru gumbo-parser
$ paru httpdirfs --rebuild=yes
Seems like there's an optional build-time dependency for httpdirfs on gumbo-parser and paru doesn't rebuild the package on reinstallation of httpdirfs without the --rebuild=yes option.
@Fazzi: I cannot reproduce your issue. Please check your fontconfig directories for references to "antialias". The only settings I can think of that would apply to this is either hinting (I tried the hinting settings and could not reproduce with either "none" or "slight"), or the antialias exclusion range, which Plasma provides an option to configure, but as far as I know, does not enable by default.
Thank you for updating the package!! However I'm having an issue with all of the fonts, They all look fine until about 15pt where they suddenly lose anti-aliasing or something. You can see this for yourself if you install font-manager and look at any of the microsoft fonts in Waterfall view. Here is an example: https://imgur.com/a/cozO2Yt
Is anyone else experiencing this issue or is it just me? It seems to only be fonts from this package. ttf-ms-fonts works fine and so do the rest of my system fonts.
The symlinking errors are expected for this package, as the download of the files is done in prepare(), so makepkg tries to link these before they even exist in the folder. This shouldn't be a problem.
even after rebuilding httpdirfs, i still get the symlink issue, anyone know why? im using yay, to build it if that matters.
I remember looking into this problem. The actual root of the problem lies with udisks timing out (does it hit the cache in the HTTP filesystem? Can't remember). Anyway, that error isn't being cleaned up, so on your second try you have multiple duplicate mounts happening (take a look at the output of mount after getting the error).
Once I reached the end of my timebox for it, I just opened up PKGBUILD and did this:
% git diff
diff --git a/PKGBUILD b/PKGBUILD
index 3608c4e..04bc7c1 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -407,6 +407,7 @@ prepare() {
udisksctl loop-delete -b "$_testLoopDev" --no-user-interaction
rm test.mount
+ _unprivilegedMountAllowed=false
if [ $_unprivilegedMountAllowed ]; then
echo "allowed"
echo "- Downloading fonts directly"
Adding the _unprivilegedMountAllowed=false line dbypasses the bug, but the install will take longer (details here explained in PKGBUILD.
Oh yeah, now I see that the root of the problem is that _loopDev=$(udisksctl loop-setup -r ... line. I found some other folks complaining about it a similar issue, but I'm not sure it's related, since the complaints were old. Here's one: https://github.com/storaged-project/udisks/issues/828
EDIT: Made the diff output less annoying to read.
I have no problems with installing the package, but while looking through the PKGBUILD after the last update, I stumbled across the httpdirfs --cache flag and the comment about it.
In short, with this flag httpdirfs caches all downloaded data in the user's cache directory permanently, using sparse allocation for partially downloaded files (as is here the case for the ISO). In the project's GitHub repo it is also mentioned that initial download speeds could be limited to 15 MiB/s due to the feature's implementation.
While I don't think the speed is a concern with a download size of ~400 MiB (I surely wouldn't notice), we really don't gain anything from the caching. When the package is updated, the cached ISO won't speed anything up since a new ISO with a new name will have to be downloaded freshly from Microsoft. Besides that it just piles up in the user's home dir, with every new ISO occupying about 6 GiB (mostly pre-allocated) space. I'd like to suggest possible changes:
Just removing the --cache option altogether, possibly mentioning why it's not used anymore in the build instructions.
Using the --cache-location option alongside to point to the $srcdir (typically src/). This way, the user's choice where to save source files is honored, and the cached files can be cleaned up easily with makepkg --clean or --cleanbuild.
run yay --rebuild httpdirfs
ln: failed to create symbolic link '/home/boredhero/Desktop/ttf-ms-win11-auto/src/' -> '': No such file or directory
==> Starting prepare()...
- Examining locally available fonts
- Fonts are missing
- Mount filesystems as a non-privileged user: allowed
- Downloading fonts directly
- Mounting HTTP file
httpdirfs: error while loading shared libraries: libgumbo.so.1: cannot open shared object file: No such file or directory
==> ERROR: A failure occurred in prepare().
Aborting...
Glad to see this finally updated. Builds flawlessly.
Note: If you get the error "Filesystem type udf not configured in kernel" its caused by not rebooting after a kernel update. Reboot and try again.
Pinned Comments
kode54 commented on 2024-02-04 10:43 (UTC) (edited on 2024-02-04 10:45 (UTC) by kode54)
You apparently need to be a member of the
diskgroup to mount a filesystem as an otherwise unprivileged user.And log out and back in again.