[Alpine-info] text/html display does not respect wrap column

[Benjamin R. Haskell]

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>

> tag.

>


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: 
html-body-input-/body-/html)

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 
combined.

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.

Best,
Ben