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: