this definition. Any tool which makes such fonts available to the X
Window System, however, must abide by this font policy.
This was all written before TrueType fonts were widely used for X and
didn't anticipate them, but in context the intention of this section is to
only apply to the
ootnote:
For the purposes of Debian Policy, a "font for the X Window System" is
one which is accessed via X protocol requests. Fonts for the Linux
console, for PostScript renderer, or any other purpose, do not fit
this definition. Any tool which makes such fonts available
On Sat, Jul 19, 2008 at 5:16 PM, Adam D. Barratt
<[EMAIL PROTECTED]> wrote:
> On Sat, 2008-07-19 at 16:58 -0700, Paul Hardy wrote:
>> I have been getting ready to release a font plus sources and auxiliary
>> programs for Debian. The Policy Manual requires using the
>> update-fonts-dir script when
On Sat, 2008-07-19 at 16:58 -0700, Paul Hardy wrote:
> I have been getting ready to release a font plus sources and auxiliary
> programs for Debian. The Policy Manual requires using the
> update-fonts-dir script when installing a font.
>
> I was going to post a change to the update-fonts-dir scri
I have been getting ready to release a font plus sources and auxiliary
programs for Debian. The Policy Manual requires using the
update-fonts-dir script when installing a font.
I was going to post a change to the update-fonts-dir script (so it
wouldn't complain that /usr/lib/X11/fonts doesn't exi
25 Mar 2001 03:08:30 -0500
From: Branden Robinson <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [PROPOSED] changes to X font policy
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signat
On 27-Mar-01, 23:57 (CST), Anthony Towns wrote:
> On Mon, Mar 26, 2001 at 09:35:36AM -0600, Steve Greenland wrote:
> > Encouraging I could agree with, particularly when the check could be
> > automated against the Packages file. But even an automated check against
> > the maintainer scripts is no
On Mon, Mar 26, 2001 at 09:35:36AM -0600, Steve Greenland wrote:
> On 25-Mar-01, 04:26 (CST), Anthony Towns wrote:
> > If you create a "must" directive, then you've just created a reason to
> > have a number of extra RC bugs. Indeed, that's the only point of making
> > it a "must" instead of a "s
On 25-Mar-01, 04:26 (CST), Anthony Towns wrote:
> If you create a "must" directive, then you've just created a reason to
> have a number of extra RC bugs. Indeed, that's the only point of making
> it a "must" instead of a "should".
The point of making a "must" requirement is that the consequence
On Sun, Mar 25, 2001 at 09:39:56PM +1000, Jason Parker wrote:
> Seth Arnold <[EMAIL PROTECTED]> writes:
> > * Anthony Towns [010325 02:30]:
> > > There's 6720 packages in sid/i386 at the moment, btw, not 8458.
> > Thanks for the correction. At ten seconds per package, this is still
> > nearly nine
Seth Arnold <[EMAIL PROTECTED]> writes:
> * Anthony Towns [010325 02:30]:
> > There's 6720 packages in sid/i386 at the moment, btw, not 8458.
> Thanks for the correction. At ten seconds per package, this is still
> nearly nineteen hours though.
Luckily we have these marvellous contraptions calle
* Anthony Towns [010325 02:30]:
> If you're not going to bother filing the RC bugs, there's no reason
> not to leave it as a "should". If you are going to file the RC bugs,
> then someone's got to figure out which packages it applies to at some
> point anyway.
This makes sense if one assumes that
On Sun, Mar 25, 2001 at 04:44:37AM -0500, Branden Robinson wrote:
> > > Why would dosemu need to be removed from the distribution?
> > Because that's what violating a "must" directive *means*. It's the sole
> > difference between "should" and "must": either's a bug, but if it's a
> > "must" the pac
On Sun, Mar 25, 2001 at 01:46:59AM -0800, Seth Arnold wrote:
> * Anthony Towns [010325 01:11]:
> > BTW, I'm inclined to think it'd be a good idea for people who want to add
> > a "must" requirement (or to change a should to a must) to include a list of
> > packages that would need to be removed fr
On Sun, Mar 25, 2001 at 07:21:29PM +1000, Anthony Towns wrote:
> On Sun, Mar 25, 2001 at 04:18:55AM -0500, Branden Robinson wrote:
> > On Sun, Mar 25, 2001 at 07:04:53PM +1000, Anthony Towns wrote:
> > > Certainly, having split packages would make it *easier* to cope with this,
> > > and that's a g
* Anthony Towns [010325 01:11]:
> BTW, I'm inclined to think it'd be a good idea for people who want to add
> a "must" requirement (or to change a should to a must) to include a list of
> packages that would need to be removed from the distribution due to the
> change. Anyone agree/disagree?
Whil
On Sun, Mar 25, 2001 at 04:18:55AM -0500, Branden Robinson wrote:
> On Sun, Mar 25, 2001 at 07:04:53PM +1000, Anthony Towns wrote:
> > Certainly, having split packages would make it *easier* to cope with this,
> > and that's a good reason to make it policy, but it's not enough of a reason
> > to re
On Sun, Mar 25, 2001 at 07:04:53PM +1000, Anthony Towns wrote:
> Certainly, having split packages would make it *easier* to cope with this,
> and that's a good reason to make it policy, but it's not enough of a reason
> to remove dosemu from the distribution. IMO.
Why would dosemu need to be remov
On Sun, Mar 25, 2001 at 07:07:40PM +1000, Anthony Towns wrote:
> On Sun, Mar 25, 2001 at 03:08:30AM -0500, Branden Robinson wrote:
> > * Some rewording to reflect the new must/should/may policy.
>
> BTW, I'm inclined to think it'd be a good idea for people who want to add
> a "must" requirement (o
On Sun, Mar 25, 2001 at 03:57:37AM -0500, Branden Robinson wrote:
> On Sun, Mar 25, 2001 at 06:29:47PM +1000, Anthony Towns wrote:
> > On Sun, Mar 25, 2001 at 03:08:30AM -0500, Branden Robinson wrote:
> > > * Some rewording to reflect the new must/should/may policy.
> > This seems like a good idea,
On Sun, Mar 25, 2001 at 03:08:30AM -0500, Branden Robinson wrote:
> * Some rewording to reflect the new must/should/may policy.
BTW, I'm inclined to think it'd be a good idea for people who want to add
a "must" requirement (or to change a should to a must) to include a list of
packages that would
On Sun, Mar 25, 2001 at 06:29:47PM +1000, Anthony Towns wrote:
> On Sun, Mar 25, 2001 at 03:08:30AM -0500, Branden Robinson wrote:
> > * Some rewording to reflect the new must/should/may policy.
>
> > - Fonts of any type supported by the X Window System
> > - should be be in a
On Sun, Mar 25, 2001 at 03:08:30AM -0500, Branden Robinson wrote:
> * Some rewording to reflect the new must/should/may policy.
> - Fonts of any type supported by the X Window System
> - should be be in a separate binary package from any
> - executables, librari
er scripts in X fonts packages need to run are provided by Debian
(in the xutils package) and thus future changes in font policy can be
directly administrated via these scripts. This should make life easier
for people packaging X fonts; the X package maintainer can insulate them
from chan
Le 08 Oct 1997 12:16:56 -0400 , Mark Eichin a écrit:
«If xfntil2 is the *only* font package not built out of the xfree
«release, that would probably be a reasonable approach too. Otherwise
No, there is also xtel.
«we should probably come up with a font list config file (or just use
«the one
Woohoo! It worked! finally! Thank you =)
On 10 Oct 1997, Mark Eichin wrote:
> > So how DO I get the fonts in xfnt100 to be recognized?
>
> your /etc/X11/XF86Config should have
>
> Section "Files"
>RgbPath"/usr/X11R6/lib/X11/rgb"
>FontPath
> "/usr/X11R6/lib/X11/fonts/misc/,/usr
> And of coure, we have the TrueType and Postscript fonts, each of which
> has their own font servers. (I think)
I have no reason to believe that...
> So how DO I get the fonts in xfnt100 to be recognized?
your /etc/X11/XF86Config should have
Section "Files"
RgbPath"/usr/X11R6/lib/X11/r
And of coure, we have the TrueType and Postscript fonts, each of which
has their own font servers. (I think)
So how DO I get the fonts in xfnt100 to be recognized?
On 10 Oct 1997, Mark Eichin wrote:
> :-) The trick is that xset isn't a general solution, though it's fine
> for one user. (Not g
:-) The trick is that xset isn't a general solution, though it's fine
for one user. (Not good enough for xnest, or xfs, for example.)
Until I read some of the points on this thread, I also thought that
just stuffing them in directories was enough...
Hi,
>>"Manong" == Manong Dibos <[EMAIL PROTECTED]> writes:
Manong> Its odd that Manoj hasnt contributed to this thread, seeing as
Manong> how he is usually one of the first to move that something be
Manong> taken to the debian-policy list, and he also seems to be the
Manong> person most concerned
Its odd that Manoj hasnt contributed to this thread, seeing as how he is
usually one of the first to move that something be taken to the
debian-policy list, and he also seems to be the person most concerned with
debian policy in general =]
Cheers,
Jonathan Walther
On 9 Oct 1997, Mark Eichin wro
Ok, at this point I'm convinced that there's a need for tools to
manipulate font path related stuff. I'll see what I can come up with.
(I'd forgotten about the emacs20 font pack, that's a good one too.) I
still haven't found out what the actual xfs config problem is (when I
developed the gzip-fon
..)
>
> Yes, I prefer something like `xfonts-path { --add | --remove }' tool, which
> would edit appropriate config files and restart appropriate daemons.
But it should IMHO be able to handle `xfs' configuration as well. See
issues in my previous mail in debian-devel ("problem
> "ME" == Mark Eichin <[EMAIL PROTECTED]> writes:
ME: In that case, do exactly what xfnt100 and the like do, as far as
ME: rerunning mkfontdir. If you want to avoid dealing with getting the X
ME: server to find the fonts (as for a game with only a few of them) I'd
ME: recommen
Mark Eichin <[EMAIL PROTECTED]> writes:
> If xfntil2 is the *only* font package not built out of the xfree
> release, that would probably be a reasonable approach too. Otherwise
> we should probably come up with a font list config file (or just use
> the one in XF86Config, but only if I write a to
> No, my package `xfntil2' deals with X fonts (it's X fonts package :-).
In that case, do exactly what xfnt100 and the like do, as far as
rerunning mkfontdir. If you want to avoid dealing with getting the X
server to find the fonts (as for a game with only a few of them) I'd
recommend "cheating
>>>>> "ME" == Mark Eichin <[EMAIL PROTECTED]> writes:
ME: umm, there doesn't need to be font "policy" -- X deals with X fonts,
ME: nothing else does, that's all there is to it, right?
No, my package `xfntil2' deals with X fonts (it&
On Tue, 7 Oct 1997, Joey Hess wrote:
> Manong Dibos wrote:
> > How many different font servers do we have to contend with that would make
> > it so we "need" a menu like scheme? (good work Joey Hess).
>
> Thanks, but I really have little to do with it. It's all Joost's work. :-)
Ok, good work J
Manong Dibos wrote:
> How many different font servers do we have to contend with that would make
> it so we "need" a menu like scheme? (good work Joey Hess).
Thanks, but I really have little to do with it. It's all Joost's work. :-)
--
see shy jo
umm, there doesn't need to be font "policy" -- X deals with X fonts,
nothing else does, that's all there is to it, right?
As for xfs not recognizing fonts in xfnt100 -- if you've spent enough
time with the documentation to figure out that it's really not your
fault
Ok, re the posts on debian-devel list, what IS the current policy on
fonts?
How many different font servers do we have to contend with that would make
it so we "need" a menu like scheme? (good work Joey Hess).
Also, even if it isnt made policy to automate it, how DO I make it so the
standard fon
41 matches
Mail list logo
