Fontconfig does not find fonts in non-default profiles

OpenSubmitted by Pierre Neidhardt.
Details
5 participants
  • Alex Kost
  • Bengt Richter
  • Ludovic Courtès
  • Pierre Neidhardt
  • zimoun
Owner
unassigned
Severity
normal
P
P
Pierre Neidhardt wrote on 5 Dec 2019 11:43
(address . bug-guix@gnu.org)
871rtjm4rt.fsf@ambrevar.xyz
The fontconfig package has this bit:

Toggle snippet (5 lines)
(string-append "--with-add-fonts="
"~/.guix-profile/share/fonts,"
"/run/current-system/profile/share/fonts")

If I understand correctly, fonts can only be installed at the system
level or in ~/.guix-profile.

Is there a way to install fonts in a non-default profile?
If not, it would be nice to implement it. Can we use an environment variable?

--
Pierre Neidhardt
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAl3o31YACgkQm9z0l6S7
zH++YAf8CtKgVxKHG1p+eYpbx6MRoMNNdBknY7mKgXKvijClAaHEgBOS7w6aV30C
NXgLJ4cs7qrJwVzt/CQxUALyMsD3M8+IUnjOKeCduogC8TbhWY3LO2NXJgHe+upE
ViQLPmEXKgUz3wFwKc7EHUAapGWT1aoJe/ukBJ8h1KuChHH9U0iTmrPMc2Bm03wM
f75TN8Ax2o1Dd6dN2g+pM9lXU/v35jV132NmIDn1fkIzzYfmL94a4rJknQkqbxrx
G+vwsbqbxDELc2w2W2z6sfvySEFpnz22ejIbpfa7zjFM4B9+X0UB3Zjp8uNEpyWB
txIvcvPVuij6dA56QbsnuWyWuTmVhQ==
=tPIT
-----END PGP SIGNATURE-----

P
P
Pierre Neidhardt wrote on 5 Dec 2019 11:47
Re: bug#38498: Acknowledgement (Fontconfig does not find fonts in non-default profiles)
(address . 38498@debbugs.gnu.org)
87y2vrkq0p.fsf@ambrevar.xyz
This issue overlaps with #31403.

--
Pierre Neidhardt
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAl3o4EYACgkQm9z0l6S7
zH8DGQf+Ku7bHLq5EFkE4TnA7EEoU5o0Hn5ONKRP8b7HD0DIGh4KdeOe9SGL+0A9
jE37lITb2x2QtAyqdgsRUkH6bhnNpecYZJKOYh+WSGTfvFYDC/jh3uYPSjpLWr6x
mm0mrXfCNmt9CG7410slCrJzAeGMLBDxzgFa+vaPyzeDx0Kr/QLTDaM5MjVMp9Kr
e2XgLzqttFsc/LCsA5d+WQmYZ+5hl8PcMn0aFKO1BNpbxC5PXWPjr2NLaTir9AjP
5EgbcgrSudqo7SKwDleL/k1DaCE13fqTwwoJuiWW629/LFkKsPy//iqj3JMD5k9Z
qFKgPX+K1cy6NG3TicZ4WEXPyD414w==
=Ma42
-----END PGP SIGNATURE-----

A
A
Alex Kost wrote on 5 Dec 2019 18:06
Re: bug#38498: Fontconfig does not find fonts in non-default profiles
(name . Pierre Neidhardt)(address . mail@ambrevar.xyz)(address . 38498@debbugs.gnu.org)
87o8wm66sd.fsf@gmail.com
Pierre Neidhardt (2019-12-05 11:43 +0100) wrote:

Toggle quote (10 lines)
> The fontconfig package has this bit:
>
> (string-append "--with-add-fonts="
> "~/.guix-profile/share/fonts,"
> "/run/current-system/profile/share/fonts")
>
> If I understand correctly, fonts can only be installed at the system
> level or in ~/.guix-profile.
> Is there a way to install fonts in a non-default profile?

I install fonts into a special profile. All you need to do is edit your
"~/.config/fontconfig/fonts.conf" file. Mine looks like this:
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<dir>~/.guix-profiles/fonts/fonts/share/fonts</dir>
</fontconfig>
This allows ‘fc-cache’ and similar commands to find fonts from a
non-standard directory.

