Bug 77626 - xclock ignores font specification?
xclock ignores font specification?
Product: Red Hat Raw Hide
Classification: Retired
Component: XFree86 (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2002-11-11 01:40 EST by Jonathan Kamens
Modified: 2007-04-18 12:48 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-11-12 02:13:48 EST
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 Jonathan Kamens 2002-11-11 01:40:24 EST
I just upgraded to XFree86-tools- and associated packages
with the same version number.  Now xclock appears to be ignoring all attempts to
set its font. Mind you, editres shows that the font resource on the clock widget
has been set, but no matter what I set it to xclock comes up in the same font
when run with -digital.  I don't know whether this problem is specific to xclock
or indicative of a larger problem (although I haven't yet noticed font problems
in any other X applications).
Comment 1 Mike A. Harris 2002-11-12 01:47:33 EST
I wasn't sure about wether or not this is a bug so I asked Keith...

<keithp> xclock now uses render by default.  Set the font with '-fa'.
<keithp> Or use -norender
<mharris> So that one isn't a bug then, just a change in behaviour?
<keithp> Yup.  Gotta move forward and stop using '-fn' :-)
<mharris> Ok, sounds good to me.  Thanks.
<keithp> NOTABUG

So this is a feature, and not a bug.  Closing NOTABUG.
Comment 2 Jonathan Kamens 2002-11-12 02:12:39 EST
There is still a bug here, although I admit that it's not clear exactly what the
bug is.  Some remaining issues:

* The xclock man page doesn't mention -face or the "face" X resource.
* Xterm defaults to old-style fonts and only does rendering if a face is
specified.  Why doesn't xclock behave the same way?
* Xterm provides the -fs command-line option and the faceSize X resource for
setting the freetype face size.  Xclock, on the other hand, appears to provide
no way whatsoever to set the face size.
* Is freetype rendering and faces in X applications documented anywhere?  I
certainly couldn't find it.  Note, for example, the documentation of common
options in X(7x).  If -face is going to be standard in the future, it needs to
be documented there.
Comment 3 Jonathan Kamens 2002-11-12 02:13:42 EST
Oh, and the usage message that you get when you do "xclock -help" doesn't
mention "-norender".
Comment 4 Mike A. Harris 2002-11-12 05:55:27 EST
All of the questions you have asked are quite interesting, however
I do not know the answers.  I am not going to simply be a middleman
in between yourself and XFree86.org for answering them.

Please ask these questions on xpert@xfree86.org or fonts@xfree86.org
user mailing lists.  Bugzilla is not a question forum or tech support

Also, don't reopen a closed bug report and add new data to it as a new
report.  If you've got a new bug to report, open a new bug report.

For each of the bulleted items in your last comment, either it is
a question for XFree86.org, or it is a issue that it is up to them
to determine if it is a bug or not, and if so, it is up to them to
fix it.

xclock is a trivial application, not worth wasting my time.  If it is
that problematic, it is _gone_.
Comment 5 Mike A. Harris 2002-11-12 06:03:07 EST
Also, missing things in manpages and stuff like that should be reported
to XFree86.org.  I've stated numerous times that extreme trivia should
be reported upstream.

As for freetype, I don't even care if freetype itself has any documentation
at all.  I am not a freetype developer, documentor, packager, I don't
maintain freetype, I don't use freetype in my own code, and I don't even
look at freetype's source code, or documentation.  The place to ask
freetype questions is some mailing list dangling off of www.freetype.org

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