LibreOffice Fonts

LibreOffice Fonts

[Tom Balzer]

Hello -

Recently I installed libreoffice in my user profile, and found that all
menus require the package 'font-gnu-freetype-ttf' in order to render
correctly. Without this package, every character was rendered as a
rectangle indicating a missing font. From the manuals description of
'propagated-inputs', it seems like this font package would fit the use
case: 

> Lastly, ‘propagated-inputs’ is similar to ‘inputs’, but the
> specified packages will be automatically installed alongside
> the package they belong to (*note ‘guix package’:
> package-cmd-propagated-inputs, for information on how ‘guix
> package’ deals with propagated inputs.)
> 
> For example this is necessary when a C/C++ library needs
> headers of another library to compile, or when a pkg-config
> file refers to another one via its ‘Requires’ field.

I asked on #guix, and one argument against including fonts in propagated
inputs is to avoid packaging the font when 'pack'ing for another
system. This to me is really an argument for including the fonts, since
there is no guarantee that the other system is 'rational', so to
speak. To create totally portable packages I would think including this
font required to render the menus would make sense.

Thanks,
Tom

Re: LibreOffice Fonts

[ng0]

[-- Attachment #1: Type: text/plain, Size: 1785 bytes --]

Tom Balzer transcribed 1.3K bytes:
> 
> Hello -
> 
> Recently I installed libreoffice in my user profile, and found that all
> menus require the package 'font-gnu-freetype-ttf' in order to render
> correctly. Without this package, every character was rendered as a
> rectangle indicating a missing font. From the manuals description of
> 'propagated-inputs', it seems like this font package would fit the use
> case: 
> 
> > Lastly, ‘propagated-inputs’ is similar to ‘inputs’, but the
> > specified packages will be automatically installed alongside
> > the package they belong to (*note ‘guix package’:
> > package-cmd-propagated-inputs, for information on how ‘guix
> > package’ deals with propagated inputs.)
> > 
> > For example this is necessary when a C/C++ library needs
> > headers of another library to compile, or when a pkg-config
> > file refers to another one via its ‘Requires’ field.
> 
> I asked on #guix, and one argument against including fonts in propagated
> inputs is to avoid packaging the font when 'pack'ing for another
> system. This to me is really an argument for including the fonts, since
> there is no guarantee that the other system is 'rational', so to
> speak. To create totally portable packages I would think including this
> font required to render the menus would make sense.
> 
> Thanks,
> Tom
> 
> 

I have a problem with making decision on default fonts. What if someone
doesn't want gnu-freetype-ttf? It is not just only this font, you can use
any font and sometimes this will depend on fc-cache -fv which is mentioned
in the documentation.
-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://krosos.org/dist/keys/
https://www.infotropique.org https://krosos.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: LibreOffice Fonts

[Tom Balzer]

ng0 writes:

> I have a problem with making decision on default fonts. What if someone
> doesn't want gnu-freetype-ttf? It is not just only this font, you can use
> any font and sometimes this will depend on fc-cache -fv which is mentioned
> in the documentation.

By 'in the documentation', do you mean the documentation for how fonts
work in guix, or libreoffice's documentation? If the latter, then yes I
see that you could start libreoffice with a gtk theme definition
to control the fonts, allowing for other font choices. But in the case
where one just launched libre office, wouldn't you expect that it
'works' running out of just the package files? If you include no font
that wouldn't work, which seems like sacrificing basic functionality in
order to avoid including a font that someone might not desire.

Couldn't that argument be made for any features above bare minimum for
any application? For instance, someone might not want a support library
for emacs that enables viewing jpegs, but the default package supports
this. I think that removing a feature from a package definition if you
don't want a feature makes more sense than crippling a package with
non-sane defaults.

Tom

Re: LibreOffice Fonts

[ng0]

[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]

Tom Balzer transcribed 1.2K bytes:
> 
> ng0 writes:
> 
> > I have a problem with making decision on default fonts. What if someone
> > doesn't want gnu-freetype-ttf? It is not just only this font, you can use
> > any font and sometimes this will depend on fc-cache -fv which is mentioned
> > in the documentation.
> 
> By 'in the documentation', do you mean the documentation for how fonts
> work in guix, or libreoffice's documentation? If the latter, then yes I
> see that you could start libreoffice with a gtk theme definition
> to control the fonts, allowing for other font choices. But in the case
> where one just launched libre office, wouldn't you expect that it
> 'works' running out of just the package files? If you include no font
> that wouldn't work, which seems like sacrificing basic functionality in
> order to avoid including a font that someone might not desire.
> 
> Couldn't that argument be made for any features above bare minimum for
> any application?

No, that's something entirely different from propagating fonts.

> For instance, someone might not want a support library
> for emacs that enables viewing jpegs, but the default package supports
> this. I think that removing a feature from a package definition if you
> don't want a feature makes more sense than crippling a package with
> non-sane defaults.
> 
> Tom
> 


I think you want to read past discussions on this still open problem:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26877
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=18640
-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://krosos.org/dist/keys/
https://www.infotropique.org https://krosos.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: LibreOffice Fonts

[Ludovic Courtès]

Hello Tom,

Tom Balzer <tbalzer@ksu.edu> skribis:

> Recently I installed libreoffice in my user profile, and found that all
> menus require the package 'font-gnu-freetype-ttf' in order to render
> correctly. Without this package, every character was rendered as a
> rectangle indicating a missing font.

Every character in the body of the text, or every character in the UI?

> From the manuals description of 'propagated-inputs', it seems like
> this font package would fit the use case:
>
>> Lastly, ‘propagated-inputs’ is similar to ‘inputs’, but the
>> specified packages will be automatically installed alongside
>> the package they belong to (*note ‘guix package’:
>> package-cmd-propagated-inputs, for information on how ‘guix
>> package’ deals with propagated inputs.)
>> 
>> For example this is necessary when a C/C++ library needs
>> headers of another library to compile, or when a pkg-config
>> file refers to another one via its ‘Requires’ field.
>
> I asked on #guix, and one argument against including fonts in propagated
> inputs is to avoid packaging the font when 'pack'ing for another
> system. This to me is really an argument for including the fonts, since
> there is no guarantee that the other system is 'rational', so to
> speak. To create totally portable packages I would think including this
> font required to render the menus would make sense.

I think it’s a borderline case.  In a sense, the font is additional
material used as input by LO (and indeed LO is much less useful without
it, but it’s still LO), though I can also understand the other argument.

My current inclination would be the status quo.  Otherwise we’d have to
worry about fonts and artwork for Abiword, Inkscape, etc. as well.

Thoughts?

Ludo’.

Re: LibreOffice Fonts

[ng0]

[-- Attachment #1: Type: text/plain, Size: 2331 bytes --]

Ludovic Courtès transcribed 1.8K bytes:
> Hello Tom,
> 
> Tom Balzer <tbalzer@ksu.edu> skribis:
> 
> > Recently I installed libreoffice in my user profile, and found that all
> > menus require the package 'font-gnu-freetype-ttf' in order to render
> > correctly. Without this package, every character was rendered as a
> > rectangle indicating a missing font.
> 
> Every character in the body of the text, or every character in the UI?
> 
> > From the manuals description of 'propagated-inputs', it seems like
> > this font package would fit the use case:
> >
> >> Lastly, ‘propagated-inputs’ is similar to ‘inputs’, but the
> >> specified packages will be automatically installed alongside
> >> the package they belong to (*note ‘guix package’:
> >> package-cmd-propagated-inputs, for information on how ‘guix
> >> package’ deals with propagated inputs.)
> >> 
> >> For example this is necessary when a C/C++ library needs
> >> headers of another library to compile, or when a pkg-config
> >> file refers to another one via its ‘Requires’ field.
> >
> > I asked on #guix, and one argument against including fonts in propagated
> > inputs is to avoid packaging the font when 'pack'ing for another
> > system. This to me is really an argument for including the fonts, since
> > there is no guarantee that the other system is 'rational', so to
> > speak. To create totally portable packages I would think including this
> > font required to render the menus would make sense.
> 
> I think it’s a borderline case.  In a sense, the font is additional
> material used as input by LO (and indeed LO is much less useful without
> it, but it’s still LO), though I can also understand the other argument.
> 
> My current inclination would be the status quo.  Otherwise we’d have to
> worry about fonts and artwork for Abiword, Inkscape, etc. as well.
> 
> Thoughts?
> 
> Ludo’.
> 
> 

What about an fontcache-service that basically
is mcron running daily "fc-cache -f"
or even "fc-cache -fr"?

That would be the closest to a post-setup hook
refreshing font caches like people could be used
to from Archlinux etc.
-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://krosos.org/dist/keys/
https://www.infotropique.org https://krosos.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: LibreOffice Fonts

[Maxim Cournoyer]

ng0 <ng0@infotropique.org> writes:

> Ludovic Courtès transcribed 1.8K bytes:
>> Hello Tom,
>> 
>> Tom Balzer <tbalzer@ksu.edu> skribis:
>> 
>> > Recently I installed libreoffice in my user profile, and found that all
>> > menus require the package 'font-gnu-freetype-ttf' in order to render
>> > correctly. Without this package, every character was rendered as a
>> > rectangle indicating a missing font.
>> 
>> Every character in the body of the text, or every character in the UI?
>> 
>> > From the manuals description of 'propagated-inputs', it seems like
>> > this font package would fit the use case:
>> >
>> >> Lastly, ‘propagated-inputs’ is similar to ‘inputs’, but the
>> >> specified packages will be automatically installed alongside
>> >> the package they belong to (*note ‘guix package’:
>> >> package-cmd-propagated-inputs, for information on how ‘guix
>> >> package’ deals with propagated inputs.)
>> >> 
>> >> For example this is necessary when a C/C++ library needs
>> >> headers of another library to compile, or when a pkg-config
>> >> file refers to another one via its ‘Requires’ field.
>> >
>> > I asked on #guix, and one argument against including fonts in propagated
>> > inputs is to avoid packaging the font when 'pack'ing for another
>> > system. This to me is really an argument for including the fonts, since
>> > there is no guarantee that the other system is 'rational', so to
>> > speak. To create totally portable packages I would think including this
>> > font required to render the menus would make sense.
>> 
>> I think it’s a borderline case.  In a sense, the font is additional
>> material used as input by LO (and indeed LO is much less useful without
>> it, but it’s still LO), though I can also understand the other argument.
>> 
>> My current inclination would be the status quo.  Otherwise we’d have to
>> worry about fonts and artwork for Abiword, Inkscape, etc. as well.
>> 
>> Thoughts?
>> 
>> Ludo’.
>> 
>> 
>
> What about an fontcache-service that basically
> is mcron running daily "fc-cache -f"
> or even "fc-cache -fr"?

Is there no way to provide it the way it should, i.e. as a
profile hook? I understand the issue that the cache generated would be
read-only, but that cache would be in the system and users running
fc-cache themselves would produce cache in their $HOME, so I don't
immediately see an issue there (other than I haven't had time yet to
look into it -- it's on my TODO).

Maxim

Re: LibreOffice Fonts

[Ludovic Courtès]

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> ng0 <ng0@infotropique.org> writes:

[...]

>> What about an fontcache-service that basically
>> is mcron running daily "fc-cache -f"
>> or even "fc-cache -fr"?
>
> Is there no way to provide it the way it should, i.e. as a
> profile hook? I understand the issue that the cache generated would be
> read-only, but that cache would be in the system and users running
> fc-cache themselves would produce cache in their $HOME, so I don't
> immediately see an issue there (other than I haven't had time yet to
> look into it -- it's on my TODO).

We could have a profile hook that creates the cache, but how would we
arrange to have ~/.cache/fontconfig pointing to the right thing?

I mean ‘guix package’ could modify ~/.cache/fontconfig, but that’s not
something we’ve done until now (‘guix package’ only touches
~/.guix-profile and /var/guix/profiles.)

Thoughts?

Ludo’.