DIMP message display not formatted

When viewing normal plain text messages in the DIMP mode, th

Tue, 30 Mar 2010 08:32:22 +0000

When viewing normal plain text messages in the DIMP mode, there are no line breaks, so the text all runs together and is very difficult to read. In the traditional IMP mode, the message body text is displayed inside a '

' and newlines are converted to '
' but neither is true in DIMP mode.

Definitely don't see this.

Tue, 30 Mar 2010 18:26:25 +0000

Definitely don't see this.

> Definitely don't see this. Here's what I'm seeing.

Tue, 30 Mar 2010 19:27:30 +0000

> Definitely don't see this. Here's what I'm seeing.

> Definitely don't see this. For comparison, here's the s

Tue, 30 Mar 2010 19:30:28 +0000

> Definitely don't see this. For comparison, here's the same message in normal IMP mode.

Well, to begin with, you absolutely can NOT use DIMP on a

Tue, 30 Mar 2010 19:51:33 +0000

Well, to begin with, you absolutely can *NOT* use DIMP on a non-UTF-8 browser. So the real ticket should be denying you access totally to dimp on that browser.

This message probably comes from the server not supporting U

Tue, 30 Mar 2010 21:34:52 +0000

This message probably comes from the server not supporting UTF-8, rather than the browser. You still should fix this, because Horde 4 will *require* UTF-8 support for both browser and server.

> Well, to begin with, you absolutely can NOT use DIMP on

Wed, 31 Mar 2010 03:06:37 +0000

> Well, to begin with, you absolutely can *NOT* use DIMP on a non-UTF-8 > browser. So the real ticket should be denying you access totally to > dimp on that browser. I'm pretty sure that Firefox 3.6.3pre and Google Chrome 5.0.342.7 beta can handle UTF-8. I have been wondering what IMP means by "This message was written in a character set (UTF-8) other than your own."

> This message probably comes from the server not supporting

Wed, 31 Mar 2010 03:32:53 +0000

> This message probably comes from the server not supporting UTF-8, > rather than the browser. You still should fix this, because Horde 4 > will *require* UTF-8 support for both browser and server. What component exactly are you referring to? I am using Apache httpd 2.2.9 and have been serving UTF-8 documents for years. Do you mean there has to be UTF-8 support in PHP? I am using mod_php 5.2.6; is there something else I need? I've never had any trouble related to a lack of UTF-8 support before in many other PHP web applications. When displaying some messages, IMP puts "This message was written in a character set (UTF-8) other than your own." in a box above the message. I can view those exact same messages (served from the same IMAP server on the same host) using Roundcube (running on the exact same instance of Apache and PHP) with no issues at all and Firefox reports the encoding of the document is UTF-8.

> Well, to begin with, you absolutely can NOT use DIMP on

Wed, 31 Mar 2010 03:38:04 +0000

> Well, to begin with, you absolutely can *NOT* use DIMP on a non-UTF-8 > browser. So the real ticket should be denying you access totally to > dimp on that browser. Wherever the message encoding issues are coming from, I doubt they have much to do with the formatting problems I've described, since the latter resulted from missing HTML markup, not encoding or decoding errors. However, to muddy things even more, I can no longer reproduce the formatting problem. For a couple of days, I could consistently reproduce the problem in DIMP mode only, but now both regular and dynamic views seem to be displaying messages correctly. I'm starting to suspect this is the result of a cache inconsistency, but that's really just a wild guess.

> What component exactly are you referring to? I am using Ap

Wed, 31 Mar 2010 08:09:12 +0000

> What component exactly are you referring to? I am using Apache httpd Your system locales.

>> What component exactly are you referring to? I am using A

Thu, 01 Apr 2010 05:20:36 +0000

>> What component exactly are you referring to? I am using Apache httpd > > Your system locales. OK, thanks. I didin't realize Horde or IMP (or PHP) relied on system locales, especially since I hadn't had trouble with UTF-8 output before. I also hadn't realized that I didn't have any UTF-8 locales installed. As soon as I installed en_US.utf8, I didn't get the encoding warning from IMP any more.