--
Alex
P
P
Pierre Neidhardt wrote on 5 Dec 2019 18:52
(name . Alex Kost)(address . alezost@gmail.com)(address . 38498@debbugs.gnu.org)
87fthylkw4.fsf@ambrevar.xyz
Thank you Alex, that's what I did and it works.

That said, I think it'd be nice if Guix would automatically do this for
us. After all, it already handles multiple-profiles properly for so
many other things! :)

--
Pierre Neidhardt
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAl3pQ/sACgkQm9z0l6S7
zH9u4wf5AXm93xe/mGPlESoYDy96AfNeGL10PNcmLINf0a5kruqdCcvSSnMl8mG2
NeyV/TnCRLtHcY6e+BKzSNOfpVajrYLZ8L6VUSiHeRFujvALeRk7hl0Pe/OrQq6i
7V3GI55xdALA4hNOCZ1YEwMv59ebr9syaM808rNpG5Ry4o5SwjIYS65h5VZYeXrY
HXuC0L8Eay5fULJ6UGdqtQLFbC1Y9ArFw66KLK61Shz7+oN18LLHh9OlwZZJNgzo
9HELMFNuP/v5nlMUdz8C0smStPuogFPLUDLGXTI0ocGGDktkVLOiC2FGER0qg2Mg
hbxtPEeHS8m0cF3hMElzG5/35sMBZg==
=lygP
-----END PGP SIGNATURE-----

A
A
Alex Kost wrote on 6 Dec 2019 18:45
(name . Pierre Neidhardt)(address . mail@ambrevar.xyz)(address . 38498@debbugs.gnu.org)
87immtuz3s.fsf@gmail.com
Pierre Neidhardt (2019-12-05 18:52 +0100) wrote:

Toggle quote (6 lines)
> Thank you Alex, that's what I did and it works.
>
> That said, I think it'd be nice if Guix would automatically do this for
> us. After all, it already handles multiple-profiles properly for so
> many other things! :)

TBH I don't understand all the problems related to multiple-profiles
that were discussed and "solved" recently. I have been using multiple
profiles for at least 5 years (I don't even have ~/.guix-profile on my
disk) and I have not had any serious problems, just some small obstacles
that can be easily overpassed.

Anyway, what I have written is not related to the bug, sorry for the
noise :-)

--
Alex
P
P
Pierre Neidhardt wrote on 6 Dec 2019 19:01
(name . Alex Kost)(address . alezost@gmail.com)(address . 38498@debbugs.gnu.org)
87blslgwp2.fsf@ambrevar.xyz
Alex Kost <alezost@gmail.com> writes:

Toggle quote (6 lines)
> TBH I don't understand all the problems related to multiple-profiles
> that were discussed and "solved" recently. I have been using multiple
> profiles for at least 5 years (I don't even have ~/.guix-profile on my
> disk) and I have not had any serious problems, just some small obstacles
> that can be easily overpassed.

The point of multi-profile support is to:

- behave in the most expected way;
- factor the work upstream.

The less time individual users spend on their ad-hoc multi-profile
support, the more time they can spend on other (more productive) things :)

We lose generality in making ~/.guix-profile special.

--
Pierre Neidhardt
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAl3ql3kACgkQm9z0l6S7
zH/b6ggAsQdLL8Qt29KLEmT6JAzYyYonC9aGGmzjL5Jog9o69oiVQphpOlBymdVM
48RHwu4PLENtm+0oVt2vu4U5H6k7bvYykBIUdnwSbNkDgRsFI0T4dgva9pMG/fRm
5wZBoNw2WWRjM7SeYOJY+1p51polMbT7XNZvzrDMvVFsm8kumUgmpXM1uIrAlmJ8
mqzOXkD1AGx4L3s1I7L9KPqwzdORfDXdsMATWAz0kzkvh6uMIEnQmAcIX2LZFrOQ
pQtbK2H3VM+oR8TkK7mlLxKuBLW3MFMLWQUVUSRjMu7a7xuY+QqxfCL62k/ahfXE
EP4vHUB7FnpEYhNiwqwZZMyDojMqKQ==
=56Of
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 10 Dec 2019 17:53
(name . Pierre Neidhardt)(address . mail@ambrevar.xyz)
87o8wgm8au.fsf@gnu.org
Hello!

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

