Bug 71642 - "Fixed" family of finely-crafted bitmap fonts would be appreciated.
"Fixed" family of finely-crafted bitmap fonts would be appreciated.
Status: CLOSED DUPLICATE of bug 68354
Product: Red Hat Public Beta
Classification: Retired
Component: bitmap-fonts (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Owen Taylor
Depends On:
  Show dependency treegraph
Reported: 2002-08-15 22:00 EDT by Michael K. Johnson
Modified: 2008-05-01 11:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-08-16 12:25:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michael K. Johnson 2002-08-15 22:00:20 EDT
A lot of us old farts are really used to (ok, addicted, whatever you want
to call it) to the hand-crafted "fixed" family of fonts.  We're used to
calling them "9x15", "10x20", etc, but we are trainable and can get used
to calling them "Fixed" and selecting a size in the new font selector...

We would either like for the fixed family of fonts to be made available
as part of the bitmap-fonts package or for a new package (doesn't even
have to be installed by default called "fixed-fonts" or something to be
made available that puts the fixed family where Xft can find it.

Comment 1 Michael K. Johnson 2002-08-15 22:14:21 EDT
Note that this could be done with symlinks, as long as Xft will read
gzipped fonts, in which case bitmap-fonts would gain a dependency.
(See bug #71641 for more on that.)

Or the symlinks could be added to the XFree86-base-fonts package.  I
don't know what the best way to do this would be.
Comment 2 Owen Taylor 2002-08-16 12:10:41 EDT
A separate package would definitely be easiest; I'd like to maintain
a separation between "all the crappy X fonts" and "fonts we think
people might want to actually use"

Adding misc-fixed to bitmap fonts is fairly non-trivial, because 
it involves taking the assorted bitmaps and turning them into a
set of coherent fonts... which one of 6x13, 7x13, 8x13 do you
use? Or do you presnet three familes "Terminal" "Terminal condensed"
"Terminal semicondensed" where condensed and semicondenseed are
only available at 13 point?

Not to mention problems with every font size having different 
character coverage.

Comment 3 Michael K. Johnson 2002-08-16 12:25:08 EDT
I'd be *completely* happy with a separate package.  Especially now
that I know that you can't use the gzipped format for Xft, as you
pointed out in bug #71641 -- so my symlink idea goes right out the

I would think that the fonts with commonly used nicknames would be
the ones.  The set I would suggest, as a single fixed family, would
be only the misc-fixed, not sony-fixed, and of those, 5x7, 6x9, 6x13
(which is also "fixed", the old default and so widely used), 7x13,
8x13, 9x15, and 10x20.

That seems like a manageable number of fonts.  Does that selection
make sense to you?

In terms of every font size having different character coverage,
the point here is to merely maintain existing usage, not to extend
to new usage.  That's one of the reasons that I suggest that this
doesn't have to be installed by default, just available to old unix
hacks who can read release notes.  :-)
Comment 4 Owen Taylor 2002-08-16 12:48:07 EDT
Well, the problem wasn't the *number* of fonts (adding 4x6 or whatever
wouldn't hurt), but the existance of 6x13, 7x13, and 8x13, which 
are all 13 point fonts.  If we went with 6x13 for it's status
as 'fixed', it doesn't really match the the surrounding 6x9, 8x15 
at all in aspect ratio...

(Garr, meant to dup this one, will add a comment to bug 68534 pointing
to discussion here)

*** This bug has been marked as a duplicate of 68354 ***
Comment 5 Michael K. Johnson 2002-08-16 12:59:36 EDT
I guess you skip 7x13 and 8x13 because 6x13 is the standard "fixed" font
that people are used to, and so that's one of the most important.

Note You need to log in before you can comment on or make changes to this bug.