Re: font policy changes

[Russ Allbery]

[EMAIL PROTECTED] writes:

> 3) Even if "mkfontdir" were invoked directly or if it's okay to give
> "update-fonts-dir" an absolute path (in which case its man page needs to
> be updated and the warning removed), isn't it also advisable to run
> "xset fp rehash" in postinst and postrm scripts?  That program is the
> standard mechanism for updating installed fonts on recent versions of
> X11, including in Debian and other GNU/Linux distributions.

Hm.  That's an interesting thought, although it's going to fail if no X
server is currently running, correct?

> 5) If I wanted to have symbolic links checked with dh_link, what is the
> preferred way to enter an absolute path to your current location in the
> file?  Should I "just know" that the path will be
> "/usr/share//", or will putting "$(CURDIR)/file.extension"
> work in the debian/.links file, or is there some other
> preferred method?

You should provide the full path of the target file to dh_link.  dh_link
will then do whatever is necessary to make it a Policy-compliant link.  So
if you're linking to a file in /usr/share/, the source should
start with that.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: font policy changes

[unifoundry]

>  Original Message 
> Subject: Re: font policy changes
> From: Russ Allbery <[EMAIL PROTECTED]>
> Date: Sun, July 13, 2008 10:13 pm
> To: [EMAIL PROTECTED]
> Cc: debian-devel@lists.debian.org, [EMAIL PROTECTED], 
> "Anthony Fok" <[EMAIL PROTECTED]>
>
> [EMAIL PROTECTED] writes:
>
> > 3) Even if "mkfontdir" were invoked directly or if it's okay to give
> > "update-fonts-dir" an absolute path (in which case its man page needs to
> > be updated and the warning removed), isn't it also advisable to run
> > "xset fp rehash" in postinst and postrm scripts? That program is the
> > standard mechanism for updating installed fonts on recent versions of
> > X11, including in Debian and other GNU/Linux distributions.
>
> Hm. That's an interesting thought, although it's going to fail if no X
> server is currently running, correct?
>
> -- 
> Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>

True.  I guess that would have to be trapped gracefully.

Would running "fc-cache -f" be preferable?  It will identify bitmap and
TrueType fonts.  There are two things I don't like about that command
though: 1) it has no man page (I guess I can write one) although
"fc-cache --help" lists options; 2) I don't think it dies gracefully --
it can corrupt a cache if there is an error, and doesn't unwind to the
old cache version (unless the program has been improved recently).  Is
that tolerable?


Paul Hardy
[EMAIL PROTECTED]



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: font policy changes

[Julien Cristau]

On Sun, Jul 13, 2008 at 22:13:27 -0700, Russ Allbery wrote:

> [EMAIL PROTECTED] writes:
> 
> > 3) Even if "mkfontdir" were invoked directly or if it's okay to give
> > "update-fonts-dir" an absolute path (in which case its man page needs to
> > be updated and the warning removed), isn't it also advisable to run
> > "xset fp rehash" in postinst and postrm scripts?  That program is the
> > standard mechanism for updating installed fonts on recent versions of
> > X11, including in Debian and other GNU/Linux distributions.
> 
> Hm.  That's an interesting thought, although it's going to fail if no X
> server is currently running, correct?
> 
It will always fail, because the user running the script (root) won't
normally have access to the X server.

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: font policy changes

[unifoundry]

>  Original Message 
> Subject: Re: font policy changes
> From: Julien Cristau <[EMAIL PROTECTED]>
> Date: Mon, July 14, 2008 2:26 am
> To: Russ Allbery <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED],
> debian-devel@lists.debian.org,[EMAIL PROTECTED], Anthony
> Fok <[EMAIL PROTECTED]>
> 
> On Sun, Jul 13, 2008 at 22:13:27 -0700, Russ Allbery wrote:
> 
> > [EMAIL PROTECTED] writes:
> > 
> > > 3) Even if "mkfontdir" were invoked directly or if it's okay to give
> > > "update-fonts-dir" an absolute path (in which case its man page needs to
> > > be updated and the warning removed), isn't it also advisable to run
> > > "xset fp rehash" in postinst and postrm scripts? That program is the
> > > standard mechanism for updating installed fonts on recent versions of
> > > X11, including in Debian and other GNU/Linux distributions.
> > 
> > Hm. That's an interesting thought, although it's going to fail if no X
> > server is currently running, correct?
> > 
> It will always fail, because the user running the script (root) won't
> normally have access to the X server.
>
> Cheers,
> Julien