Toggle quote (2 lines)
> We lose generality in making ~/.guix-profile special.

I think we all agree on that. Fontconfig is one of the very few cases
where we ended up resorting to that. The reason I think is simply that
Fontconfig honors ~/.config/fontconfig/fonts.xml but does not honor a
search path environment variable as is customary.

We could fix that by adding a patch so that Fontconfig would honor
$FONTCONFIG_FONT_PATH or similar.

WDYT?

Thanks,
Ludo’.
P
P
Pierre Neidhardt wrote on 10 Dec 2019 18:11
(name . Ludovic Courtès)(address . ludo@gnu.org)
875ziods13.fsf@ambrevar.xyz
Hi!

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (3 lines)
> We could fix that by adding a patch so that Fontconfig would honor
> $FONTCONFIG_FONT_PATH or similar.

Have we ever asked upstream? Maybe they would consider adding it.
If they don't, I'm in favour of a patch! :)

--
Pierre Neidhardt
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAl3v0dgACgkQm9z0l6S7
zH8g0Qf+LoL/nxXR2FfiQQAI9EwuZMJowKGfUeGm31D+E3189fG3tx1xZl8u0v17
FpyAIWOnrXyuxhn0pIOz/8lgA0CPjgCNvgXIT7QJzXVGTMri3e7dwnJTrNkwtePA
SF2gzS1a2LRtYGkmzfMnIiYcEZscDizZpMlx+EjoN32K1uVGbJiTtOa80Qt8Sl2w
ygHR0fdJLsbkPuuhl/N+OgbOP/KfK+3crc/mIVpZvSVBqccHkJ+FCsuCmDA9LFdN
YcawsGge5twTZnXrm2Q3ZijUPtZPtzDZmHQcpIUxD6vSneVQ5RxHKZlgqxThPjs/
ZM/NgA3J6LD5EbF0lJiQZ5U+y5CPFA==
=tVs2
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 12 Dec 2019 14:04
(name . Pierre Neidhardt)(address . mail@ambrevar.xyz)
87zhfx8zl4.fsf@gnu.org
Hi!

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

Toggle quote (8 lines)
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> We could fix that by adding a patch so that Fontconfig would honor
>> $FONTCONFIG_FONT_PATH or similar.
>
> Have we ever asked upstream? Maybe they would consider adding it.
> If they don't, I'm in favour of a patch! :)

I don’t think anyone asked upstream and I agree that we should! It
could help to have a patch ready to get the discussion started anyway.

Thanks,
Ludo’.
P
P
Pierre Neidhardt wrote on 13 Dec 2019 14:11
(name . Ludovic Courtès)(address . ludo@gnu.org)
87fthobcb2.fsf@ambrevar.xyz
Just read this:

Could we do the following: use a profile hook to generate a config file
and set the environment variable FONTCONFIG_FILE to this file?

(I feel that we can't do that because the path of the hook-generated
cannot be known in advance.)


I looked at what NixOS does in
nixpkgs/pkgs/development/libraries/fontconfig/default.nix:

Toggle quote (3 lines)
> - NixOS creates /etc/fonts/${configVersion}/fonts.conf link to $out/etc/fonts/fonts.conf,
> and other modifications should go to /etc/fonts/${configVersion}/conf.d

We don't have a global font folder and we probably don't want to have
one, so I guess this is not ideal.

The <dir> fontconfig setting in Nix is

Toggle snippet (8 lines)
<!-- nix user profile -->
<dir>~/.nix-profile/lib/X11/fonts</dir>
<dir>~/.nix-profile/share/fonts</dir>
<!-- nix default profile -->
<dir>/nix/var/nix/profiles/default/lib/X11/fonts</dir>
<dir>/nix/var/nix/profiles/default/share/fonts</dir>

so it probably suffers from the same issue.

