Re: sigs again [Was: Composing in utf8 from latin1 terminal]
Derek's message verified here. Both of Ian's test messages verified here. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu signature.asc Description: PGP signature
Re: sigs again [Was: Composing in utf8 from latin1 terminal]
On Sat, Oct 27, 2018 at 10:25:47AM -0700, Ian Zimmerman wrote: > On 2018-10-25 13:06, Derek Martin wrote: > > > Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 > > Oh, I feel the itch again. Ow-ow, it's unbearable! I must scratch, > > Has anyone tried to verify Derek's GPG signature on his message? It verifies for me. =8^) It's been brought to my attention multiple times that some of my messages do not properly verify, FOR SOME PEOPLE, while others do. FWIW the first occurence of this happened long before any switch of provider (either mine or Mutt's). Fun stuff. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpwL3_b7TCM5.pgp Description: PGP signature
sigs again [Was: Composing in utf8 from latin1 terminal]
On 2018-10-25 13:06, Derek Martin wrote: > Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 Oh, I feel the itch again. Ow-ow, it's unbearable! I must scratch, Has anyone tried to verify Derek's GPG signature on his message? -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: Composing in utf8 from latin1 terminal
On Thu, Oct 25, 2018 at 06:14:18PM +0100, Nuno Silva wrote: > > Also, depending on exactly why you're doing this multi-locale stuff, > > an even better solution may be to let Mutt's send_charset handle it > > for you. [...] > But, if I understood the purpose of send_charset correctly, it only > affects the encoding of the outgoing message. It won't change the > encoding with which mutt reads the temporary file after I close the text > editor, will it? No, but why would you care? It's just an intermediate data encoding. What I'm saying is, forget about your latin1 terminal, do EVERYTHING in Unicode, and let Mutt send the data out as latin1 if appropriate. This may not be appropriate for your use case--it comes down to your reason for using a latin1 terminal to run Mutt in. I can't think of a good reason to do that any longer... so my assumption is your end goal is to produce an outgoing message in latin1 so some recipients who can't yet handle Unicode properly can read it. If your purpose is something else, that may not work, but like I said I can't think of a reason why you'd need to do that. A unicode terminal should have no trouble letting you enter Portuguese (or whatever other language) so long as your locale is correct (and consistent across all programs) and your IME is configured properly. Then Mutt can convert to latin1 to send. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpSNPZYrmzTL.pgp Description: PGP signature
Re: Composing in utf8 from latin1 terminal
On 2018-10-25, Derek Martin wrote: > On Thu, Oct 25, 2018 at 11:11:52AM -0500, Derek Martin wrote: >> On Thu, Oct 25, 2018 at 12:53:43PM +0100, Nuno Silva wrote: >> > When I use emacsclient, the interface locale is not broken: the terminal >> > I/O encoding is correctly set from the locale. The only difference (that >> > I know of) is that Emacs will use utf8 to read/write files. If this >> > should match the terminal encoding, then it *is* broken. > > Also, depending on exactly why you're doing this multi-locale stuff, > an even better solution may be to let Mutt's send_charset handle it > for you. If set properly, you should be able to compose your messages > in UTF-8, and as long as you don't use any non-latin1 characters, > send_charset *should* make sure the message goes out encoded as > latin1. > > The biggest drawback to this approach is you have to be very careful > to not use any non-latin1 characters, or else the message will be sent > as unicode. Otherwise, you'd need to check every message before you > send it to make sure Mutt will send it as the desired encoding. I > have a vague notion that certain other message transforms, like PGP, > may also interfere with this, but I'm not 100% sure. But, if I understood the purpose of send_charset correctly, it only affects the encoding of the outgoing message. It won't change the encoding with which mutt reads the temporary file after I close the text editor, will it? -- Nuno Silva
Re: Composing in utf8 from latin1 terminal
On Thu, Oct 25, 2018 at 11:11:52AM -0500, Derek Martin wrote: > On Thu, Oct 25, 2018 at 12:53:43PM +0100, Nuno Silva wrote: > > When I use emacsclient, the interface locale is not broken: the terminal > > I/O encoding is correctly set from the locale. The only difference (that > > I know of) is that Emacs will use utf8 to read/write files. If this > > should match the terminal encoding, then it *is* broken. Also, depending on exactly why you're doing this multi-locale stuff, an even better solution may be to let Mutt's send_charset handle it for you. If set properly, you should be able to compose your messages in UTF-8, and as long as you don't use any non-latin1 characters, send_charset *should* make sure the message goes out encoded as latin1. The biggest drawback to this approach is you have to be very careful to not use any non-latin1 characters, or else the message will be sent as unicode. Otherwise, you'd need to check every message before you send it to make sure Mutt will send it as the desired encoding. I have a vague notion that certain other message transforms, like PGP, may also interfere with this, but I'm not 100% sure. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgppEdh53sHJZ.pgp Description: PGP signature
Re: Composing in utf8 from latin1 terminal
On Thu, Oct 25, 2018 at 12:53:43PM +0100, Nuno Silva wrote: > When I use emacsclient, the interface locale is not broken: the terminal > I/O encoding is correctly set from the locale. The only difference (that > I know of) is that Emacs will use utf8 to read/write files. If this > should match the terminal encoding, then it *is* broken. I suspected as much. The issue, as far as I can tell based on your description of things, is that the emacs *server* is running with a UTF-8 locale, which is why it is editing files in that locale, and you're connecting to it from a client that's running a different locale. That's definitely broken, as would be any such locale mismatch. Your hack may well work around it... but you should be very clear that you're doing something unexpected (and generally undesirable) which may well break in other ways later. That's what's called a gross hack. A likely better solution would be to run two instances of emacs server, one in each locale, and make mutt connect to the right one. But either way it comes down to the choice of running two different instances of emacs, or using a gross hack to avoid that. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgp_KyQrAdmHJ.pgp Description: PGP signature
Re: Composing in utf8 from latin1 terminal
On 2018-10-24, Derek Martin wrote: > On Tue, Oct 23, 2018 at 10:31:45PM +0100, Nuno Silva wrote: >> On 2017-10-12, nunojsi...@ist.utl.pt wrote: >> >> > Recently, I have tried to use mutt on a non-utf8 terminal. Everything >> > works as expected in an utf8 environment, but when I compose new e-mails >> > in a latin1/ISO-8859-1 terminal, mutt will expect the file to be in the >> > same encoding as the terminal, while my text editor will save the file >> > in utf8. The result is that non-ASCII characters get misinterpreted, >> > which can affect the message headers as well (e.g. real names in To: and >> > Cc:). >> [...] >> > Is there some way to configure mutt so that it always uses utf8 to read >> > the new message after I exit the editor? Or a way to enable some >> > encoding autodetection that can tell utf8 apart from latin1? > > The bottom line is that your environment is misconfigured. If you > want this to work, you need to have LANG set properly at every point > along the execution path. Your terminal, terminal font, editor, and > Mutt all need to know that you're using latin1 instead of Unicode, by > having been started with a latin1 LANG setting. You may need to > configure your terminal to use the correct font, although with many > modern terminals (like gnome-term, kterm, etc.) this should be > unnecessary. > > If you are launching the latin1 terminal from a shell that has its > LANG set to UTF-8, it could break (an example of this is starting > hanterm, a terminal program expressly for Korean input with EUC-KR, > with a UTF-8 locale--won't work). If the shell running inside the > terminal has LANG set to UTF-8, both Mutt and your editor could break. > If you have manual settings on any of these programs to override the > locale defined by the environment, it could break. If you don't have > all of these things set the same way, it could, and almost certainly > will break. Sometimes the breakage is subtle, e.g. if you dump the > right characters to a terminal (say, with the cat command) tht has the > right font, it will generally display them correctly, even if the > locale is wrong. But using them with programs that need to know the > locale will still break. > > If you're using a Mutt setting to connect to an existing emacs > instance (via emacsclient or similar) that's already running in a > UTF-8 locale, that's broken. You need to start a new instance of > emacs whose locale is latin1. I haven't noticed this before, but there *is* indeed a difference when starting a fresh new Emacs instance instead of connecting to an existing one using emacsclient: the new instance does use latin1 to read/write files. (That is, the behaviour expected by mutt.) When I use emacsclient, the interface locale is not broken: the terminal I/O encoding is correctly set from the locale. The only difference (that I know of) is that Emacs will use utf8 to read/write files. If this should match the terminal encoding, then it *is* broken. I might be happy with the way things are now (as my files are usually in utf8, and mutt is the only context where I need the file encoding to match the terminal), but I won't claim it isn't broken if it is. > Lastly, you may need to adjust send_charset in Mutt. It can have > multiple locales, and Mutt will pick the first one that your document > can be displayed in. For example, mine is: > > set send_charset="iso-8859-1:utf-8" > > If my e-mail contains no characters that need UTF-8, Mutt will choose > to send the message as iso-8859-1, but otherwise as UTF-8. > > If you do those things, it should "just work" and if you don't it > won't, at least without jumping through pointless hoops to force it, > which will most likely just break other things. send_charset appears to be working correctly here, I've checked it a couple days ago. It isn't even set in any configuration file, so I suppose it is using the default setting. For now, I will leave the Emacs hack in place, as I prefer to use the Emacs "server instance" instead of creating a new one. Everything else is hopefully correctly set, as this has been the only encoding problem I've had in the past months. (Now that I've said this, I will probably discover a new one tomorrow...) -- Nuno Silva
Re: Composing in utf8 from latin1 terminal
On 2018-10-24, Ian Zimmerman wrote:
> On 2018-10-23 22:31, Nuno Silva wrote:
>
>> So far I did not find a way to change this on the mutt side, but I made
>> a new major mode for mutt messages in Emacs (the editor I use with
>> mutt), with a hook that changes the file encoding to latin1 if the file
>> was opened in a latin1 terminal and Emacs cannot detect a non-ASCII file
>> encoding.
>>
>> It appears to work here. I'm sure someone who is more versed in Emacs
>> than me would be able to come up with a more elegant solution, but I'm
>> sharing mine here just in case it is useful to somebody else someday:
>>
>> (define-derived-mode my-mutt-message-mode message-mode "MuttMSG")
>> (add-hook
>> 'my-mutt-message-mode-hook
>> (lambda ()
>>(when (equal (terminal-coding-system) 'iso-latin-1-unix)
>> (let ((encoding (detect-coding-region (point-min) (point-max
>>(when (or
>> (equal encoding '(undecided-unix))
>> (equal encoding '(undecided)))
>> (setq buffer-file-coding-system 'iso-latin-1-unix))
>> (add-to-list 'auto-mode-alist '("/mutt" . my-mutt-message-mode))
>
> You could just hook message-mode-hook with a function that checks
> buffer-file-name, I think that would be a bit more straightforward than
> adding a new mode.
Yes, it would be. In my case, I am also redefining a keybinding (C-c
C-c, and possibly more in the future), so the new mode is a way to keep
these mutt-related changes together.
> Other possibilities: you could handle this still in Emacs, but after you
> finish writing, at the point you save the temporary file (with one of
> the write hooks). Or you can write a script that runs Emacs and then
> recodes the file outside of Emacs, using something like iconv(1).
--
Nuno Silva
Re: Composing in utf8 from latin1 terminal
On Tue, Oct 23, 2018 at 10:31:45PM +0100, Nuno Silva wrote: > On 2017-10-12, nunojsi...@ist.utl.pt wrote: > > > Recently, I have tried to use mutt on a non-utf8 terminal. Everything > > works as expected in an utf8 environment, but when I compose new e-mails > > in a latin1/ISO-8859-1 terminal, mutt will expect the file to be in the > > same encoding as the terminal, while my text editor will save the file > > in utf8. The result is that non-ASCII characters get misinterpreted, > > which can affect the message headers as well (e.g. real names in To: and > > Cc:). > [...] > > Is there some way to configure mutt so that it always uses utf8 to read > > the new message after I exit the editor? Or a way to enable some > > encoding autodetection that can tell utf8 apart from latin1? The bottom line is that your environment is misconfigured. If you want this to work, you need to have LANG set properly at every point along the execution path. Your terminal, terminal font, editor, and Mutt all need to know that you're using latin1 instead of Unicode, by having been started with a latin1 LANG setting. You may need to configure your terminal to use the correct font, although with many modern terminals (like gnome-term, kterm, etc.) this should be unnecessary. If you are launching the latin1 terminal from a shell that has its LANG set to UTF-8, it could break (an example of this is starting hanterm, a terminal program expressly for Korean input with EUC-KR, with a UTF-8 locale--won't work). If the shell running inside the terminal has LANG set to UTF-8, both Mutt and your editor could break. If you have manual settings on any of these programs to override the locale defined by the environment, it could break. If you don't have all of these things set the same way, it could, and almost certainly will break. Sometimes the breakage is subtle, e.g. if you dump the right characters to a terminal (say, with the cat command) tht has the right font, it will generally display them correctly, even if the locale is wrong. But using them with programs that need to know the locale will still break. If you're using a Mutt setting to connect to an existing emacs instance (via emacsclient or similar) that's already running in a UTF-8 locale, that's broken. You need to start a new instance of emacs whose locale is latin1. Lastly, you may need to adjust send_charset in Mutt. It can have multiple locales, and Mutt will pick the first one that your document can be displayed in. For example, mine is: set send_charset="iso-8859-1:utf-8" If my e-mail contains no characters that need UTF-8, Mutt will choose to send the message as iso-8859-1, but otherwise as UTF-8. If you do those things, it should "just work" and if you don't it won't, at least without jumping through pointless hoops to force it, which will most likely just break other things. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgps1A3kowv76.pgp Description: PGP signature
Re: Composing in utf8 from latin1 terminal
On 2018-10-23 22:31, Nuno Silva wrote:
> So far I did not find a way to change this on the mutt side, but I made
> a new major mode for mutt messages in Emacs (the editor I use with
> mutt), with a hook that changes the file encoding to latin1 if the file
> was opened in a latin1 terminal and Emacs cannot detect a non-ASCII file
> encoding.
>
> It appears to work here. I'm sure someone who is more versed in Emacs
> than me would be able to come up with a more elegant solution, but I'm
> sharing mine here just in case it is useful to somebody else someday:
>
> (define-derived-mode my-mutt-message-mode message-mode "MuttMSG")
> (add-hook
> 'my-mutt-message-mode-hook
> (lambda ()
>(when (equal (terminal-coding-system) 'iso-latin-1-unix)
> (let ((encoding (detect-coding-region (point-min) (point-max
>(when (or
> (equal encoding '(undecided-unix))
> (equal encoding '(undecided)))
> (setq buffer-file-coding-system 'iso-latin-1-unix))
> (add-to-list 'auto-mode-alist '("/mutt" . my-mutt-message-mode))
You could just hook message-mode-hook with a function that checks
buffer-file-name, I think that would be a bit more straightforward than
adding a new mode.
Other possibilities: you could handle this still in Emacs, but after you
finish writing, at the point you save the temporary file (with one of
the write hooks). Or you can write a script that runs Emacs and then
recodes the file outside of Emacs, using something like iconv(1).
--
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: Composing in utf8 from latin1 terminal
On 2017-10-12, nunojsi...@ist.utl.pt wrote:
> Recently, I have tried to use mutt on a non-utf8 terminal. Everything
> works as expected in an utf8 environment, but when I compose new e-mails
> in a latin1/ISO-8859-1 terminal, mutt will expect the file to be in the
> same encoding as the terminal, while my text editor will save the file
> in utf8. The result is that non-ASCII characters get misinterpreted,
> which can affect the message headers as well (e.g. real names in To: and
> Cc:).
[...]
> Is there some way to configure mutt so that it always uses utf8 to read
> the new message after I exit the editor? Or a way to enable some
> encoding autodetection that can tell utf8 apart from latin1?
So far I did not find a way to change this on the mutt side, but I made
a new major mode for mutt messages in Emacs (the editor I use with
mutt), with a hook that changes the file encoding to latin1 if the file
was opened in a latin1 terminal and Emacs cannot detect a non-ASCII file
encoding.
It appears to work here. I'm sure someone who is more versed in Emacs
than me would be able to come up with a more elegant solution, but I'm
sharing mine here just in case it is useful to somebody else someday:
(define-derived-mode my-mutt-message-mode message-mode "MuttMSG")
(add-hook
'my-mutt-message-mode-hook
(lambda ()
(when (equal (terminal-coding-system) 'iso-latin-1-unix)
(let ((encoding (detect-coding-region (point-min) (point-max
(when (or
(equal encoding '(undecided-unix))
(equal encoding '(undecided)))
(setq buffer-file-coding-system 'iso-latin-1-unix))
(add-to-list 'auto-mode-alist '("/mutt" . my-mutt-message-mode))
--
Nuno Silva
Composing in utf8 from latin1 terminal
Hello, Recently, I have tried to use mutt on a non-utf8 terminal. Everything works as expected in an utf8 environment, but when I compose new e-mails in a latin1/ISO-8859-1 terminal, mutt will expect the file to be in the same encoding as the terminal, while my text editor will save the file in utf8. The result is that non-ASCII characters get misinterpreted, which can affect the message headers as well (e.g. real names in To: and Cc:). When replying to messages, this has not been an issue so far, as mutt includes the quoted copy of the message I'm replying to and the editor can use that to guess the encoding. Is there some way to configure mutt so that it always uses utf8 to read the new message after I exit the editor? Or a way to enable some encoding autodetection that can tell utf8 apart from latin1? -- Thanks in advance, Nuno Silva
Re: Convert ascii UTF8 code (in mutt "to:" header) to real UTF8
El día Friday, June 03, 2016 a las 06:05:11PM -0300, Marcelo Laia escribió: > > And btw: try to break your lines between 72 and 80 chars. > > Yes! I do! I use mutt + vi. So, they do that for me. Are there some problems > with your friend terminals? No, you do not as yu could proof: $ grep '^Yes, I do! I read all ' /var/mail/guru Yes, I do! I read all messages in the thread and in there isn't a friend solution! If there are, please, point me out. $ grep '^Yes, I do! I read all ' /var/mail/guru | wc 1 24 119 i.e. one line with 118 chars and a \n to much for a normal friendly terminal; q.e.d. matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 "Die Verkaufsschlager des Buchmarkts geben Auskunft über den Zustand einer Gesellschaft bzw. sind, was diese Zeiten angeht, Gradmesser fortschreitenden Schwachsinns. ..." (jW 19.05.2016)
Re: Convert ascii UTF8 code (in mutt "to:" header) to real UTF8
On Fri, Jun 3, 2016 at 5:45 AM, Ionel Mugurel Ciobîcă wrote: > On 3-06-2016, at 10h 52'54", Christian Brabandt wrote about "Re: Convert > ascii UTF8 code (in mutt "to:" header) to real UTF8" >> >> An alternative might be qprint (package qprint) >> > > Yes, qprint should do it: > > # echo "Ker=C4=B1ko" | qprint -d > Kerıko > > You just need to deal yourself with the "=?utf-8?Q?" and "?=". > > You can look for alternative programs that understand the RFC 1521 > MIME Quoted-Printable standard. > > Some e-mails will have the name encoded in base64. This will look > maybe like this: > > To: Jeri =?utf-8?B?S2VyxLFrbwo=?= <...> > > You decode those by base64: > > # echo "S2VyxLFrbwo=" | base64 -d > Kerıko > > Again, you need to take care yourself of the "=?utf-8?B?" and "?=". > > > Good luck. > Ionel Oh great! I'm very happy. Thank you to everyone. So many kind people here. So solution is to use qprint or mmencode, extract the part to pass, and then paste together. My sed talents are not high, but I am sure I can achieve it after some study. I will post a full solution if I achieve it. Kind regards, Xu
Re: Convert ascii UTF8 code (in mutt "to:" header) to real UTF8
On 03/06/16 at 10:52pm, Matthias Apitz wrote: > El día Friday, June 03, 2016 a las 05:45:04PM -0300, Marcelo Laia escribió: > > > Yes, I do! I read all messages in the thread and in there isn't a friend > > solution! If there are, please, point me out. > > I have no clue about what for you is a 'friend solution'. In the thread > there are some useful solutions. Any one solved my problem! So, they inst a 'friend solution'. > And btw: try to break your lines between 72 and 80 chars. Yes! I do! I use mutt + vi. So, they do that for me. Are there some problems with your friend terminals? -- Marcelo
Re: Convert ascii UTF8 code (in mutt "to:" header) to real UTF8
El día Friday, June 03, 2016 a las 05:45:04PM -0300, Marcelo Laia escribió: > Yes, I do! I read all messages in the thread and in there isn't a friend > solution! If there are, please, point me out. I have no clue about what for you is a 'friend solution'. In the thread there are some useful solutions. And btw: try to break your lines between 72 and 80 chars. 80-column punchcards and terminals based on this size are still our friends. matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 "Die Verkaufsschlager des Buchmarkts geben Auskunft über den Zustand einer Gesellschaft bzw. sind, was diese Zeiten angeht, Gradmesser fortschreitenden Schwachsinns. ..." (jW 19.05.2016)
Re: Convert ascii UTF8 code (in mutt "to:" header) to real UTF8
On 03/06/16 at 09:14pm, Matthias Apitz wrote: > El día Friday, June 03, 2016 a las 08:49:44AM -0300, Marcelo Laia escribió: > > > Hi, > > > > I have the same problem here. If you found a solution, please, share it. > > Please read / glance through the entire thread and do not just TOP POST on > the first > message in the thread. > Yes, I do! I read all messages in the thread and in there isn't a friend solution! If there are, please, point me out. I do a top post exactly for that: insnt a solution inside the thread. -- Marcelo
Re: Convert ascii UTF8 code (in mutt "to:" header) to real UTF8
El día Friday, June 03, 2016 a las 08:49:44AM -0300, Marcelo Laia escribió: > Hi, > > I have the same problem here. If you found a solution, please, share it. Please read / glance through the entire thread and do not just TOP POST on the first message in the thread. matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 "Die Verkaufsschlager des Buchmarkts geben Auskunft über den Zustand einer Gesellschaft bzw. sind, was diese Zeiten angeht, Gradmesser fortschreitenden Schwachsinns. ..." (jW 19.05.2016)
Re: Convert ascii UTF8 code (in mutt "to:" header) to real UTF8
Hi, I have the same problem here. If you found a solution, please, share it. Marcelo On 03/06/16 at 01:35am, Xu Wang wrote: > Hello, > > When I pipe email I see the following header: > > To: Jeri =?utf-8?Q?Ker=C4=B1ko?= > > I would like to get the name with the UTF8 character, without special > code, which in this case is: Jeri Kerıko (note that the last i has no > dot) > Is there a Linux command that can convert the special code to actual > UTF8 character which my terminal know how to display and actually > display correctly in mutt, but not when I pipe to custom script. > > What is the name for that special code? is it encoding? I see also header > Content-Type: text/plain; charset=us-ascii > but does that refer only to body or does that mean that the above > special code is us-ascii and I must look for ascii to utf8 converter? > > Kind regards, > > Xu -- Marcelo
Re: Convert ascii UTF8 code (in mutt "to:" header) to real UTF8
El día Friday, June 03, 2016 a las 08:13:00PM +1000, Erik Christiansen escribió: > > $ fgrep -A1 MASTER_SITES ports-r414411/*/metamail/Makefile > > MASTER_SITES= http://ftp.funet.fi/pub/unix/mail/metamail/ \ > > ftp://ftp.research.telcordia.com/pub/nsb/ > > > > I don't know if this would compile straight forward on your system. > > A previous build of the 2.7 version, some years ago, worked fine, but > the link I had kept: http://kb.iu.edu/data/data/aibt.html is now a 404, > which inclines me to go with Debian's decision to obsolete the package > on the basis that it isn't maintained. (Better to invest in remembering > replacement utilities with a greater future availability, I think.) In FreeBSD the port is still actively maintained. > > Erik > (who remembers when uuencode was the go-to decoding utility.) Matthias who still uses from time to time uuencode/uudecode to move a binary to a customer site when I only have terminal access to this system (gzip the file, uuencode it, cut&paste into a cat or vi command at remote site, uudecode it) -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 "Die Verkaufsschlager des Buchmarkts geben Auskunft über den Zustand einer Gesellschaft bzw. sind, was diese Zeiten angeht, Gradmesser fortschreitenden Schwachsinns. ..." (jW 19.05.2016)
Re: Convert ascii UTF8 code (in mutt "to:" header) to real UTF8
On 3-06-2016, at 10h 52'54", Christian Brabandt wrote about "Re: Convert ascii UTF8 code (in mutt "to:" header) to real UTF8" > > An alternative might be qprint (package qprint) > Yes, qprint should do it: # echo "Ker=C4=B1ko" | qprint -d Kerıko You just need to deal yourself with the "=?utf-8?Q?" and "?=". You can look for alternative programs that understand the RFC 1521 MIME Quoted-Printable standard. Some e-mails will have the name encoded in base64. This will look maybe like this: To: Jeri =?utf-8?B?S2VyxLFrbwo=?= <...> You decode those by base64: # echo "S2VyxLFrbwo=" | base64 -d Kerıko Again, you need to take care yourself of the "=?utf-8?B?" and "?=". Good luck. Ionel
Re: Convert ascii UTF8 code (in mutt "to:" header) to real UTF8
On 03.06.16 10:32, Matthias Apitz wrote: > I'm on FreeBSD and do compile all from sources (the so called ports > collection). mmencode comes from: > > $ which mmencode > /usr/local/bin/mmencode > $ pkg which /usr/local/bin/mmencode > /usr/local/bin/mmencode was installed by package metamail-2.7_11 > > $ fgrep -A1 MASTER_SITES ports-r414411/*/metamail/Makefile > MASTER_SITES= http://ftp.funet.fi/pub/unix/mail/metamail/ \ > ftp://ftp.research.telcordia.com/pub/nsb/ > > I don't know if this would compile straight forward on your system. A previous build of the 2.7 version, some years ago, worked fine, but the link I had kept: http://kb.iu.edu/data/data/aibt.html is now a 404, which inclines me to go with Debian's decision to obsolete the package on the basis that it isn't maintained. (Better to invest in remembering replacement utilities with a greater future availability, I think.) Erik (who remembers when uuencode was the go-to decoding utility.)
Re: Convert ascii UTF8 code (in mutt "to:" header) to real UTF8
On 03.06.16 10:52, Christian Brabandt wrote: > > An alternative might be qprint (package qprint) Indeedy! :-) Thank you Christian. I've made a note of that. (Stuff from many years ago now sticks better than new stuff. :( Regards, Erik
Re: Convert ascii UTF8 code (in mutt "to:" header) to real UTF8
Hi Erik! On Fr, 03 Jun 2016, Erik Christiansen wrote: > On 03.06.16 08:45, Matthias Apitz wrote: > > $ echo 'Ker=C4=B1ko' | mmencode -u -q > > Kerıko > > $ echo 'Ker=C4=B1ko' | mmencode -u -q | od -tx1 > > 0004b 65 72 c4 b1 6b 6f 0a > > 010 > > Matthias, mmencode looks very useful, but I'm not able to find it on my > debian install, and apt-search doesn't do any good either. We used to > have mimencode, but that was obsoleted years ago. I tried munpack, but > that doesn't seem to make any attempt to handle mime fragments. > Any clue on where mmencode might be snaffled would be very handy. An alternative might be qprint (package qprint) regards, Christian -- Moore's Constant: Everybody sets out to do something, and everybody does something, but no one does what he sets out to do.
Re: Convert ascii UTF8 code (in mutt "to:" header) to real UTF8
El d�a Friday, June 03, 2016 a las 05:52:36PM +1000, Erik Christiansen escribi�: > On 03.06.16 08:45, Matthias Apitz wrote: > > $ echo 'Ker=C4=B1ko' | mmencode -u -q > > Kerıko > > $ echo 'Ker=C4=B1ko' | mmencode -u -q | od -tx1 > > 0004b 65 72 c4 b1 6b 6f 0a > > 010 > > Matthias, mmencode looks very useful, but I'm not able to find it on my > debian install, and apt-search doesn't do any good either. We used to > have mimencode, but that was obsoleted years ago. I tried munpack, but > that doesn't seem to make any attempt to handle mime fragments. > Any clue on where mmencode might be snaffled would be very handy. I'm on FreeBSD and do compile all from sources (the so called ports collection). mmencode comes from: $ which mmencode /usr/local/bin/mmencode $ pkg which /usr/local/bin/mmencode /usr/local/bin/mmencode was installed by package metamail-2.7_11 $ fgrep -A1 MASTER_SITES ports-r414411/*/metamail/Makefile MASTER_SITES= http://ftp.funet.fi/pub/unix/mail/metamail/ \ ftp://ftp.research.telcordia.com/pub/nsb/ I don't know if this would compile straight forward on your system. HIH matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-176-38902045 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign
Re: Convert ascii UTF8 code (in mutt "to:" header) to real UTF8
On Fri, Jun 03, 2016 at 05:52:36PM +1000, Erik Christiansen wrote: > On 03.06.16 08:45, Matthias Apitz wrote: > > $ echo 'Ker=C4=B1ko' | mmencode -u -q > > Kerıko > > $ echo 'Ker=C4=B1ko' | mmencode -u -q | od -tx1 > > 0004b 65 72 c4 b1 6b 6f 0a > > 010 > > Matthias, mmencode looks very useful, but I'm not able to find it on my > debian install, and apt-search doesn't do any good either. We used to > have mimencode, but that was obsoleted years ago. I tried munpack, but > that doesn't seem to make any attempt to handle mime fragments. > Any clue on where mmencode might be snaffled would be very handy. > > Erik My system says: The program 'mmencode' is currently not installed. You can install it by typing: sudo apt-get install xemacs21-bin However, after installation, there is no man-page for xemacs21-bin. ulrich
Re: Convert ascii UTF8 code (in mutt "to:" header) to real UTF8
On 03.06.16 08:45, Matthias Apitz wrote: > $ echo 'Ker=C4=B1ko' | mmencode -u -q > Kerıko > $ echo 'Ker=C4=B1ko' | mmencode -u -q | od -tx1 > 0004b 65 72 c4 b1 6b 6f 0a > 010 Matthias, mmencode looks very useful, but I'm not able to find it on my debian install, and apt-search doesn't do any good either. We used to have mimencode, but that was obsoleted years ago. I tried munpack, but that doesn't seem to make any attempt to handle mime fragments. Any clue on where mmencode might be snaffled would be very handy. Erik
Re: Convert ascii UTF8 code (in mutt "to:" header) to real UTF8
El día Friday, June 03, 2016 a las 01:35:40AM -0400, Xu Wang escribió: > Hello, > > When I pipe email I see the following header: > > To: Jeri =?utf-8?Q?Ker=C4=B1ko?= > > I would like to get the name with the UTF8 character, without special > code, which in this case is: Jeri Kerıko (note that the last i has no > dot) > Is there a Linux command that can convert the special code to actual > UTF8 character which my terminal know how to display and actually > display correctly in mutt, but not when I pipe to custom script. > > What is the name for that special code? is it encoding? I see also header > Content-Type: text/plain; charset=us-ascii > but does that refer only to body or does that mean that the above > special code is us-ascii and I must look for ascii to utf8 converter? Hello, $ echo 'Ker=C4=B1ko' | mmencode -u -q Kerıko $ echo 'Ker=C4=B1ko' | mmencode -u -q | od -tx1 0004b 65 72 c4 b1 6b 6f 0a 010 matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 "Die Verkaufsschlager des Buchmarkts geben Auskunft über den Zustand einer Gesellschaft bzw. sind, was diese Zeiten angeht, Gradmesser fortschreitenden Schwachsinns. ..." (jW 19.05.2016)
Convert ascii UTF8 code (in mutt "to:" header) to real UTF8
Hello, When I pipe email I see the following header: To: Jeri =?utf-8?Q?Ker=C4=B1ko?= I would like to get the name with the UTF8 character, without special code, which in this case is: Jeri Kerıko (note that the last i has no dot) Is there a Linux command that can convert the special code to actual UTF8 character which my terminal know how to display and actually display correctly in mutt, but not when I pipe to custom script. What is the name for that special code? is it encoding? I see also header Content-Type: text/plain; charset=us-ascii but does that refer only to body or does that mean that the above special code is us-ascii and I must look for ascii to utf8 converter? Kind regards, Xu
[solved] garbage thread characters with utf8
Dear mutt users / developers, I have found a (the?) solution to the problem mentioned in the FAQ where utf8 characters used to draw the message thread (red arrows) become garbled. In my case (seen it multiple times) it happened on a new ubuntu 10.04 system. The problem has to do with the LANG setting: this should be set to en_US.utf8 or something similar. Setting that in a terminal and running mutt did NOT fix the problem though. The issue: the LANG variable was NOT set when the terminal (gnome-terminal) was started, so the terminal program itself (gnome-terminal) was not using the utf8 locale. Solution: set your LANG variable in your first login script (e.g. .xsession), or change the system wide default to a utf8 encoding. In my case I did this with sudo update-locale LANG=en_US.utf8 Logout after doing this, so your environment picks it up. Note that setting LANG in .bashrc is probably not going to work, as this is not read by your login environment (e.g. gdm + xsession). Perhaps it's an idea to put this on the mutt wiki page. I hope it helps someone else. Kind regards, Hein Zelle
Re: utf8 file corruption after transmission over email
Hi, * Jussi Peltola wrote: > On Fri, May 08, 2009 at 06:23:15PM -0700, zion wrote: > > if LC_CTYPE is unset, file doesn't get corrupted. In that case, what does ':set ?charset' in mutt report? > I think mutt is reading your file, assuming it's KOI8-R as stated in > your locale, and converting it to UTF-8 for sending. > > It has to do that; plain text won't tell it what charset it's in and it > has to guess. Yes. If mutt is recent enough, $attach_charset can help (it specifies the charsets to use for guessing for text media type attachments). Rocco
Re: utf8 file corruption after transmission over email
On Fri, May 08, 2009 at 06:23:15PM -0700, zion wrote: > On Fri, May 08, 2009 at 04:34:14PM -0700, zion wrote: > > Well, I just captured smtp session of loopback interface (same box where > > mutt is running). Here is the relevant part: > > 03d0: 746f 3e38 353c 2f74 6f3e 0d0a 0909 093c to>85.< > > 03e0: 7265 6164 3e21 d091 e288 9ae2 9591 3c2f read>!п.Б..Б.. > > > 03f0: 7265 6164 3e0d 0a09 0909 3c77 7269 7465 read>. > > > As you can see, this character is already messed up before reaching > > server. So, @gmail is not guilty here ;-). > Turns out it's my locale. having this causes the problem: > LC_CTYPE=ru_RU.KOI8-R > if LC_CTYPE is unset, file doesn't get corrupted. I think mutt is reading your file, assuming it's KOI8-R as stated in your locale, and converting it to UTF-8 for sending. It has to do that; plain text won't tell it what charset it's in and it has to guess. If you want to send files over email byte-per-byte, renaming them to .bin or something else that has the mime type of application/octet-stream should work better. -- Jussi Peltola
Re: utf8 file corruption after transmission over email
On Fri, May 08, 2009 at 04:34:14PM -0700, zion wrote: > Well, I just captured smtp session of loopback interface (same box where > mutt is running). Here is the relevant part: > 03d0: 746f 3e38 353c 2f74 6f3e 0d0a 0909 093c to>85.< > 03e0: 7265 6164 3e21 d091 e288 9ae2 9591 3c2f read>!п.Б..Б.. > 03f0: 7265 6164 3e0d 0a09 0909 3c77 7269 7465 read>. > As you can see, this character is already messed up before reaching > server. So, @gmail is not guilty here ;-). Turns out it's my locale. having this causes the problem: LC_CTYPE=ru_RU.KOI8-R if LC_CTYPE is unset, file doesn't get corrupted.
Re: utf8 file corruption after transmission over email
Well, I just captured smtp session of loopback interface (same box where mutt is running). Here is the relevant part: 03d0: 746f 3e38 353c 2f74 6f3e 0d0a 0909 093c to>85.< 03e0: 7265 6164 3e21 d091 e288 9ae2 9591 3c2f read>!п.Б..Б...
Re: utf8 file corruption after transmission over email
On Fri, May 08, 2009 at 06:04:42PM -0500, Kyle Wheeler wrote: > On Friday, May 8 at 03:00 PM, quoth Aaron S.: > > I have a mystery that I'm trying to solve to no avail. > > Hopefully we can help! > > > I got a little sample XML (utf-8) encoded file that I'm trying to > > send as attachment. When I attach it, mutt correctly identifies it: > > [text/plain, 8bit, utf-8, 0.3K], since there are non-ASCII > > characters, in this case there is only 1 such character. > > Well, actually, that's an incorrect identification. It's NOT a > text/plain file, it's an xml file. According to RFC 3023, it should > either be sent as application/xml or as text/xml. > > Now, that misidentification shouldn't cause the problem you're having, > but correcting it *probably* will fix the problem. I bet that if you > add the following to your ~/.mime.types file, the problem goes away: > > application/xml jff > > > After I send it, this attached file becomes currupt. > > I tried sending your file to myself, both with and without that line > in my mime.types file, and the file didn't get corrupted either way. > > My guess is that this is ACTUALLY your mail server's fault (did you > send it through an MSFT Exchange server maybe? They're really bad > about this). Here's what I think happened: you have configured mutt to > send things in 8-bit mode (i.e. $allow_8bit). Thus, when sending a > utf-8 file attachment with an unusual character in it, mutt sent it > completely unmodified, because that's supposed to be safe to do when > sending in 8-bit mode. But some servers (and I've had this happen more > often than not with Exchange servers) attempt to convert all messages > into 7-bit form. Unfortunately, they're often very bad at it. I've had > several messages corrupted by Exchange servers simply because they > couldn't handle curly-quotes correctly. It's happened often enough > that I finally just unset allow_8bit so that mutt would always take > care of encoding my messages in a 7-bit safe manner, because mutt is > so much better at it than they are. > > Anyway, does that help? Hello, Well, it was sent from @gmail to another @gmail account. I have no idea what they run there at google. I thought about adding that to mime.types and it does work. What bothers me is that now I have to pay much closer attention as to when I'm attaching strange files. I'm gonna have to think of a way to intercept whatever mutt is sending out to make sure it's not mutt that messes up this 3byte UTF-8 character. In any case, thanks for your pointers.
Re: utf8 file corruption after transmission over email
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Friday, May 8 at 03:00 PM, quoth Aaron S.: > I have a mystery that I'm trying to solve to no avail. Hopefully we can help! > I got a little sample XML (utf-8) encoded file that I'm trying to > send as attachment. When I attach it, mutt correctly identifies it: > [text/plain, 8bit, utf-8, 0.3K], since there are non-ASCII > characters, in this case there is only 1 such character. Well, actually, that's an incorrect identification. It's NOT a text/plain file, it's an xml file. According to RFC 3023, it should either be sent as application/xml or as text/xml. Now, that misidentification shouldn't cause the problem you're having, but correcting it *probably* will fix the problem. I bet that if you add the following to your ~/.mime.types file, the problem goes away: application/xml jff > After I send it, this attached file becomes currupt. I tried sending your file to myself, both with and without that line in my mime.types file, and the file didn't get corrupted either way. My guess is that this is ACTUALLY your mail server's fault (did you send it through an MSFT Exchange server maybe? They're really bad about this). Here's what I think happened: you have configured mutt to send things in 8-bit mode (i.e. $allow_8bit). Thus, when sending a utf-8 file attachment with an unusual character in it, mutt sent it completely unmodified, because that's supposed to be safe to do when sending in 8-bit mode. But some servers (and I've had this happen more often than not with Exchange servers) attempt to convert all messages into 7-bit form. Unfortunately, they're often very bad at it. I've had several messages corrupted by Exchange servers simply because they couldn't handle curly-quotes correctly. It's happened often enough that I finally just unset allow_8bit so that mutt would always take care of encoding my messages in a 7-bit safe manner, because mutt is so much better at it than they are. Anyway, does that help? ~Kyle - -- Anyway, have fun. And don't bother reporting any bugs for the next few days. I won't care anyway. -- Linus Torvalds, when kernel 2.4 came out -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iQIcBAEBCAAGBQJKBLqJAAoJECuveozR/AWeBBQP/j1tOe19BTFKo/AN4gzcDhTS 72ug8j7pY3M75W7DJ33Bx3p6gafGEwaiHh6mePt/0L4YuHzGpZxhog9FmmzptJmG 1ROfdmkJ4DYH7zrXTHvLBufrp1I/hlAGqsogncrs+N/gLV6QNzJno3FnY9xkVbxe DNm3MgkksZ1U9uMXyhrHsoJ+NQ01zuzP6BtEp1uVQKOHnluEd8jzyR9Dow5j5/8A zp84PLMCvHn5UIQl1cf8qoUGFSfznBmK6xMgBDXCy/bghjwliGdPsy8n3Y0VhD6V 16vqx3qcTwoSbbTaQcyqY++v82TvQAz8izat23C1OWxWnYoAiy5lEjMv5FBh5UkO dyDZKAWM4XmM05c1GexEcmhfvAHOQ2Il93hluKA7ZIFGeDfyz4Hl+dkeY7aSX2ek 6caHXz+jQnRz6hgBnwk1GcoTDwdmAdtU8XZYCjYHo+1BotMyKzMcE7c/483pj4Kb dOpluhcPXsjnHKJK3wvRzT9lQqfGy4XFU6SuxXIH8TIxucAvlw+ZWrwUdpx1btIm tH1ESVyIr4RoAm8viVl/OUdZ2apF8an9faxMwa80YBVGog9TxfoCy0jYOxs0g9YW KLhPmaeeHaBaFpeha//MN8zcMxNknx7WsFvg2eL7XyMoUj3s2LhlWE6eQu0Luijc 3NWylNKI3jMswtfFtUyQ =Hbvl -END PGP SIGNATURE-
utf8 file corruption after transmission over email
Hello, I have a mystery that I'm trying to solve to no avail. mutt-1.5.19 is running on OpenBSD 4.5, "--with-idn". I got a little sample XML (utf-8) encoded file that I'm trying to send as attachment. When I attach it, mutt correctly identifies it: [text/plain, 8bit, utf-8, 0.3K], since there are non-ASCII characters, in this case there is only 1 such character. After I send it, this attached file becomes currupt. before I send it: MD5 (hw2.jff) = 9a14b9ac1a12deb07d262b6658d7b9b2 after: MD5 (hw2.jff-corrupted) = 718597b09e7544f89cd255a5d4c8e301 this file contains a 'WHITE SQUARE' character, see http://www.fileformat.info/info/unicode/char/25a1/index.htm after examining both files here is what gets changed: "0xE2 0x96 0xA1" becomes "0xD0 0x91 0xE2 0x88 0x9A 0xE2 0x95 0x91" Both files are available for your inspection at: http://www.x96.org/files/hw2.jff http://www.x96.org/files/hw2.jff-corrupted I appreciate your help.
Re: utf8 console font
On Wed, May 07, 2008 at 07:55:43AM -0500, Kyle Wheeler wrote: > On Wednesday, May 7 at 09:29 PM, quoth Chris Bannister: > > Had one, an SE30, based on the 68030, greata machine. Support - > > bloody horrible, unless you had a fat wallet. Backwards > > compatibility - bloody horrible, they make their money from the > > hardware. Frankly, they are just too expensive. > > A basic Mac mini starts at $600, which seems pretty reasonable to me > (similar machines from Dell are $650, but come with a monitor, similar > machines from HP are $550 and don't come with a monitor). Then again, > you *can* get bargain-bin stuff for $350 from Dell. > > To each their own, I suppose. Oh, ok, I'll keep that in mind, thanks. -- Chris. == "One, with God, is always a majority, but many a martyr has been burned at the stake while the votes were being counted." -- Thomas B. Reed
Re: utf8 console font
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, May 7 at 09:29 PM, quoth Chris Bannister: > Had one, an SE30, based on the 68030, greata machine. Support - > bloody horrible, unless you had a fat wallet. Backwards > compatibility - bloody horrible, they make their money from the > hardware. Frankly, they are just too expensive. A basic Mac mini starts at $600, which seems pretty reasonable to me (similar machines from Dell are $650, but come with a monitor, similar machines from HP are $550 and don't come with a monitor). Then again, you *can* get bargain-bin stuff for $350 from Dell. To each their own, I suppose. ~Kyle - -- Habits of thought persist through the centuries; and while a healthy brain may reject the doctrine it no longer believes, it will continue to feel the same sentiments formerly associated with that doctrine. -- Charlotte Perkins Gilman -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkghps8ACgkQBkIOoMqOI15dMQCdEMQA2ZprALm4f/xQ0IGrPReR nQMAoLF2sVBZJLsRfHqO8huh7kKT+dO/ =zQTe -END PGP SIGNATURE-
Re: utf8 console font
On Tue, May 06, 2008 at 12:03:50PM -0500, Kyle Wheeler wrote: > On Tuesday, May 6 at 11:04 PM, quoth Chris Bannister: > >Hi, > > > >Just wondering which console font people are using in an utf8 locale. > > Monaco. The font families were named after cities, yeah now I remember. > Tips? Get a mac. ;) Had one, an SE30, based on the 68030, greata machine. Support - bloody horrible, unless you had a fat wallet. Backwards compatibility - bloody horrible, they make their money from the hardware. Frankly, they are just too expensive. -- Chris. == "One, with God, is always a majority, but many a martyr has been burned at the stake while the votes were being counted." -- Thomas B. Reed
Re: utf8 console font
> > > Just wondering which console font people are using in an utf8 locale. > > > > Terminus > > > > http://www.is-vn.bg/hamster/ > > Yeah, I have heard of it and am installing it now. > > Installed "Uni3-TerminusBold16" and it seems to be displaying more > foreign characters than "chavo", although it does remind of the early > personal computers in the '70s :-), ah nostalgia ... I use fullscreen terminal (no borders around). I think it looks nice :) I installed the same font to my solaris, linux and windows machines. -- Vlad pgpRasSLylYqV.pgp Description: PGP signature
Re: utf8 console font
On Tue, May 06, 2008 at 01:05:05PM +0200, Vladimir Marek wrote: > > Just wondering which console font people are using in an utf8 locale. > > Terminus > > http://www.is-vn.bg/hamster/ Yeah, I have heard of it and am installing it now. Installed "Uni3-TerminusBold16" and it seems to be displaying more foreign characters than "chavo", although it does remind of the early personal computers in the '70s :-), ah nostalgia ... -- Chris. == "One, with God, is always a majority, but many a martyr has been burned at the stake while the votes were being counted." -- Thomas B. Reed
Re: utf8 console font
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday, May 6 at 11:04 PM, quoth Chris Bannister: >Hi, > >Just wondering which console font people are using in an utf8 locale. Monaco. Tips? Get a mac. ;) ~Kyle - -- Come to me, son of Jor-El. Kneel before Zod. Snootchie-bootchies. -- Jay -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkggj3YACgkQBkIOoMqOI15HfgCcCSBwYmz6vG43UOkOWp5LH2+X KBsAoPN+1YaViv67T6HSg3NEFRvRdaB1 =ArGJ -END PGP SIGNATURE-
Re: utf8 console font
On Tue, May 06, 2008 at 11:04:38PM +1200, Chris Bannister wrote:
> Hi,
>
> Just wondering which console font people are using in an utf8 locale.
sigma-general-8x16 ;) [ It's from sigma-consolefonts which is my own
assemblage, derived from etl16, and includes a number of different
maps (the maps decide which characters are available in a particular
psfu font). ]
http://homepage.ntlworld.com/zarniwhoop/consolefonts/sigma.html .
End of blowing my own trumpet. I must remember to update that font
with a few minor fixes.
>
> Any tips?
>
Screen fonts fall into two types - the 'vga' fonts derived from
what you get from the video card (usually very bold), and the others
(often less bold, which might be a problem for some people). You
then have the "256 glyphs and bold colours, or 512 glyphs without the
bold colours" decision. There is also a size consideration (fewer
lines of text, or more lines of text) FWIW, mine is up-to 512 glyphs
and «less bold» with only an 8x16 "cell".
The big question is, which languages do you want to support in the
console ? Most fonts are limited to only a few languages. If you
already have UTF-8 text in all the languages of interest to you, or
you can create some (remember punctuation, quotation marks, currency
symbols as well as the accented letters), then try using the
different fonts ('setfont') to see how well they cope. For
non-ascii text, creating it is usually a lot easier in a graphical
environment.
I assume you already know that only alphabetic languages can be
displayed in the regular linux console.
Of course, there are also visual choices for any font, such as
'what letter form for "g"?', and "how many rows of the character cell
are used for the text?" and even "what do you display when the glyph
isn't available?". Many console fonts use different glyphs for
cyrillic and latin letters (e.g. Aa|Аа B|В and perhaps C|С) which to
me looks strange. There is definitely no "one size fits all".
ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
Re: utf8 console font
> Just wondering which console font people are using in an utf8 locale. Terminus http://www.is-vn.bg/hamster/ -- Vlad pgpDa6DQRfNyM.pgp Description: PGP signature
utf8 console font
Hi, Just wondering which console font people are using in an utf8 locale. Currently I am using chavo less /etc/console-tools/config [..] SCREEN_FONT=chavo That was aquired by "apt-get install fonty-rq" in Debian Etch locale | grep LANG LANG=en_NZ.UTF-8 Any tips? -- Chris. == "One, with God, is always a majority, but many a martyr has been burned at the stake while the votes were being counted." -- Thomas B. Reed
Re: utf8 encoding problem, but which part?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday, October 16 at 09:11 AM, quoth Raphael Brunner: > my problem isn't clear for me, what it is exactly. Nor is it for anyone you're describing it to. > I became a mail from russia with koi8-u encoding (in mailheader). You mean you *received* such an email? > My system is debian stable. In muttrc, I defined 'set > charset=utf-8', It's typically (unless you know what you're doing) better to let mutt detect the charset, so take that out of your muttrc. > the terminal is mlterm (I tried also xterm with the same result) I don't know anything about mlterm, but xterm can't display the full utf-8 character set unless you do to things: first, you must have it using a font that has all the right characters in it, and second, you must run xterm with the correct options (e.g. use the wrapper script `uxterm`). > and locale output (see below) shows good. Now, the mailcontent in > mutt is right, Good. > but if I reply to this (mails open with vim), then there are strange > signs there (but only the not-ascii). Regardless if I set ':set > encoding=utf-8' in vim or not, vim don't show this characters > correct. Firstly, setting the encoding in vim to be utf-8 only changes vim's internal representation of characters, it does NOT change vim's understanding of the file it's editing. Here's a clip from vim's documentation: NOTE: Changing this option will not change the encoding of the existing text in Vim. It may cause non-ASCII text to become invalid. It should normally be kept at its default value, or set when Vim starts up. See |multibyte|. More helpfully: The character encoding of files can be different from 'encoding'. This is specified with 'fileencoding'. The conversion is done with iconv() or as specified with 'charconvert'. Normally 'encoding' will be equal to your current locale. This will be the default if Vim recognizes your environment settings. If 'encoding' is not set to the current locale, 'termencoding' must be set to convert typed and displayed text. See |encoding-table|. So you want to leave 'encoding' alone, and change 'fileencoding'. What you need to do is figure out what character set mutt is saving its temporary files as. I believe (but I haven't checked) that mutt doesn't do any conversion, and saves the temporary files in the same character set as the email. > I tried also emacs, it display exact the same like vim. Probably because it assumed (just like vim) that the text was encoded in either us-ascii or utf-8. Hope that helps, ~Kyle - -- When ideas fail, words come in very handy. -- Johann Wolfgang von Goethe -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFHJd6ABkIOoMqOI14RAp0wAKDdBnu6oDPuR4t2KoJOo7c1Jq8Q7gCgzwNc JbXhVAaXhnOI+mZmbRiQxss= =dfo6 -END PGP SIGNATURE-
utf8 encoding problem, but which part?
hi all my problem isn't clear for me, what it is exactly. I became a mail from russia with koi8-u encoding (in mailheader). My system is debian stable. In muttrc, I defined 'set charset=utf-8', the terminal is mlterm (I tried also xterm with the same result) and locale output (see below) shows good. Now, the mailcontent in mutt is right, but if I reply to this (mails open with vim), then there are strange signs there (but only the not-ascii). Regardless if I set ':set encoding=utf-8' in vim or not, vim don't show this characters correct. I tried also emacs, it display exact the same like vim. Now, I don't know where I should begin to debugging and how. Is this a problem of my system, of my terminal, of mutt or vim? I don't know this. I googled a lot, but because I couldn't define my problem exactly, I search in the darkness. Have you any idea for this? thank you. raphael locale: LANG=de_CH.UTF-8 LANGUAGE=de_CH.UTF-8:de_DE:de:en_GB:en LC_CTYPE="de_CH.UTF-8" LC_NUMERIC="de_CH.UTF-8" LC_TIME="de_CH.UTF-8" LC_COLLATE="de_CH.UTF-8" LC_MONETARY="de_CH.UTF-8" LC_MESSAGES="de_CH.UTF-8" LC_PAPER="de_CH.UTF-8" LC_NAME="de_CH.UTF-8" LC_ADDRESS="de_CH.UTF-8" LC_TELEPHONE="de_CH.UTF-8" LC_MEASUREMENT="de_CH.UTF-8" LC_IDENTIFICATION="de_CH.UTF-8" LC_ALL=
Re: utf8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, September 19 at 03:57 PM, quoth Matthias Apitz: >What would be the best way to make visible mails arriving in my >mail-folder as: > > --=_NextPart_001_2090AD_01C7FA92.54AF4C00 > Content-Type: text/plain; >charset="utf-8" > Content-Disposition: inline > Content-Transfer-Encoding: base64 Hmm, the best way would be to get mutt to decode those. :) I don't know how, though - probably something you need to pester the devel list for. >$ /usr/local/bin/decode-base64 attachment > attachment.ascii > >but I can get 'decode-base64' compiled on FreeBSD 6.2R OpenSSL can also decode base64 stuff: openssl base64 -d < attachment > attachment.ascii ~Kyle - -- If you are going through hell, keep going. -- Winston Churchill -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFG8TChBkIOoMqOI14RAgI+AJ4gDUao/Aga3cXDJa9ZXFUUf46WTwCgvFb7 7GKVmF55l2xPJEub360Gg7E= =JWgg -END PGP SIGNATURE-
utf8
Hello, What would be the best way to make visible mails arriving in my mail-folder as: --=_NextPart_001_2090AD_01C7FA92.54AF4C00 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: base64 V2hlbiByZXBseWluZywgdHlwZSB5b3VyIHRleHQgYWJvdmUgdGhpcyBsaW5lLg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KTm90aWZpY2F0aW9uIG9mIElz c3VlIENoYW5nZQ0KVGhlIGZvbGxvd2luZyBjaGFuZ2VzIGhhdmUgYmVlbiBtYWRlIHRvIHRoaXMg SXNzdWU6IENoYW5nZWQgU3RhdHVzIHRvIEN1c3RvbWVyIFJlc3BvbmRlZCBmcm9tIFBlbmRpbmcs IEFwcGVuZGVkIGEgbmV3IERlc2NyaXB0aW9uLCBJbmNvbWluZyBtYWlsOiBGcm9tOiBtLmFwaXR6 ... In the past I have saved the attachment into a file and unpacked it with $ /usr/local/bin/decode-base64 attachment > attachment.ascii but I can get 'decode-base64' compiled on FreeBSD 6.2R Any idea? Thx matthias -- Matthias Apitz Manager Technical Support - OCLC PICA GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e <[EMAIL PROTECTED]> - w http://www.oclcpica.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ OCLC PICA GmbH, Geschaeftsfuehrer: Christine Magin-Weeger, Norbert Weinberger Sitz der Gesellschaft: Oberhaching, HRB Muenchen: 113261
Re: How to insert utf8 characters in mutt?
Hi! On Thu, Jan 10, 2002 at 03:15:33PM -0500, Walt Mankowski wrote > You could try adding > set edit_headers > to your .muttrc and edit the subject inside vim. Thanks, yes, that is a way, but I thought mutt had its own way for doing this because it handles utf8 very well. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: [EMAIL PROTECTED] | | WWW: http://fsing.fs.uni-sb.de/~stse/| | PGP Public Keys: http://fsing.fs.uni-sb.de/~stse/pgp.html | msg22905/pgp0.pgp Description: PGP signature
Re: How to insert utf8 characters in mutt?
On Thu, Jan 10, 2002 at 04:09:19PM +0100, Stephan Seitz wrote: > I'm using mutt 1.3.25i in an utf8-xterm. Within my editor (vim) I can > insert any utf8 characters with "ctrl-v u ". > But how do I such thing within mutt (e.g. the subject)? You could try adding set edit_headers to your .muttrc and edit the subject inside vim. Walt msg22839/pgp0.pgp Description: PGP signature
How to insert utf8 characters in mutt?
Hi! I'm using mutt 1.3.25i in an utf8-xterm. Within my editor (vim) I can insert any utf8 characters with "ctrl-v u ". But how do I such thing within mutt (e.g. the subject)? Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: [EMAIL PROTECTED] | | WWW: http://fsing.fs.uni-sb.de/~stse/| | PGP Public Keys: http://fsing.fs.uni-sb.de/~stse/pgp.html | msg22780/pgp0.pgp Description: PGP signature