It would only fail if you did not have an X server running, for example
if root were running in single-user mode.  But if an ordinary user logs
in using an X server in multi-user mode and does an "su" to root to run
apt-get, or of course if root logs in and runs X11, it works.  This
package isn't part of any default Debian installation, so I think a user
would most often be running apt-get inside an X11 environment.

"fc-cache -f" will run without an X server running.  Maybe that is the
best choice.


Paul Hardy
[EMAIL PROTECTED]



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: font policy changes

[Russ Allbery]

Julien Cristau <[EMAIL PROTECTED]> writes:
> On Sun, Jul 13, 2008 at 22:13:27 -0700, Russ Allbery wrote:
>> [EMAIL PROTECTED] writes:

>>> 3) Even if "mkfontdir" were invoked directly or if it's okay to give
>>> "update-fonts-dir" an absolute path (in which case its man page needs to
>>> be updated and the warning removed), isn't it also advisable to run
>>> "xset fp rehash" in postinst and postrm scripts?  That program is the
>>> standard mechanism for updating installed fonts on recent versions of
>>> X11, including in Debian and other GNU/Linux distributions.

>> Hm.  That's an interesting thought, although it's going to fail if no X
>> server is currently running, correct?

> It will always fail, because the user running the script (root) won't
> normally have access to the X server.

See, I thought that too, and then I tried it and it seemed to work fine.
Maybe my test was wrong?

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: font policy changes

[Vincent Bernat]

OoO Lors  de la soirée naissante  du lundi 14 juillet  2008, vers 17:50,
Russ Allbery <[EMAIL PROTECTED]> disait :

>> It will always fail, because the user running the script (root) won't
>> normally have access to the X server.

> See, I thought that too, and then I tried it and it seemed to work fine.
> Maybe my test was wrong?

If HOME  was set to ~user,  root can find ~user/.Xauthority  and is then
able  to  use  the  xserver.  Same applies  if  XAUTHORITY  variable  is
correctly set.
-- 
 /* After several hours of tedious analysis, the following hash
  * function won.  Do not mess with it... -DaveM
  */
2.2.16 /usr/src/linux/fs/buffer.c


pgppapzmNqMQa.pgp
Description: PGP signature

Re: font policy changes

[Julien Cristau]

On Mon, Jul 14, 2008 at 08:50:57 -0700, Russ Allbery wrote:

> Julien Cristau <[EMAIL PROTECTED]> writes:
> > It will always fail, because the user running the script (root) won't
> > normally have access to the X server.
> 
> See, I thought that too, and then I tried it and it seemed to work fine.
> Maybe my test was wrong?
> 
Maybe HOME was still set to the user's home dir?  If XAUTHORITY isn't
set Xlib looks in $HOME/.Xauthority, so that may work depending how you
get root.

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: font policy changes

[Russ Allbery]

Julien Cristau <[EMAIL PROTECTED]> writes:

> Maybe HOME was still set to the user's home dir?  If XAUTHORITY isn't
> set Xlib looks in $HOME/.Xauthority, so that may work depending how you
> get root.

Ah, XAUTHORITY was set.  Thank you.  I didn't know about that.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: font policy changes

[Josselin Mouette]

Le dimanche 13 juillet 2008 à 21:16 -0700, [EMAIL PROTECTED] a
écrit :
> 4) What are the preferred steps for registering a TrueType font in
> Debian?  It is outside the X11 directory structure, and depends on the
> TrueType font server.  GNOME recognizes a newly installed TrueType font
> but is there anything that should appear in a postinst or postrm script?

The font caches should be automatically updated as soon as you are
registering fonts with defoma. If you are not using defoma, you need to
run fc-cache by hand in the postinst.

Cheers,
-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

RE: font policy changes

[unifoundry]

>  Original Message 
> Subject: Re: font policy changes
> From: Josselin Mouette <[EMAIL PROTECTED]>
> Date: Wed, July 16, 2008 4:20 am
> To: [EMAIL PROTECTED]
> Cc: debian-devel@lists.debian.org, [EMAIL PROTECTED]
> 
> The font caches should be automatically updated as soon as you are
> registering fonts with defoma. If you are not using defoma, you need to
> run fc-cache by hand in the postinst.
> 
> Cheers,

Thank you.  I can write a proposed addition to the Policy Manual for
TrueType fonts after I'm done with the current package unless someone
else wants to do it.  The "update-fonts-dir" utility currently only
handles fonts in the X11 tree (not TrueType), and even then the new X11
font directory options to look under /usr/share/fonts/X11/ ("-7" and
"--x11r7-layout") don't work on my stable release (Etch 4.0r3).


