[bug#44191] gnu: Add kristall

["Nicolò Balzarotti" <anothersms@gmail.com>]

Hi!
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'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.

Let me know and thanks again,
Nicolò

[1] https://unicode.org/Public/emoji/1.0/emoji-data.txt