--
Pierre Neidhardt
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAl3zjfEACgkQm9z0l6S7
zH+QbwgAqJTw89PdsUFAnV0151Sak2ZNUDIx9qjR+obyTGbfiQp7HnYoapH5HkFx
3HLfVxt1Q+vH4/r0M7LW6I53iqgPhaPrQK5QErsGpsydnv147s5bf2KeVvxgVUY9
peQhsorrJlZPFXVMALUyTBqxgTOgdXT/lFWOg7icLCBtQb5WKGu45cQUz6ULT/Ta
SkEsgrPUfe/CELPPqXW9po6nRIgjAuRP0OrZPIzKgciHq+1dQaCfi0/yNqrZJmMh
F//FhwM2oWUYIJjskJeivZnAOE3mHY14ORYOxp1Ex1yjYhXBaclsQQZamMgdP58c
8J/wjBZ+r45VuzPnqZKcfbiZVs5mlQ==
=y3yi
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 14 Dec 2019 15:08
(name . Pierre Neidhardt)(address . mail@ambrevar.xyz)
87r217yp8c.fsf@gnu.org
Hello,

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

Toggle quote (6 lines)
> Just read this:
> https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/126
>
> Could we do the following: use a profile hook to generate a config file
> and set the environment variable FONTCONFIG_FILE to this file?

I guess that would work.

Toggle quote (3 lines)
> (I feel that we can't do that because the path of the hook-generated
> cannot be known in advance.)

‘FONTCONFIG_FILE’ could be a search path of ‘fontconfig’ (the usual
way), but then we’d hit https://issues.guix.gnu.org/issue/22138,
meaning that it would not be set automatically.

Thoughts?

Ludo’.
B
B
Bengt Richter wrote on 15 Dec 2019 23:14
(name . Pierre Neidhardt)(address . mail@ambrevar.xyz)
20191215221406.GA1010@PhantoNv4ArchGx.localdomain
Hi Guix,

On +2019-12-13 14:11:13 +0100, Pierre Neidhardt wrote:
Toggle quote (16 lines)
> Just read this:
> https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/126
>
> Could we do the following: use a profile hook to generate a config file
> and set the environment variable FONTCONFIG_FILE to this file?
>
> (I feel that we can't do that because the path of the hook-generated
> cannot be known in advance.)
>
>
> I looked at what NixOS does in
> nixpkgs/pkgs/development/libraries/fontconfig/default.nix:
>
> > - NixOS creates /etc/fonts/${configVersion}/fonts.conf link to $out/etc/fonts/fonts.conf,
> > and other modifications should go to /etc/fonts/${configVersion}/conf.d
>
┌─────────────────────────────────────────────────────────────────────────┐
│ > We don't have a global font folder and we probably don't want to have │
│ > one, so I guess this is not ideal. │
└─────────────────────────────────────────────────────────────────────────┘
Toggle quote (2 lines)
>

How about an interplanetary font folder? cf. IPLD[1] :-)

I'm thinking fonts might be a good use case as content-addressable items
identified by what I call vbr's (Verifiable Blob References). A poc vbr
implementation is demoed below.



Toggle quote (14 lines)
> The <dir> fontconfig setting in Nix is
>
> --8<---------------cut here---------------start------------->8---
> <!-- nix user profile -->
> <dir>~/.nix-profile/lib/X11/fonts</dir>
> <dir>~/.nix-profile/share/fonts</dir>
> <!-- nix default profile -->
> <dir>/nix/var/nix/profiles/default/lib/X11/fonts</dir>
> <dir>/nix/var/nix/profiles/default/share/fonts</dir>
> --8<---------------cut here---------------end--------------->8---
>
> so it probably suffers from the same issue.
>

I have been working on my own spin on content-addressability
by way of what I call a vbr -- Verifiable Blob Reference.
It is a name that can be used for a symbolic link or a filename.

