[Alpine-info] text/html display does not respect wrap column
Benjamin R. Haskell
alpine at benizi.com
Mon Feb 4 20:51:27 PST 2008
On Mon, 4 Feb 2008, Eduardo Chappa wrote:
> On Mon, 4 Feb 2008, Benjamin R. Haskell wrote:
> :) The text/plain portion seems to be using format=flowed (even though
> :) it's not listed in the Content-Type header). So it makes sense that it
> :) would repect viewer-margin.
> :) But, on my machine it appears that the text/html part simply isn't
> :) wrapping at all, except to prevent text being displayed off-screen.
> Text/html displays as flowed text. You create a new line by using a <BR>
Oops. Indeed, that's what's happening.
Example input, with newlines at each line ending:
(For HTML, pretend it's the same, but appropriately marked-up:
1) This is some text with many short
2) words that will wrap in some way,
3) but I do not know what way that is.
flowed: |<- margin
1) This is some text with
2) many short words that
3) will wrap in some way,
4) but I do not know what
5) way that is.
wrapped |<- margin
1) This is some text with
2) many short
3) words that will wrap in
4) some way,
5) but I do not know what
6) way that is.
Currently, I'm seeing text/plain = wrapped, text/html = flowed. I thought
you were complaining of the opposite (plain = flowed, html = wrapped).
But, isn't this just an artifact of how format=flowed works? In text/html,
apparently, lines are split on <br/>'s (and probably others?), rather than
message lines, and it flows by default. In text/plain, they're message
lines, and it won't flow without explicit "permission" (;format=flowed).
If a line ends without a trailing space, the next line shouldn't be
What do you want/expect to happen?
> :) Given the complexities involved in rendering HTML, that seems like a
> :) fine compromise.
> Depends on who you are. Some people think that givng approximate sizes in
> IMAP is wrong (and with a good reason), some others think that wrapping
> text not respecting the viewer margin is a bug...
Giving approximate sizes is a matter of technical correctness. In the case
of dealing with potentially(/usually)-malformed HTML in a medium
consisting of a fixed grid of monospaced text with about 16 colors, I
don't think it's possible to achieve anything resembling the HTML(+/CSS)
author's original intent. So, that's not at all a fair comparison. (The
software *can* get the sizes right, but the HTML is a lost cause, IMO.)
Nonetheless, I think we'd still disagree, so I'll drop my case. Besides,
alpine did better than I thought it would/should.
More information about the Alpine-info