Ian Brandt <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]