Thanks very much for the explanation, David. It helps quite a lot to understand more about Pegasus' HTML technology (much more complex than I would have imagined!) - and also to know that my OS isn't screwed up somehow.

So how safe would it be to assume that a forwarded HTML section - with "Edit or make changes..." - will probably be seen by the recipient as it originally appeared in the reader window, even if it looks screwy in the compose window? At least in my experiment today, it did work out that way.

Dave

Being a newbie to this forum, I have to get this little intro out of the way first:  I've been a devoted (addicted?) user of Pegasus since 1997, and would like to take this opportunity to sincerely thank David Harris for this wonderful product and for all the vast amount of work that he has put into it throughout these years.  

Now for my tech question... I just received an HTML message containing a table with 6 cells (2 across, 3 down),

each cell containing one animated GIF with a caption.

All 6 GIFS were attachments (not "lazy HTML"). This message displayed perfectly in my Pegasus 4.41 READER

window.

However, when I clicked to forward this message with "edit and

make changes," the table in the message composing window now appeared much too narrow for the GIFs and the animations were

running much, much faster than the originals. By the way, I had unchecked "Word-wrap long lines" in the forwarding options.

I decided to go ahead and forward this "messed up" version to my

Yahoo e-mail, just to see what would happen.

And strangely enough, opening up this message in Yahoo, the table was back to its correct dimensions and all

the GIFs were running at their correct speed!

What might be going on to make the HTML in the Pegasus compose window appear so "messed up" when in fact it sends the original message correctly formatted?

Thanks!

Dave
University of Arkansas

Pegasus Mail uses two different technologies to handle HTML. To display messages, it uses BearHTML, a module developed by Martin Ireland (one of my beta testers and a regular contributor here) based on an extremely good HTML rendering technology by a man called Dave Baldwin (http://www.pbear.com). It's very robust and does an extremely good job of handling the wide range of HTML rubbish floating around on the net (as best I can tell, only about 1 message in 80 is actually fully compliant with the W3C standards for HTML).  To edit messages, however, it uses a proprietary editing module called TER which we licensed a number of years back. TER is an extremely good richtext editor, but it knows nothing about HTML; instead, to edit HTML, we have to pass it through a conversion modulecalled HTS, licensed from the same developer. Unfortunately, HTS is not a very good product. If you present it with completely correct HTML it will usually do a reasonably good job of rendering it, but it copes very poorly with anything unexpected. In earlier times, it had a tendency to crash when presented with malformed HTML, which was a real problem, but these days at least there are mechanisms in place to handle problems more seamlessly, so the crashing at least is not the issue it once was.

The nett effect of this is that you may well be able to read a message and have it look quite normal, but have the reply look strange or not even appear at all, because the two different technologies react in different ways to the HTML content.

Unfortunately, unless I can find a much better HTML<-->RTF translator/converter, or a complete replacement for TER (and I don't believe one exists - TER is very comprehensive and effective, regardless of the negative opinions of certain naysayers out there who fail to appreciate all the things it CAN do and concentrate on a relatively small range of things that it does less well), I can't do very much about this, sorry.

Cheers!

-- David --