he manual"
> because I have the fonts installed; especially font-dejavu (and
> gs-fonts too).
The missing fonts were in images (PNG files) embedded in the manual, so
it does not matter what you have installed: they are not rendered when
you open the .png, unlike e.g. SVG or a rich text document.
&
1418; I have never commented on.
I do not understand why you are saying "missing font in the manual"
because I have the fonts installed; especially font-dejavu (and
gs-fonts too).
Well, I do not understand neither how c81457a588 can work nicely and
not 23a59b180b with the exact same setu
On Wed, May 20, 2020 at 01:28:13PM +0200, Marius Bakke wrote:
> The print infrastructure (CUPS, ghostscript) does not use Pango, so I
> think gs-fonts still work there.
>
> Might be difficult to work with when the end user applications don't
> recognize them though.
>
>
lable such as 'guix pack's.
>>
>> I'm not sure whether font-dejavu is a good replacement here. Another
>> approach could be to convert gs-fonts to TrueType or OpenType format.
>>
>> Thoughts? I don't know much about fonts and would appreciate
zimoun writes:
> On Wed, 20 May 2020 at 15:55, Marius Bakke wrote:
>> zimoun writes:
>
>> > Apparently, there is different fonts on master and core-updates, if yes
>> > why?
>>
>> The only known difference since the core-updates merge is that
>> applications using Pango (e.g. GTK+) no longer r
On Wed, 20 May 2020 at 15:55, Marius Bakke wrote:
> zimoun writes:
> > Apparently, there is different fonts on master and core-updates, if yes why?
>
> The only known difference since the core-updates merge is that
> applications using Pango (e.g. GTK+) no longer recognizes bitmap fonts.
>
> h
zimoun writes:
> Apparently, there is different fonts on master and core-updates, if yes why?
The only known difference since the core-updates merge is that
applications using Pango (e.g. GTK+) no longer recognizes bitmap fonts.
https://gitlab.gnome.org/GNOME/pango/issues/386
> I mean, on my
make (some) fonts working when users don't have fonts
> specified in their system configuration, and (crucially) places where
> the fontconfig cache may be unavailable such as 'guix pack's.
>
> I'm not sure whether font-dejavu is a good replacement here. Another
>
lable such as 'guix pack's.
>>
>> I'm not sure whether font-dejavu is a good replacement here. Another
>> approach could be to convert gs-fonts to TrueType or OpenType format.
>>
>> Thoughts? I don't know much about fonts and would appreciate
gt;
> I'm not sure whether font-dejavu is a good replacement here. Another
> approach could be to convert gs-fonts to TrueType or OpenType format.
>
> Thoughts? I don't know much about fonts and would appreciate feedback.
I think you should push right away, assuming tha
working when users don't have fonts
specified in their system configuration, and (crucially) places where
the fontconfig cache may be unavailable such as 'guix pack's.
I'm not sure whether font-dejavu is a good replacement here. Another
approach could be to convert gs-font
is looks like too much work to implement for each package separately.
> And as a permanent solution, I do not like it.
>
>> Alternately, we could provide a wrapper containing a ‘gs’ symlink.
>
> This would be one option. Or we could add another package, corresponding
> to the p
> > gnu: ghostscript: Do not build the statically-linked 'gs' binary.
> >
> > * gnu/packages/ghostscript.scm (ghostscript)[arguments]: Remove
> > 'build-so' and 'install-so' phases. Replace 'build' and 'install
h package separately.
And as a permanent solution, I do not like it.
> Alternately, we could provide a wrapper containing a ‘gs’ symlink.
This would be one option. Or we could add another package, corresponding
to the previous definition, that we would use only as an input to the
packages in core-
Andreas Enge writes:
> Hello,
>
> the following commit
> commit eb354bdacbf4154ec66038dac07f19bf4ced1fad
> Author: Ludovic Courtès
> Date: Mon May 9 15:54:34 2016 +0200
>
> gnu: ghostscript: Do not build the statically-linked 'gs' binary.
>
Hi!
Andreas Enge skribis:
> the following commit
> commit eb354bdacbf4154ec66038dac07f19bf4ced1fad
> Author: Ludovic Courtès
> Date: Mon May 9 15:54:34 2016 +0200
>
> gnu: ghostscript: Do not build the statically-linked 'gs' binary.
>
>
Andreas Enge writes:
> Hello,
>
> the following commit
> commit eb354bdacbf4154ec66038dac07f19bf4ced1fad
> Author: Ludovic Courtès
> Date: Mon May 9 15:54:34 2016 +0200
>
> gnu: ghostscript: Do not build the statically-linked 'gs' binary.
>
Hello,
the following commit
commit eb354bdacbf4154ec66038dac07f19bf4ced1fad
Author: Ludovic Courtès
Date: Mon May 9 15:54:34 2016 +0200
gnu: ghostscript: Do not build the statically-linked 'gs' binary.
* gnu/packages/ghostscript.scm (ghostscript)[arguments]: Remove
Ricardo Wurmus skribis:
> the attached patch changes the result of ‘(search-gs)’ in the Lilypond
> backend, such that it returns the “gs” executable from the very same
> version of ghostscript that Lilypond was built with.
>
> Retaining a reference to ghostscript causes a closur
Hi Guix,
the attached patch changes the result of ‘(search-gs)’ in the Lilypond
backend, such that it returns the “gs” executable from the very same
version of ghostscript that Lilypond was built with.
Retaining a reference to ghostscript causes a closure increase from
309.9 to 351.2. “gs” is
20 matches
Mail list logo
