[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OS X Terminal.app and Aptitude



Ian Brandt <ian@ianbrandt.com> wrote:

> Thomas Dickey wrote:
>>>   - Horizontal borders in Aptitude (e.g. in the search or quit
>>> dialogs) become '?' characters.
>> 
>> This is more interesting.  Those dashes look like they're double-width.  I have
>> a hunch that your locale on Debian is set to a UTF-8 flavor and that aptitude
>> is emitting line-drawing in UTF-8, but that Terminal isn't doing the Right
>> Thing with that.  A quick check with uxterm shows me that aptitude sends
>> _something_ in UTF-8.
>> 
>> I seem to recall reading that Terminal can handle UTF-8, so given that, one of
>> these possibilities comes to mind:
>> 
>> 	a) the OS X locale isn't UTF-8 (and Terminal gets confused)

> I checked my Terminal settings and the encoding is set to UTF-8.  I
> tried changing my Terminal font from Bitstream Vera Sans Mono to the
> included VT-100 and Courier fonts to see if it could be a bug in the
> font, but no change.

hmm - but the line-drawing characters were all double-width when drawn
with UTF-8.  tack doesn't know about UTF-8 (yet), and will send just the
strings that are in the terminfo.  ncurses is sending the UTF-8 strings
to work with terminals that require that.

I suspect that if you set your locale to en_US then the lines would be
drawn properly.  Terminal may simply be drawing the lines without using
a font (which is what xterm can do), since many fonts do not contain
line-drawing characters.

>> 	b) Terminal works for UTF-8 text, but not line-drawing (chooses
>> 	   an incorrect set of glyphs for mapping the line-drawing text).

> Is one of the terminfo settings related to how double byte characters
> are sent to the terminal?  Feeling my way around tack I found the
> alternate character set tests.  Sure enough when set to nsterm many of
> the characters are rendered as '?'.  Set to our running macosx copy of
> OS X's included /usr/share/terminfo/78/xterm-color I see that all the
> alternate characters are drawn correctly.

That's acsc, enacs, rmacs and smacs.

I didn't notice before, but nsterm's acsc string does look odd.
Several of the console emulators (Linux, FreeBSD for instance) have
mappings that use existing fonts to obtain line-drawing characters from
character codes that are always available in the 128-255 range.  Looks
like nsterm was designed for that.  vt100-style mapping uses the enacs,
smacs and rmacs strings to initialize and switch to/from an alternate
character set that's not always available by a direct mapping.

Anyway, nsterm's acsc string is odd since it doesn't seem to match
the other ones I'm familiar with.

> During that process I also noticed that blink worked when I was set to
> nsterm, so I've added 'enter_blink_mode=\E[5m' to macosx with success.

> I'm starting to get more familiar with tack, and I see that the
> solution here is to get a proper terminfo definition made and
> disseminated for Terminal.app.  A couple questions related to that quest:

> Many tests say a capability is "...not present" or "...not defined".
> Examples...

> (flash) Flash is not defined.  (flash) Done
> (cnorm) Cursor-normal is not defined.  (cnorm) Done
> (hs) Has-status line is not defined.  (hs) Done

> Would the advisable strategy be to enable these in the terminfo and
> see if Terminal.app will then pass the tests?  Finding that it

To do that, you have to have an idea what string might be recognized.
For flash 

	flash=\E[?5h\E[?5l, 

or
	flash=\E[?5h$<100/>\E[?5l,

might work.  The usual problem with flash on different terminal emulators
is that they don't honor the delay time.

For cnorm, the most common ones use the vt320 sequences

	cvvis=\E[?25h,
	cnorm=\E[?25h,

Status line is harder - very few terminal emulators do this (aside from
the kludges that map title-string escapes onto the terminfo, which don't
follow the expected pattern).

> supports blink makes me wonder what other capabilities it might
> support, though not having comprehensive knowledge of the individual
> capabilities themselves I don't know whether you necessarily want them
> defined just because Terminal supports them.

It would be interesting to read Terminal's source - but I suppose that's
part of the code that Apple doesn't publish.

> Also, since the menu issues in Aptitude are my only known remaining
> bug, any guidance on particular tests/capability settings that might
> relate to the rendering issues in the screen shots I posted?  A lot of
> the drawing and alignment related tests seemed to pass, so nothing is
> jumping out at me.

I'd focus on the locale - thinking that Terminal's not going to handle
UTF-8 properly.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



Reply to: