guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#44191] gnu: Add kristall


From: Christopher Baines
Subject: [bug#44191] gnu: Add kristall
Date: Tue, 10 Nov 2020 19:57:51 +0000
User-agent: mu4e 1.4.13; emacs 27.1

Nicolò Balzarotti <anothersms@gmail.com> writes:

> Christopher Baines <mail@cbaines.net> writes:
>>
>> Given this is a stylesheet, rather than cmark, I don't think it's a
>> blocker, although I do think it would be neater to have a package for
>> it.
>>
> Would it be better to at least pass it's origin as an input?
>
> #+begin_src scheme
>   ("breeze-stylesheet"
>    ,(origin
>       (method git-fetch)
>       (uri
>        (git-reference
>       (url "https://github.com/Alexhuszagh/BreezeStyleSheets";)
>       (commit "2d595a956f8a5f493aa51139a470b768a6d82cce")))
>       (file-name (git-file-name name version))
>       (sha256
>        (base32
>       "1kvkxkisi3czldnb43ig60l55pi4a3m2a4ixp7krhpf9fc5wp294"))))
> #+end_src
>
> I'm ok with making a package for it, but in that case I'm not sure what
> to do.  I think I'd use the copy-build-system, right? Should the package
> be hidden?

I don't mind, I think it's OK as is.

>> I've made some more comments below, and I wanted to enquire about
>> exactly how the fonts are used, but I think this is pretty much ready to
>> merge.
>>
>> I'd maybe use symlink rather than copy file, since you want the fonts to
>> be used from the respective packages in the store, however, is this just
>> to satisfy the build system? It looks to me like the XDG_DATA_DIRS
>> wrapping is probably what'll make the fonts work at runtime (if
>> anything)?
>
> Regarding fonts,
> I tried removing both from the inputs, and emojis at this page [1]
> rendered just fine.
> Should I just remove them from the inputs and let the user install them?
> The code tries to load them with the relative path:
>
> #+begin_src cpp
> // Provide OpenMoji font for a safe fallback
> QFontDatabase::addApplicationFont(":/fonts/OpenMoji-Color.ttf");
> QFontDatabase::addApplicationFont(":/fonts/NotoColorEmoji.ttf");
> #+end_src
>
> This function fails silently (The function returns -1 if the font could
> not be loaded.) and the error code is not checked, so we don't even need
> to patch kristall source for this.

If there's an expectation or a use in making sure these fonts are
available, it would be good to patch the relative paths to be the
absolute paths within the font-openmoji package.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]