Paul Hardy
[EMAIL PROTECTED]



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: font policy changes

[Julien Cristau]

On Wed, Jul 16, 2008 at 08:37:12 -0700, [EMAIL PROTECTED] wrote:

> Thank you.  I can write a proposed addition to the Policy Manual for
> TrueType fonts after I'm done with the current package unless someone
> else wants to do it.  The "update-fonts-dir" utility currently only
> handles fonts in the X11 tree (not TrueType), and even then the new X11
> font directory options to look under /usr/share/fonts/X11/ ("-7" and
> "--x11r7-layout") don't work on my stable release (Etch 4.0r3).
> 
These options are no-ops.  What do you mean by "don't work"?
Also please stop breaking the thread.

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: font policy changes

[unifoundry]

>  Original Message 
> Subject: Re: font policy changes
> From: Julien Cristau <[EMAIL PROTECTED]>
> Date: Wed, July 16, 2008 8:47 am
> To: [EMAIL PROTECTED]
> Cc: debian-devel@lists.debian.org, [EMAIL PROTECTED]
> 
> On Wed, Jul 16, 2008 at 08:37:12 -0700, [EMAIL PROTECTED] wrote:
> 
> > Thank you. I can write a proposed addition to the Policy Manual for
> > TrueType fonts after I'm done with the current package unless someone
> > else wants to do it. The "update-fonts-dir" utility currently only
> > handles fonts in the X11 tree (not TrueType), and even then the new X11
> > font directory options to look under /usr/share/fonts/X11/ ("-7" and
> > "--x11r7-layout") don't work on my stable release (Etch 4.0r3).
> > 
> These options are no-ops. What do you mean by "don't work"?
> Also please stop breaking the thread.
> 
> Cheers,
> Julien
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

What I meant by "don't work" is that, as you mention, these two options
are no-ops.

According to the update-fonts-dir(1) man page, these options should not
be no-ops:
===
update-fonts-dir creates a fonts.dir file in an X font directory by
invoking mkfontdir(1x) with the appropriate argumentsFor each
directory, which is simply the last component of its path (such as
'75dpi' or 'misc'), update-fonts-dir will generate either
/usr/lib/X11/fonts/directory/fonts.dir or
/usr/share/fonts/X11/directory/fonts.dir from the fonts.scale and font
files found within it.

-7, --x11r7-layout switches the font layout to the one introduced in
X11R7: fonts in /usr/share/fonts/X11/directory (default is: fonts in
/usr/lib/X11/fonts/directory)
===

Here are examples of what happens in practice on Etch (4.0r3, i386 DVD
install), showing where the man page says the program should look versus
what actually happens.

Invocation:  update-fonts-dir misc
Documented Path: /usr/lib/X11/fonts/misc
Actual Path: /usr/lib/X11/fonts/misc
Status:  works as advertised (and complains that
/usr/lib/X11/fonts/misc doesn't exist)

Invocation:  update-fonts-dir -7 misc
Documented Path: /usr/share/fonts/X11/misc
Actual Path: /usr/lib/X11/fonts/misc
Status:  looks in wrong directory; "-7" has no effect

Invocation:  update-fonts-dir --x11r7-layout misc
Documented Path: /usr/share/fonts/X11/misc
Actual Path: /usr/lib/X11/fonts/misc
Status:  looks in wrong directory; "--x11r7-layout" has no
effect

Invocation:  update-fonts-dir /usr/share/fonts/X11/misc
Documented Path: /usr/share/fonts/X11/misc
Actual Path: /usr/share/fonts/X11/misc
Status:  "warning: absolute path /usr/share/fonts/X11/misc was
provided"

===

With the current stable release, use of /usr/lib/X11/fonts is
deprecated.  This gives a few options:

a) Leave "-7" and "--x11r7-layout" as no-ops, but change the default
font top directory from "/usr/lib/X11/fonts" to "/usr/share/fonts/X11"
in the source code (so it never looks in "/usr/lib/X11/fonts" anymore).

b) Change "-7" and "--x11r7-layout" to work the way the man page says
they should work.

c) Change update-fonts-dir to accept an absolute font path without
complaint.

d) Change update-fonts-dir to look by default in both the old top-level
directory and the new one.

e) Phase out update-fonts-dir in favor of something else that also looks
in the truetype/ and other font directories outside the customary X11
font directories (for example, defoma or fc-cache).  Remove the mandated
use of update-fonts-dir from the Policy Manual (it doesn't handle
truetype fonts anyways).

