[gentoo-dev] Fonts, Xfree, Linux

[gentoo-dev] Fonts, Xfree, Linux

[Seemant Kulleen]

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

Hi All,

OK, the above combination, as we all know, blows dogs.  Having said that, I have some ideas.  First, to reiterate as in my last e-mail: xfree-4.3.0-r3 is moving towards *NOT* installing *ANY* fonts at all.  All the xfree built-in fonts will move to separate packages in media-fonts.  Additionally *ALL* fonts will be in /usr/share/fonts, rather than /usr/X11R6/lib/X11/fonts (and I had to hold back from exaggerating it to say /usr/X11R6/lib/X11/R6/include/lib/X/X11/X11R6/misc/lib/fonts :P).

The idea is that this will be a centralised location for system fonts.  All user custom fonts would go into /usr/share/fonts (or perhaps /usr/local/share/fonts -- not sure on that one, and not sure how much complexity it would add).

Anyway, RedHat developed a tool called chkfontpath which updates /etc/X11/fs/config with font paths to be added, removed, queried and what not. It seems most binary distros distribute this utility.  We had a look at it (popt is a required dependency for it), and I've asked Graham (vladimir@g.o) to come up with a perl equivalent for it.  To me, it seems that coding that in C and using popt is overkill.

So the idea he and I discussed was to have this utility (or set of utilities) to update the fontpaths in /etc/X11/fs/config as well as /etc/X11/XF86Config (IF the font path is other than unix:/7100 in that file).

Now, here's the question.  Gentoo policy dictates that we do not touch files in /etc.  During emerge, this is fine, we can provide a file to be etc-update'd.  The concern is during emerge unmerge, when a font path is to be removed.

I guess the question is: do we violate policy on these two files, or is there a more clever solution to this?  One thought which comes up is to have the utility just check which font paths exist in /usr/share/fonts and make sure both files have them.  Again, that would violate policy :/

The other thought which arises is to have those files in /usr/share/xfree or some such, but I'm not entirely comfortable with that, either.


Thoughts, opinions, criticisms?

Thanks,

-- 
Seemant Kulleen
Developer and Project Co-ordinator,
Gentoo Linux					http://www.gentoo.org/~seemant

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E
Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Fonts, Xfree, Linux

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2581 bytes --]

On Friday 30 May 2003 11:30, Seemant Kulleen wrote:
> Hi All,
>
> OK, the above combination, as we all know, blows dogs.  Having said that, I
> have some ideas.  First, to reiterate as in my last e-mail: xfree-4.3.0-r3
> is moving towards *NOT* installing *ANY* fonts at all.  All the xfree
> built-in fonts will move to separate packages in media-fonts.  Additionally
> *ALL* fonts will be in /usr/share/fonts, rather than
> /usr/X11R6/lib/X11/fonts (and I had to hold back from exaggerating it to
> say /usr/X11R6/lib/X11/R6/include/lib/X/X11/X11R6/misc/lib/fonts :P).
>
> The idea is that this will be a centralised location for system fonts.  All
> user custom fonts would go into /usr/share/fonts (or perhaps
> /usr/local/share/fonts -- not sure on that one, and not sure how much
> complexity it would add).
>
> Anyway, RedHat developed a tool called chkfontpath which updates
> /etc/X11/fs/config with font paths to be added, removed, queried and what
> not. It seems most binary distros distribute this utility.  We had a look
> at it (popt is a required dependency for it), and I've asked Graham
> (vladimir@g.o) to come up with a perl equivalent for it.  To me, it seems
> that coding that in C and using popt is overkill.
>
> So the idea he and I discussed was to have this utility (or set of
> utilities) to update the fontpaths in /etc/X11/fs/config as well as
> /etc/X11/XF86Config (IF the font path is other than unix:/7100 in that
> file).
>
> Now, here's the question.  Gentoo policy dictates that we do not touch
> files in /etc.  During emerge, this is fine, we can provide a file to be
> etc-update'd.  The concern is during emerge unmerge, when a font path is to
> be removed.
>
> I guess the question is: do we violate policy on these two files, or is
> there a more clever solution to this?  One thought which comes up is to
> have the utility just check which font paths exist in /usr/share/fonts and
> make sure both files have them.  Again, that would violate policy :/
>
> The other thought which arises is to have those files in /usr/share/xfree
> or some such, but I'm not entirely comfortable with that, either.
>

