RTim -

In my IE browser, quite a few of your individual characters "fail" and display as inappropriate glyphs. It seems to be a characteristic of Macs, if you paste directly from Word, since you and Amos are about the only ones where I consistently see this behavio(u)r.

Mac "punctuations" and some "formats" often are handled differently than in Windows, even if both are using Word. (And believe me, it drives the page layout people bonkers in the book publishing business, especially when a MAC writer tries to be "helpful" and apply "formatting" to text instead of leaving it up to the book layout people.)

In your post above, all of the apostrophes (') display as upper case O-tildes for me. Copying them to my Word, and using the Word "Unicode detector" shows the errant characters as actually being, in the page code, hex U-00D5 (decimal 0213) which actually is an Õ according to common Unicode font tables.

Assuming that "following Stilly's instructions" means you were typing <P> to start a paragraph, and </P> to end one, if you right click on the page and choose "View code" (works in IE and should in any browser?) I find one of your "paragraph breaks" consisting of:

"<br>&#13;&#10;<P>&#13;&#10;&#9;"

The <br> alone will produce the line break that you want.

The &#13;&#10;< is approximately a line feed + return, which is redundant and may or may not be ignored by browsers, and probably means you hit an Enter/Return or whatever it's called on a Mac.

The <P> is a "new paragraph" in html,

followed by another line feed+return and an apparently extraneous "number nine" character - (&#13;&#10;&#9;)

[vague memory is that the char with decimal value 009 is a tab, which html ignores completely.]

The <P> tag does produce a new paragraph and is consistent so far as I know. The problem is that each <P> in principle should be followed by a </P> or the html parser (the one in your browser and sometimes the one at mudcat) gets jammed up. Some browsers (actually most reasonably current ones) allow you to omit the "closing" </P> (except for the last one) and most should handle missing ones okay, since the standard is "soft" on whether closing the paragraph tag is required; but a few browsers, especially older ones, may perform unpredictably.

The simpler <br> is one of extremely few html tags that does not ever require that the tag be closed hence less danger of mangled posts.

If you compose in Word, when you're happy with what it looks like, open Find and Replace and "find" ^p and "replace with" <br> using replace all. The mess that you get will be all one line, but when posted, run through the mudcat sorter, and then back through the viewers' browsers it should look just like what you typed to begin with.

Mudcat, and most browsers, should recognize the ¶ paragraph break in Word when you past from Word to the input, but sometimes the first one is ignored and it takes two to get a break.

Explanation: ANSI 0010 + ANSI 0013 is the correct pair of control characters to get both a drop down to the next line and a return to the start of the new line. It isn't supposed to make a difference which order the two chars appear, but for some programs - including some browsers - it does. HTML deliberately "ignores anything it doesn't understand;" but if it ignores the first one, the opposite sequence is "embedded" in the "set of four" chars it sees when two ¶ chars are adjacent (10 13 10 13 contains a 13 10 in the middle and 13 10 13 10 contains a 10 13 pair in the middle).

There's sort of an explanation for the weird tilde chars from Macs, I think, but it's not brief like the above.

John