It is formed by a prefix followed by a guix hash followed by a
single hyphen followed by the basename of the file (or -bnam opt), like
prefix-hash-basename -- but the final guix hash you see in the final name
is not the guix hash of the file bytes, though that is used to form
an intermediate name string ("prefix-hashOfFileBytes-basename").
The final hash in the final name is a guix hash of the intermediate
name string per se, and _that_ hash is placed between "prefix-" and
"-basename" to form the final name so that the final name is
"prefix-hashOfIntermediateNameString-basename"

So the final name's hash is dependent on both the source bytes
and characters of the name. I'm hoping it will be hard to modify
source file bytes to produce the same final name.

I'm thinking is kind of like the old trick of taking the CRC32
of a packet with the CRC slot set to a known value and stuffing
the resulting CRC back in that slot.

I am not a crypto expert by any means, so comments on weaknesses
are appreciated. The above describes one variant. There is also
a self-referential version where the vbr text can be embedded in
the file, but that requires a substitution trick in the file byte
stream feeding the hash so the self-reference slot(s) can be
fixed value(s) during hashing. Still a wip but a single slot in
first or last pages of a file is not too bad :-) This in turn
has text vs binary variations. I've seen similar to the latter
described, but not my repeat hash vbr method, though I wouldn't
be that surprised if someone says, "Yeah, that's called frobulation."
or something.

I am re-inventing wheels I notice every time a scan the internet,
but hope to contribute something useful, eventually :)

Since this started with fonts, I'll start with a sample
┌──────────────────────────────────────────────────────────────────────────────────────────┐
│ this shows verifiable blob reference (vbr) names for duplicated 12x22 font files │
├──────────────────────────────────────────────────────────────────────────────────────────┤
│ $ find /gnu -type f -iname '*12x22*'|while read x;do vbr GxFont12x22- $x;done │
│ GxFont12x22-0jhp0cswgvpg4awc7cnadi9jymglnfryj0l9fcg1z7wd5sw8210a-sun12x22.psfu.gz │
│ GxFont12x22-0ylkkdlwhzfw3dadsqhhh021xafz97zajc3qcgrbv6vmdlk3chpn-LatGrkCyr-12x22.psfu.gz │
│ GxFont12x22-0awqnypd4np6zpjy12wd2fq5ri9ifamapadfmn1h9k2vjjnndwpd-iso01-12x22.psfu.gz │
│ GxFont12x22-1hy97l5n7363q5w5x19f7c8klabbprrpx5r1ki4swbn372326jgl-iso02-12x22.psfu.gz │
│ GxFont12x22-1zrlk9zvpkmhcl0cyxy5pnm6mqy7qranx40gz5gy3wvf0cnpm6dp-README.12x22 │
│ $ │
│ $ find /usr -type f -iname '*12x22*'|while read x;do vbr GxFont12x22- $x;done │
│ find: ?/usr/share/polkit-1/rules.d?: Permission denied │
│ GxFont12x22-0jhp0cswgvpg4awc7cnadi9jymglnfryj0l9fcg1z7wd5sw8210a-sun12x22.psfu.gz │
│ GxFont12x22-0ylkkdlwhzfw3dadsqhhh021xafz97zajc3qcgrbv6vmdlk3chpn-LatGrkCyr-12x22.psfu.gz │
│ GxFont12x22-0awqnypd4np6zpjy12wd2fq5ri9ifamapadfmn1h9k2vjjnndwpd-iso01-12x22.psfu.gz │
│ GxFont12x22-1hy97l5n7363q5w5x19f7c8klabbprrpx5r1ki4swbn372326jgl-iso02-12x22.psfu.gz │
│ GxFont12x22-1zrlk9zvpkmhcl0cyxy5pnm6mqy7qranx40gz5gy3wvf0cnpm6dp-README.12x22 │
└──────────────────────────────────────────────────────────────────────────────────────────┘
Potentially, the store could contain vbr names naming links to the foreign versions
in /usr and which could be verified any time desired for integrity and identity, and
presence: if absent, it would be optional to go to a substitutes repo or anywhere on
the web to refresh a local cache. If you find the name you can verify that the referenced
blob is identical to any other with the same name and dereferencing. More discussion below.

The names are made so that the hash part is dependent on both the file bytes
and the name itself as axplained below.

Following is an example poc vbr session. Pretty simple so far, but bigger dreams afoot ;-)