I think we could have some utility that takes the real XF86Config and creates 
a new file for it. This could just be ._cfg0001_XF86Config, where it checks 
for other versions and if the differences are only with the fonts overwrites 
it, else not. This way we simulate config protection.

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Fonts, Xfree, Linux

[Ian Phillips]

> had a look at it (popt is a required dependency for it), and I've
> asked Graham (vladimir@g.o) to come up with a perl equivalent for it.  To me, it seems that coding that in C and using popt is overkill.

Surely Python would be more Gentoo-ish?

As to files in /etc, how about this as a first hack: modify etc-update
so that an ebuild can mark a file in /etc as requiring manual attention
and possibly an optional short text message. I'm not sure of the best
way to do this, but maybe if etc-update finds an update file with some
magic string as the first line then it will say that the file needs
attention. The file could just be a pointer to the user to run
GentooFontUpdater or whatever the new tool is called.

It seems (more than) a little hacky, but I think that not touching files
in /etc is a good rule, and think it's worth putting some effort into a
way of not breaking it.

Ian.

-- 
#ifndef  __COMMON_SENSE__ | Ian Phillips
#include <std_disclaimer> | TIBCO Software Inc.
#endif                    | www.tibco.com




--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Fonts, Xfree, Linux

[Terje Kvernes]

Seemant Kulleen <seemant@gentoo.org> writes:

  [ ... ]

> Anyway, RedHat developed a tool called chkfontpath which updates
> /etc/X11/fs/config with font paths to be added, removed, queried and
> what not. It seems most binary distros distribute this utility.  We
> had a look at it (popt is a required dependency for it), and I've
> asked Graham (vladimir@g.o) to come up with a perl equivalent for
> it.  To me, it seems that coding that in C and using popt is
> overkill.
  
  if a working tool exists, is it really worth rewriting the tool just
  to remove popt as a dependency?  actually, to me it seems that
  you're removing popt and adding perl as a dependency.  :-)

> So the idea he and I discussed was to have this utility (or set of
> utilities) to update the fontpaths in /etc/X11/fs/config as well as
> /etc/X11/XF86Config (IF the font path is other than unix:/7100 in
> that file).

  is this something chkfontpath already does, or something
  Gentoo-specific and new?
 
  [ ... ]

  now, as for policy...  when you install a font, you probably want it
  to be available for X.  then again, it's sort of the same thing with
  a daemon, and rc-update.  a common behavior is a good thing, even if
  it requires some monotonous user action every time.  as long as the
  behavior is well documented, I don't see a big problem it.

-- 
Terje

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Fonts, Xfree, Linux

[Seemant Kulleen]

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

On Fri, 30 May 2003 15:03:39 +0200
Terje Kvernes <terjekv@math.uio.no> wrote:
  
>   if a working tool exists, is it really worth rewriting the tool just
>   to remove popt as a dependency?  actually, to me it seems that
>   you're removing popt and adding perl as a dependency.  :-)

The xfree ebuild as it currently stands has perl as a dependency for the font generation stuff anyway, so it is not adding anything new.

 
> > So the idea he and I discussed was to have this utility (or set of
> > utilities) to update the fontpaths in /etc/X11/fs/config as well as
> > /etc/X11/XF86Config (IF the font path is other than unix:/7100 in
> > that file).
> 
>   is this something chkfontpath already does, or something
>   Gentoo-specific and new?

The latter.

>   [ ... ]
> 
>   now, as for policy...  when you install a font, you probably want it
>   to be available for X.  then again, it's sort of the same thing with
>   a daemon, and rc-update.  a common behavior is a good thing, even if
>   it requires some monotonous user action every time.  as long as the
>   behavior is well documented, I don't see a big problem it.

More or less agree with this.


> -- 
> Terje
> 
> --
> gentoo-dev@gentoo.org mailing list
> 
> 


-- 
Seemant Kulleen
Developer and Project Co-ordinator,
Gentoo Linux					http://www.gentoo.org/~seemant

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E
Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Fonts, Xfree, Linux

[Spider]

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

