Package Details: ttf-ms-win11-auto-korean 10.0.26100.1742-2

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 Korean TrueType fonts
Upstream URL: https://www.microsoft.com/typography/fonts/product.aspx?PID=164
Licenses: custom
Conflicts: ttf-ms-win11-korean
Provides: ttf-ms-win11-korean
Submitter: octocorvus
Maintainer: octocorvus (kode54)
Last Packager: kode54
Votes: 81
Popularity: 6.97
First Submitted: 2022-05-06 13:39 (UTC)
Last Updated: 2024-10-20 08:55 (UTC)

Dependencies (4)

Required by (0)

Sources (143)

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 disk group to mount a filesystem as an otherwise unprivileged user.

sudo usermod -aG disk $USER

And log out and back in again.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 .. 10 Next › Last »

Fazzi commented on 2024-02-07 09:25 (UTC)

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.

gregthwuen commented on 2024-02-06 23:15 (UTC)

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.

Archangelectra commented on 2024-02-06 22:54 (UTC)

even after rebuilding httpdirfs, i still get the symlink issue, anyone know why? im using yay, to build it if that matters.

mattalxndr commented on 2024-02-06 07:17 (UTC) (edited on 2024-02-06 07:34 (UTC) by mattalxndr)

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.

gregthwuen commented on 2024-02-05 23:06 (UTC)

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:

  1. Just removing the --cache option altogether, possibly mentioning why it's not used anymore in the build instructions.

  2. 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.

TheJackofClubs commented on 2024-02-05 19:53 (UTC)

run yay --rebuild httpdirfs

boredhero commented on 2024-02-05 18:21 (UTC) (edited on 2024-02-05 18:22 (UTC) by boredhero)

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...

jdigi78 commented on 2024-02-05 03:08 (UTC)

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.

kode54 commented on 2024-02-05 01:25 (UTC)

@Viterzgir: please rebuild and reinstall httpdirfs AUR package.

Viterzgir commented on 2024-02-04 15:08 (UTC) (edited on 2024-02-04 15:52 (UTC) by Viterzgir)

I can't build ln: failed to create symbolic link '/home/serge/Downloads/ttf-ms-win11-auto/src/' 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(). Nevermind rebuild httpdirfs package solved this problem.