requiring a (non-specific) font?

[Matthew Miller]

I happened to install Scratch onto a remove VM (on Fedora Infrastructure's
new private cloud, in fact) where no fonts were installed. It runs, but
Pango throws warnings about not having anything for 'latin' or 'common'
--
and of course the UI has boxes where the menus and variables should be.

I could require something generic, like 'font(:lang=en)', but that's likely
to pull in a random decorative font.

I could require some specific font, but that seems wrong. (Particularly
since if a "better" match for latin or common happen to be installed,
whatever I said is a requirement will actually be irrelevant.)

Orrr, should I just not worry about this case?

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Bill Nottingham]

Matthew Miller (mattdm(a)fedoraproject.org) said: 
>  I happened to install Scratch onto a remove VM (on Fedora
> Infrastructure's
>  new private cloud, in fact) where no fonts were installed. It runs, but
>  Pango throws warnings about not having anything for 'latin' or 'common'
> --
>  and of course the UI has boxes where the menus and variables should be.
>  
>  I could require something generic, like 'font(:lang=en)', but that's likely
>  to pull in a random decorative font.
>  
>  I could require some specific font, but that seems wrong. (Particularly
>  since if a "better" match for latin or common happen to be installed,
>  whatever I said is a requirement will actually be irrelevant.)
>  
>  Orrr, should I just not worry about this case? 
Generally, if you want to run graphical apps, install the @fonts group -
this gives you the preferred default fonts for all of the languages we
support.

If you only care about Latin fonts, just grab dejavu-{sans,serif,mono}-fonts
and be done with it.

Bill

[Matthew Miller]

On Fri, Sep 28, 2012 at 04:37:33PM -0400, Bill Nottingham wrote:
>  > I could require some specific font, but that seems wrong.
> (Particularly
>  > since if a "better" match for latin or common happen to be installed,
>  > whatever I said is a requirement will actually be irrelevant.)
>  > Orrr, should I just not worry about this case?
>  Generally, if you want to run graphical apps, install the @fonts group -
>  this gives you the preferred default fonts for all of the languages we
>  support. 
So from a packaging point of view, don't worry that the package plus all of
its dependencies installed doesn't really function?


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Omair Majid]

On 09/28/2012 04:14 PM, Matthew Miller wrote:
>  I happened to install Scratch onto a remove VM (on Fedora
> Infrastructure's
>  new private cloud, in fact) where no fonts were installed. It runs, but
>  Pango throws warnings about not having anything for 'latin' or 'common'
> --
>  and of course the UI has boxes where the menus and variables should be.
>  
>  I could require something generic, like 'font(:lang=en)', but that's likely
>  to pull in a random decorative font.
>  
>  I could require some specific font, but that seems wrong. (Particularly
>  since if a "better" match for latin or common happen to be installed,
>  whatever I said is a requirement will actually be irrelevant.)
>  
>  Orrr, should I just not worry about this case?
>   
How about installing fonts on demand? PackageKit has some support for
this [1] [2]. Pango should be using it already, in fact. So this sounds
like a bug.

Cheers,
Omair

[1] http://fedoraproject.org/wiki/Features/AutomaticFontInstallation
[2]
http://blogs.gnome.org/hughsie/2008/12/01/packagekit-and-pango-are-now-fr...

[Nicolas Mailhot]

Le Sam 29 septembre 2012 05:06, Matthew Miller a écrit :
>  On Fri, Sep 28, 2012 at 04:37:33PM -0400, Bill Nottingham wrote:
> > > I could require some specific font, but that seems wrong.
> > (Particularly
> > > since if a "better" match for latin or common happen to be installed,
> > > whatever I said is a requirement will actually be irrelevant.)
> > > Orrr, should I just not worry about this case?
> > Generally, if you want to run graphical apps, install the @fonts group -
> > this gives you the preferred default fonts for all of the languages we
> > support.
>
>  So from a packaging point of view, don't worry that the package plus all
>  of
>  its dependencies installed doesn't really function? 
The Fedora default font set is provided by the @fonts group. So if you
install anything that needs fonts, you should have this group in your
kickstart. Not different than any other basic needs group which is not
explicitly required by packages. And there is no simpler way to name a
fonts-providing groups than fonts.

If you feel i18n was over-enthusiastic with @fonts, you are free to
specify explicitly the fonts you need or use a generic provide such as
font(:lang=sw). The generic provides are pretty basic because fonts would
really need n-uplet provides, but rpm only understands single tokens.
Because we do no use hard dependencies, font selection can be customized
as needed (you are free to shot yourself in the foot).

Given how widespread font use is and how varied font selection criteria
are I doubt you could find a dependency system that would be even remotely
satisfying to users. Not to mention that fonts overlap in strange an
non-intuitive ways (and never completely), and any attempt would bloat yum
indexes a lot.

Of course it was all way simpler in ASCII bitmap times.

-- 
Nicolas Mailhot

[Miroslav Suchý]

On 09/28/2012 10:14 PM, Matthew Miller wrote:
>  I could require something generic, like 'font(:lang=en)', but
> that's likely
>  to pull in a random decorative font. 
Interesting, I did not know about font(:lang=en)...

I would use this, even if it pull decorative font. I met this problem 
once in past. Without any font, it took me some time to debug that 
problem and find up what is cause of the problem, because the error was 
not straightforward - there was nothing like "error: no fonts found"

But if the application will start and everything is painted with 
decorative font, it will ring bells immediately.

-- 
Miroslav Suchy
Red Hat Systems Management Engineering