begin  quote
On Fri, 30 May 2003 02:30:39 -0700
Seemant Kulleen <seemant@gentoo.org> wrote:

> 
> So the idea he and I discussed was to have this utility (or set of
> utilities) to update the fontpaths in /etc/X11/fs/config as well as
> /etc/X11/XF86Config (IF the font path is other than unix:/7100 in that
> file).
> 

What will such a tool do about ordering of paths?  There is a sticky
issue here when two paths provide the same fonts, something that is
completely legal. Now, anyone who has customized their X to some extent
knows this, and many are quite picky about the order.  putting Speedo
after fixed, TTF before fixed, unscaled before scaled, Xdpi before
other dpi.

Theese settings are fairly custom, and to give an automatic tool a go at
this is annoying. (font-update, following modules-update and others.. )

Now, how would this be handled?   Should a user have to specify the
ordering of such fonts in a separate file? (Yey, another config +
verifying the autogenerated tool?)   or perhaps not install them at all?
(Not good either, Xnest, different X layout and other such things come
in and annoy here)


otherways I'm all for standardizing portage installed fonts (that aren't
X core) in /usr/share/fonts/<fonttype>  , having a tool to run
fc-update and otheres.  System local fonts ( my import of  fonts
from adobe, and so on) should go to /usr/local/share/fonts/, as is
custom.


//Spider

-- 
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Fonts, Xfree, Linux

[Svyatogor]

On Friday 30 May 2003 09:30, Seemant Kulleen wrote:
> OK, the above combination, as we all know, blows dogs.  Having said that, I
> have some ideas.  First, to reiterate as in my last e-mail: xfree-4.3.0-r3
> is moving towards *NOT* installing *ANY* fonts at all.  All the xfree
> built-in fonts will move to separate packages in media-fonts.  Additionally
> *ALL* fonts will be in /usr/share/fonts, rather than
> /usr/X11R6/lib/X11/fonts (and I had to hold back from exaggerating it to
> say /usr/X11R6/lib/X11/R6/include/lib/X/X11/X11R6/misc/lib/fonts :P).

Hello!
If  you don't mind me giving some comments on it. The idea to move all the 
fonts to /usr/share/fonts is great and actually it is necessary, cause 
otherwise the whole font tre is a big mess.

However, I am not so sure about the first part of the suggestion, which is not 
installing any fonts with xfree. When I first installed gentoo, I remember 
being very please with the fact that after emerging xfree I got a proper 
support of cyrillic fonts staringht away. I did not have it in any other 
distro: they all required me to install additional packages to get something 
different from default fonts, which have very ugly cyrullic chars or don't 
support them at all.

What I am trying basically to say, is that users should be getting reasonable 
set of fonts, with proper support of their local chars right after installing 
xfree and not have to search in portage to get at least some fonts with their 
local glyphs.

Regards,
-- 
Sergey Kuleshov <svyatogor@gentoo.org>
Let the Force be with us!


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Fonts, Xfree, Linux

[Svyatogor]

On Friday 30 May 2003 13:31, Spider wrote:
> begin  quote
> On Fri, 30 May 2003 02:30:39 -0700
>
> Seemant Kulleen <seemant@gentoo.org> wrote:
> > So the idea he and I discussed was to have this utility (or set of
> > utilities) to update the fontpaths in /etc/X11/fs/config as well as
> > /etc/X11/XF86Config (IF the font path is other than unix:/7100 in that
> > file).
>
> What will such a tool do about ordering of paths?  There is a sticky
> issue here when two paths provide the same fonts, something that is
> completely legal. Now, anyone who has customized their X to some extent
> knows this, and many are quite picky about the order.  putting Speedo
> after fixed, TTF before fixed, unscaled before scaled, Xdpi before
> other dpi.
>
> Theese settings are fairly custom, and to give an automatic tool a go at
> this is annoying. (font-update, following modules-update and others.. )

I abosultely agree with you! Also, if I put localised fonts after generic I 
lose local glyphs totaly and completely. So it is extremely important to have 
some way to specify the order of the fonts.

-- 
Sergey Kuleshov <svyatogor@gentoo.org>
Let the Force be with us!


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Fonts, Xfree, Linux

[matsuu]

