reassign 319952 bsdmainutils
retitle 319952 col doesn't handle UTF-8
thanks

On Tue, Jul 26, 2005 at 04:16:13PM +0200, Bas Zoetekouw wrote:
> You wrote:
> > Actually, all locale support is still present. The problem is that man
> > pages being output to a file or a pipe are now filtered through 'col
> > -b', the intent of which was simply:
> >         o When stdout is not a terminal, man pages will be formatted in
> >           plain text without the use of backspace or ANSI formatting
> >           characters.
> > Unfortunately, and unintentionally, this clobbers characters that aren't
> > printable ASCII. Bah. 'col -b -p -x' is much better, but exhibits some
> > minor corruption ("ÜBERSICHT" at the start of a line has some garbage
> > before it, probably because col can't handle the overstruck "Ü").
> 
> Ah, I see.  
> 
> > Changing the arguments to col seems to be obviously the right thing to
> > do, but beyond that I'm not sure what to do about this. I could reassign
> > to bsdmainutils in the hope that col can be changed to deal with UTF-8
> > in UTF-8 locales, or I could just disable the col command in the
> > pipeline for multibyte locales. The latter would be a shame given that
> > it means everyone has to go back to putting explicit 'col -b' in
> > makefiles and things again, and the breakage pending a col fix is
> > confined to just a few places ...
> 
> I think the best way to solve this would indeed be to fix col.  Or maybe
> it can be replaced by a sed script that rips out the ANSI codes?  

man-db (2.4.3-2) unstable; urgency=low

  * Use 'col -b -p -x' rather than just 'col -b' when stdout is not a
    terminal. Partly fixes #319952, but col still needs to be fixed to cope
    with UTF-8 input.
  * Use www-browser as default HTML pager, and suggest the virtual
    www-browser package (closes: #321769).
  * Update debian/copyright with the FSF's new address.

 -- Colin Watson <[EMAIL PROTECTED]>  Tue, 30 Aug 2005 13:37:35 +0100

I think the rest of this bug now belongs to col; at a minimum it should
avoid corrupting UTF-8 text when being run in a UTF-8 locale. Ideally it
would also handle other multibyte encodings correctly.

Cheers,

-- 
Colin Watson                                       [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to