Bug 113899 - xclock -digital does not obey the -fn (font) switch
xclock -digital does not obey the -fn (font) switch
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
: MoveUpstream
Depends On:
  Show dependency treegraph
Reported: 2004-01-19 18:34 EST by Robert M. Riches Jr.
Modified: 2007-04-18 13:01 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-01 08:02:46 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 Robert M. Riches Jr. 2004-01-19 18:34:40 EST
Description of problem:
With the -digital option, xclock does not obey
the -fn (font) switch.

Version-Release number of selected component (if applicable):
XFree86-tools-4.3.0-2.90.43 (XFree86 was the closest thing
in the bugzilla list.)

How reproducible:

Steps to Reproduce:
1. xclock -digital -fn 6x10
2. xclock -digital -fn 12x24
Actual results:
The two commands display the identical font.

Expected results:
Each command should display the specified font.

Additional info:
xterm obeys the -fn switch just fine.
Comment 1 Mike A. Harris 2004-01-19 21:40:09 EST
Not sure if this is a bug, or due to xclock now using Xft/fontconfig
for it's font rendering.   It's of a trivial enough nature however,
that it should be reported instead to XFree86.org directly via their
own bugzilla, located at:  http://bugs.xfree86.org

Once you've reported it there, please paste a URL here to the upstream
bug report, and I will track it upstream.
Comment 2 Mike A. Harris 2004-01-19 21:45:23 EST
Since I have the repo tree locally, I did a quick cvs rdiff of
xclock, and found manpage updates which indicate that -fn is not
valid when using -digital.  Here is the snippet:

+.B \-face \fIpattern\fP
+This option specifies the font to use in digital mode when the
+Xrender extension is used.

So, when using -digital, you must use the -face option instead
due to it using Render support.

Comment 3 Robert M. Riches Jr. 2004-01-19 23:38:46 EST
Curious inconsistency in the switches.  The RHL 9 man page
does not describe -fn or -face.  The "-h" usage message
shows both.  I tried -face with '6x10' and '12x24' as
arguments, but it did not appear to have any effect.  As I
don't have ready access to documentation on how the -face
switch is used, I tried a few things.  Using 'courier-<n>'
appears to work.  It looks like the man pages and usage
messages need to be brought in sync with the code.

I'll make an attempt to report this to bugs.xfree86.org.

On a related note, I can't seem to get the -hd option in
analog to work.  Do you have a reference to what options
have replaced the old options for analog color settings?

Comment 4 Robert M. Riches Jr. 2004-01-21 22:02:39 EST
I searched XFree86's bugzilla and found #331 relating to
xclock -digital's font options and #437 relating to the
-analog hand color options.  I posted an addition asking
whether the man pages and usage message inconsistency
should be reported as a separate bug.  The bug reports
did say the -norender option would restore old functionality,
and it appears this does return the -fn and -hd options to
their old behavior.  I just added that option to my .Xclients,
so now I'm happy for now.  :-)
Comment 5 Mike A. Harris 2004-01-22 02:21:05 EST
The manpages we ship are the manpages that XFree86.org supplies.
Any inconsistancies and/or errors or ommisions are upstream
deficiencies rather than something we've added, and should thus
be reported and addressed upstream.  We do occasionally make
modifications to manpages and other documentation when the issue
involved is rather non-trivial or drastic, or is a problem reported
to us by a large number of users, of which a small doc update
may resolve.  We don't generally review the upstream manpages
for correctness and verify the operation of every commandline
switch and permutations of them for all included applications
however, as that would incur a massive amount of QA resources
dedicated to testing it all, and would not provide much bang for
the buck.  Generally speaking, we rely and expect upstream to
document what they supply more or less accurately and reflecting
the operation of the software.  Hopefully they do.  ;o)

Setting bug to UPSTREAM state, for later review of upstream
bug reports.

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