Hi.

I just posted chkfontpath and font.eclass(#21932, #13808).

---
MATSUU Takuto <matsuu@7501.net>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Fonts, Xfree, Linux

[Dan Armak]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1184 bytes --]

On Friday 30 May 2003 19:21, Svyatogor wrote:
> However, I am not so sure about the first part of the suggestion, which is
> not installing any fonts with xfree. When I first installed gentoo, I
> remember being very please with the fact that after emerging xfree I got a
> proper support of cyrillic fonts staringht away. I did not have it in any
> other distro: they all required me to install additional packages to get
> something different from default fonts, which have very ugly cyrullic chars
> or don't support them at all.
>
> What I am trying basically to say, is that users should be getting
> reasonable set of fonts, with proper support of their local chars right
> after installing xfree and not have to search in portage to get at least
> some fonts with their local glyphs.

As seemant said somewhere, the new xfree ebuild will have the separated font 
ebuilds in PDEPEND. They'll still be installed, at least by default, they'll 
just live in separate packages which makes sense for people who don't want 
them.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://cvs.gentoo.org/~danarmak/danarmak-gpg-public.key

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Fonts, Xfree, Linux

[George Shapovalov]

Yes, this is a good idea in general.
On to the particulars:

On Friday 30 May 2003 02:30, Seemant Kulleen wrote:
> Now, here's the question.  Gentoo policy dictates that we do not touch
> files in /etc.  During emerge, this is fine, we can provide a file to be
> etc-update'd.  The concern is during emerge unmerge, when a font path is to
> be removed.

I am not sure I understand the issue: the fontpaths are akin to variable 
settings - one line corresponding to installed fontdir. Why can't we do 
something similar to what we do with /etc/env.d?
For example have /usr/share/fonts/paths.d directory (or may be 
/etc/fontpaths.d may be more appropriate) and have every font pacjage install 
a file containing the corresponding path.. The utility would scan this dir 
(called from pkg_postinst or somehow automatically otherwise) and update both 
official config files. Users should not need to mess with these one-liners, 
so they will get deleted upon unmerge... 

On Friday 30 May 2003 06:31, Spider wrote:
> What will such a tool do about ordering of paths?  There is a sticky
> issue here when two paths provide the same fonts, something that is
> completely legal. Now, anyone who has customized their X to some extent
This is more complicated and totally depends on whether there is certain 
common way to order them or should this be left totally to user.

In the former case it is easy to put numbers at the beginning of fontpath 
files, how it is done with env-vars anyway..

In the latter case users can just rename these files giving them different 
number so thay they would get appropriately ordered. The files will be kept 
intact and only the fonts not specifically ordered will get automatic 
handling.. 
In this case users will apparently need to keep track of what they are doing, 
but this stands true for any site-specific modification.
May be there is a better way to address this problem still..

George




--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Fonts, Xfree, Linux

[Matthew Kennedy]

Seemant Kulleen <seemant@gentoo.org> writes:

> Hi All,
>

> The idea is that this will be a centralised location for system fonts.
> All user custom fonts would go into /usr/share/fonts (or perhaps
> /usr/local/share/fonts -- not sure on that one, and not sure how much
> complexity it would add).
>
> Anyway, RedHat developed a tool called chkfontpath which updates

You might also want to check out Debian's tool called Deforma as it
solves this problem as well.

Matt

-- 
Matthew Kennedy
Gentoo Linux Developer

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Fonts, Xfree, Linux

[C. Brewer]

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

On Sat, 31 May 2003 13:04:02 -0500
Matthew Kennedy <mkennedy@gentoo.org> wrote:

> You might also want to check out Debian's tool called Deforma as it
> solves this problem as well.
> 
> Matt
> 
> -- 
> Matthew Kennedy
> Gentoo Linux Developer
> 
> --
> gentoo-dev@gentoo.org mailing list
> 
It's not very user friendly though:(

-- 
Chuck Brewer
Gentoo Linux Developer                    http://www.gentoo.org

GPG key:  http://pgp.mit.edu:11371/pks/lookup?search=0xBB12D4CB
GPG FP :  893B 4DA0 2763 12CF 4891  E6AC 9085 E8F6 BB12 D4CB


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]