GNU bug report logs - #44191
gnu: Add kristall

Previous Next

Full log

View this message in rfc822 format

From: Nicolò Balzarotti <anothersms <at> gmail.com>
To: Christopher Baines <mail <at> cbaines.net>
Cc: 44191 <at> debbugs.gnu.org, nicolo <at> nixo.xyz
Subject: [bug#44191] gnu: Add kristall
Date: Sat, 14 Nov 2020 15:52:35 +0100

[Message part 1 (text/plain, inline)]

Hi Chris!

Sorry for the delay, here's the updated patch.  I addedd
breeze-stylesheet as an input, and added the phase
"dont-use-bundled-fonts" that replaces relative links to absolute links
to the fonts, as you suggested.  I also added the copyright line I
forgot.

Thanks again!
Nicolò

[v2-0001-gnu-Add-kristall.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

Christopher Baines <mail <at> cbaines.net> writes:

> Nicolò Balzarotti <anothersms <at> gmail.com> writes:
>
>> Christopher Baines <mail <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.