The commands are (others are wip, not shown :)
vbr prefix- filepath # prefix includes single trailing - for now
vbr -ck [ vbr-link | vbr-file-name ]

The rest made this a monster post, so if vbr and potential uses is
of interest, perhaps someone could copy this as the seed of a new thread
in a more appropriate list for discussing guix architectural evolution
and factoring out of minimalist components for use separately and/or
in minimal environments?

Also the guile language tower interests me :)

The following is an example of a possible format for sharing embedded snippets
simply and bitwise unambiguously. Lots of other possibilities exist ;-)
┌─────────────────────────────────────────────────────────────────────────┐
│ v1Snippet-1mzfvrqhllz92siajm2rq7h7a67hg486wnyjwxznhc0zmzxg9n2v-xxx │
├─────────────────────────────────────────────────────────────────────────┤
│ Among other things, I discuss using vbr's as verifiable blob references │
│ for what UEFI bios reads from /boot and so for what a boot loader sees, │
│ and so forth. Also the role of vbr's in casual but unambigous sharing │
│ of snippets within emails and docs, for automatic search and validated │
│ extraction. │
└─────────────────────────────────────────────────────────────────────────┘
The above could be cleanly automated but was done ad hoc by selecting the
five lines of box content before boxing it, and then executing

Toggle snippet (3 lines)
cat > /tmp/xxx;cat /tmp/xxx|boxit -title "$(vbr v1Snippet- /tmp/xxx)"

as a shell filter command on the region. The part after -title
put the vbr in title above the boxed content. So a search on v1Snippet-...
in e.g. this email lists archives in mbox format would allow automated
extraction of the box content and checking that the vbr was correct.

Of course you could do a vbr for a base64 part of an email too,
before or after decoding.

I think vbr is simple enough to integrate easily into the guix architeture.
Or WDYT, Ludo ;-)

Ok, this is getting long again ;-/

Can't resist including the /boot use:

Here is a use case re booting images.

for f in /boot/*{x,g};do vbr v1Boot- "$f";done
┌──────────────────────────────────────────────────────────────────────────────────────────┐
│ veebers for what UEFI sees, which it could keep as whitelist │
├──────────────────────────────────────────────────────────────────────────────────────────┤
│ v1Boot-0c9w9bjwbhn8hn7w427qar8wgdbyic7xv88pjs4yji79n9f2433v-vmlinuz-linux │
│ v1Boot-1dp21vvpx99nqjy2z8s239f8bgiqh43lzxm91j7a3n2867ngadj0-initramfs-linux-fallback.img │
│ v1Boot-1bxpkf7i3w7q3c4ziasp2vgg17xq5j3vdqp9y633l5212ddypj8d-initramfs-linux.img │
│ v1Boot-02yla7mv6qg16j0zw0dyy339zdn827xlv964hbinx7hnhi5ax3kk-intel-ucode.img │
└──────────────────────────────────────────────────────────────────────────────────────────┘

This would enable safe booting via TFPT, without signatures, assuming you checked and
trusted the vbr when you efibootmgr'd it. The UEFI could load speculatively and display
a computed vbr for an image it loaded and didn't recognize. The user could then check
the the web for a trusted opinion and bail or proceed (given UEFI password) to accept
the new image and white-list it with one-shot trial boot if desired.

This would also be a nice way to validate a boot-to-guile image ;-)

--
Regards,
Bengt Richter
Z
Z
zimoun wrote on 16 Dec 2019 16:25
(name . Bengt Richter)(address . bokr@bokr.com)
CAJ3okZ3KYRW3mZPMsumD_ZhL9GvXFfuLVahJ6Ft6oc=VR1ZimA@mail.gmail.com
Hi Bengt,

On Sun, 15 Dec 2019 at 23:15, Bengt Richter <bokr@bokr.com> wrote:

Toggle quote (2 lines)
> How about an interplanetary font folder? cf. IPLD[1] :-)

I am not sure it is related to the issue discussed here, IMHO.

However, if you are interested in IPFS stuff, give a look at this
patch [#] because it still needs some love to be merged...



All the best,
simon
?