Bug 238596 - anaconda text install screen has font issues with Mac OS 10.4
Summary: anaconda text install screen has font issues with Mac OS 10.4
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: anaconda
Version: 4.4
Hardware: s390x
OS: Linux
medium
low
Target Milestone: ---
: ---
Assignee: Anaconda Maintenance Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-05-01 18:26 UTC by Chris Snook
Modified: 2007-11-17 01:14 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-05-02 21:38:12 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
screenshot of corrupted display in Mac OS terminal (31.99 KB, image/png)
2007-05-01 18:27 UTC, Chris Snook
no flags Details
less severe font mangling on Apple X11 xterm (29.29 KB, image/png)
2007-05-01 18:28 UTC, Chris Snook
no flags Details

Description Chris Snook 2007-05-01 18:26:19 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11

Description of problem:
The ASCII line drawing characters used in Anaconda text mode do not draw properly on Mac OS X.  In the Mac OS terminal, the horizontal line characters are roughly twice as long as they should be, causing line wraps on a standard 80x24 terminal, and less serious but annoying disruption on a full-screen terminal.  This seems to impact all fonts and font sizes available in Terminal, though not all fonts have been exhaustively tested.  All preset $TERM values offered by Mac OS terminal have been tested, and make no difference.

In the xterm included with Apple's X11 package, the characters do not show up as line drawing characters, but aside from occasional spurious characters that throw off the width by one character, the spacing is mostly correct.

Version-Release number of selected component (if applicable):
RHEL 4 U4

How reproducible:
Always


Steps to Reproduce:
1. Launch an s390x installation from the 3270 console
2. ssh into anaconda from Mac OS X

Actual Results:
Mac OS terminal: line wraps severely mangle the screen, but installation is still feasible, maximizing the terminal before sshing in reduces the impact

Apple X11 xterm: line drawing characters show up as accented letters and various other non-line-drawing characters, and a few spurious characters show up, but spacing is correct in most places.

Expected Results:
Ideally, the line drawing characters should show up correctly.  Simply getting the spacing right, regardless of the characters, would be a substantial improvement.

Additional info:
I've seen some ncurses-based applications with an option to use ASCII line-drawing characters, mostly +, -, and |.  If it's feasible to add an "ascii" boot parameter that switches to this, it would be easy to get proper text GUI appearance regardless of client font configuration and terminal emulation.

Comment 1 Chris Snook 2007-05-01 18:27:44 UTC
Created attachment 153879 [details]
screenshot of corrupted display in Mac OS terminal

Comment 2 Chris Snook 2007-05-01 18:28:34 UTC
Created attachment 153880 [details]
less severe font mangling on Apple X11 xterm

Comment 3 Jeremy Katz 2007-05-02 21:38:12 UTC
Congratulations; the apple terminal program is busted.  There's not really much
we can do to fix it since it's closed source :)

Comment 4 Chris Snook 2007-05-07 21:16:54 UTC
Agreed, this is Apple's bug.  In fact, this is two completely different Apple
bugs, one for Terminal.app and one for X11.  My point is that no matter how
broken various terminal emulators may be with the extended line drawing
characters, they all work just fine with the ASCII box drawing characters
(+,-,|).  Offering an option to use ASCII-only line drawing would fix this
problem on just about any semi-broken terminal emulator.  I've seen other curses
apps offer such options, so I suspect it wouldn't be extremely difficult to
implement.

If we can easily implement an 'ascii' parameter that uses safe line-drawing
characters, we should, even if it's to work around other people's bugs.

Comment 5 Jeremy Katz 2007-05-07 21:29:26 UTC
Set your term to vt100-nav and you'll get vt100 emulation with No Advanced Video
(which includes the line drawing chars).

We just follow the capabilities the terminal says that it offers.  And all of
that is done at layers way below anaconda, so "options" can't really fix it.  


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