f) Other suggestions?


Paul Hardy
[EMAIL PROTECTED]



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: font policy changes

[Julien Cristau]

On Thu, Jul 17, 2008 at 00:19:39 -0700, [EMAIL PROTECTED] wrote:

> What I meant by "don't work" is that, as you mention, these two options
> are no-ops.
> 
> According to the update-fonts-dir(1) man page, these options should not
> be no-ops:
> ===
> update-fonts-dir creates a fonts.dir file in an X font directory by
> invoking mkfontdir(1x) with the appropriate argumentsFor each
> directory, which is simply the last component of its path (such as
> '75dpi' or 'misc'), update-fonts-dir will generate either
> /usr/lib/X11/fonts/directory/fonts.dir or
> /usr/share/fonts/X11/directory/fonts.dir from the fonts.scale and font
> files found within it.
> 
> -7, --x11r7-layout switches the font layout to the one introduced in
> X11R7: fonts in /usr/share/fonts/X11/directory (default is: fonts in
> /usr/lib/X11/fonts/directory)
> ===
> 
The manpage is outdated.

> Here are examples of what happens in practice on Etch (4.0r3, i386 DVD
> install), showing where the man page says the program should look versus
> what actually happens.
> 
> Invocation:  update-fonts-dir misc
> Documented Path: /usr/lib/X11/fonts/misc
> Actual Path: /usr/lib/X11/fonts/misc
> Status:  works as advertised (and complains that
> /usr/lib/X11/fonts/misc doesn't exist)
> 
No.  It looks in both the old and the new paths.  Did you actually look
at the script?

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: font policy changes

[unifoundry]

>  Original Message 
> Subject: Re: font policy changes
> From: Julien Cristau <[EMAIL PROTECTED]>
> Date: Thu, July 17, 2008 1:38 am
> To: [EMAIL PROTECTED]
> Cc: debian-devel@lists.debian.org, [EMAIL PROTECTED]
> 
> On Thu, Jul 17, 2008 at 00:19:39 -0700, [EMAIL PROTECTED] wrote:
> 
> > What I meant by "don't work" is that, as you mention, these two options
> > are no-ops.
> > 
> > According to the update-fonts-dir(1) man page, these options should not
> > be no-ops:
> > ===
> > update-fonts-dir creates a fonts.dir file in an X font directory by
> > invoking mkfontdir(1x) with the appropriate argumentsFor each
> > directory, which is simply the last component of its path (such as
> > '75dpi' or 'misc'), update-fonts-dir will generate either
> > /usr/lib/X11/fonts/directory/fonts.dir or
> > /usr/share/fonts/X11/directory/fonts.dir from the fonts.scale and font
> > files found within it.
> > 
> > -7, --x11r7-layout switches the font layout to the one introduced in
> > X11R7: fonts in /usr/share/fonts/X11/directory (default is: fonts in
> > /usr/lib/X11/fonts/directory)
> > ===
> > 
> The manpage is outdated.

Okay, then as far as that problem goes, it is just that the man page
needs to be updated.

> 
> > Here are examples of what happens in practice on Etch (4.0r3, i386 DVD
> > install), showing where the man page says the program should look versus
> > what actually happens.
> > 
> > Invocation: update-fonts-dir misc
> > Documented Path: /usr/lib/X11/fonts/misc
> > Actual Path: /usr/lib/X11/fonts/misc
> > Status: works as advertised (and complains that
> > /usr/lib/X11/fonts/misc doesn't exist)
> > 
> No. It looks in both the old and the new paths. Did you actually look
> at the script?

I only looked at the script quickly, and saw that all it did was invoke
mkfontdir, and knew that wasn't enough to start using a font immediately
under X11.  That's why I posted my earlier messages about whether it was
okay to just call mkfontdir directly (given that update-fonts-dir wasn't
behaving the way the man page said it should), and also if installation
shouldn't then refresh the X11 font list with xset or fc-cache.

The consensus seems to be that it's okay to use fc-cache or defoma in a
postinst or postrm script, but that it's not okay to use xset, because
xset will fail if X11 isn't running.  It would be nice to add mention of
that in some way to the Policy Manual.

update-fonts-dir should probably no longer complain about
/usr/lib/X11/fonts not being found every time it is run, seeing as how
that directory no longer exists on Debian systems.

> 
> Cheers,
> Julien


Paul Hardy
[EMAIL PROTECTED]



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]