Bug 113899 - xclock -digital does not obey the -fn (font) switch
Summary: xclock -digital does not obey the -fn (font) switch
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 9
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-01-19 23:34 UTC by Robert M. Riches Jr.
Modified: 2007-04-18 17:01 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-09-01 12:02:46 UTC
Embargoed:


Attachments (Terms of Use)

Description Robert M. Riches Jr. 2004-01-19 23:34:40 UTC
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:
100%

Steps to Reproduce:
1. xclock -digital -fn 6x10
2. xclock -digital -fn 12x24
3.
  
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-20 02:40:09 UTC
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-20 02:45:23 UTC
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-20 04:38:46 UTC
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?

Thanks.


Comment 4 Robert M. Riches Jr. 2004-01-22 03:02:39 UTC
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 07:21:05 UTC
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.