“ and Internet Explorer (6)

[Swifty]

People insist on examples, so here is my page:
http://swiftys.org.uk/therules.html

A colleague in China is viewing the page using IE6 any my “
characters are coming out as pair of Chinese glyphs, and taking the
following plain ASCII character with them. The rest of the page is
rendered more or less correctly.

I'd always assumed that things like “ would render correctly under
all circumstances, unless the client didn't have the right font to
display them.

Is this more likely a font issue on the target system or an IE6 problem?

We are obliged to stay on IE6 as some of our corporate applications fail
under IE7.

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

[Holger Jeromin]

Swifty schrieb am 29.10.2008 14:28:

People insist on examples, so here is my page:
http://swiftys.org.uk/therules.html

404 - file not found

--
Mit freundlichen Grüßen
Holger Jeromin

[Jukka K. Korpela]

Swifty wrote:

People insist on examples, so here is my page:
http://swiftys.org.uk/therules.html

We'd prefer example rules that result in a 200 OK response. :-)
I guess the correct URL is
http://swiftys.org.uk/rules.html

The encoding of the page is not specified in HTTP headers _or_ in a meta
tag. This means that the client must guess, and different browsers will
guess differently. In China, making a guess on an encoding that is widely
used in China is not a bad idea, but it may break Western pages.

Using View/Encoding on IE 7, I tested the page on four Chinese encodings. In
three cases, I saw some Chinese characters in the midst of English texts; in
the fourth, Big5, the page is differently broken (some characters shown as
bullets). This was more or less to be expected.

A colleague in China is viewing the page using IE6 any my “
characters are coming out as pair of Chinese glyphs, and taking the
following plain ASCII character with them. The rest of the page is
rendered more or less correctly.

This matches my test results and strongly suggests that it is an encoding
problem. The quickest fix is to add
<meta http-equiv="Content-Type" content="text/html;charset=wi ndows-1252">

I'd always assumed that things like &ldquo; would render correctly
under all circumstances, unless the client didn't have the right font
to display them.

More or less so, and the "unless" reservation is rather theoretical. But the
problem is that in the eyes of a browser, or other user agent, your
document's content is unspecified. It is a sequence of bytes (or a sequence
of bits) with no interpretation assigned to them. So why should they think
the document contains characters "&", "l", etc.?

In practice, if your document contained _only_ bytes in the ASCII range,
then the problem probably would not appear, though there is really no
guarantee. Your document contains also curly quotation marks and apostrophes
in windows-1252 (Windows Latin 1) encoding, and since they are outside the
ASCII range, there will be different guesses on what they mean.

Is this more likely a font issue on the target system or an IE6
problem?

Neither.

We are obliged to stay on IE6 as some of our corporate applications
fail under IE7.

Why would that matter to the way you author web pages?

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[Swifty]

Jukka K. Korpela wrote:

In practice, if your document contained _only_ bytes in the ASCII range,
then the problem probably would not appear, though there is really no
guarantee. Your document contains also curly quotation marks and
apostrophes in windows-1252 (Windows Latin 1) encoding, and since they
are outside the ASCII range, there will be different guesses on what
they mean.

How odd. I edited the source (rules.html, not therules.html, but I've
now created a hard link, so the name is optional) and found some weird
left and right double quote ASCII characters (0x93 and 0x94) in there. I
wouldn't know how to put those in there, so how they got there is a
mystery. I've changed them to &ldquo; and &rdquo; and I'll ask my
colleague to try again. I've just remembered that I imported the text of
this page from a Powerpoint document, so that probably that's where the
odd characters came from.

>We are obliged to stay on IE6 as some of our corporate applications
fail under IE7.

Why would that matter to the way you author web pages?

My colleague told me that the page rendered correctly in Firefox, and I
had no idea that I'd somehow managed to get weird characters into my
HTML, so my initial reaction was that it might be an IE6 problem. Had
this been the case, I didn't want people telling us to upgrade to IE7,
as that is not an option at the moment.

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

[Jukka K. Korpela]

Swifty wrote:

How odd. I edited the source (rules.html, not therules.html, but I've
now created a hard link, so the name is optional) and found some weird
left and right double quote ASCII characters (0x93 and 0x94) in
there. I wouldn't know how to put those in there, so how they got
there is a mystery. I've changed them to &ldquo; and &rdquo; and I'll
ask my colleague to try again. I've just remembered that I imported
the text of this page from a Powerpoint document, so that probably
that's where the odd characters came from.

It's actually relatively simple. Powerpoint, like Microsoft Office software
in general, converts ASCII quotation mark ", U+0022, and Ascii apostrophe ',
U+0027, into language-dependent double and single quotation marks. This is
usually a nice feature, provided that the language setting is correct and
that you take some care in using the text in other contexts.

In particular, if you cut and paste data and save it in "ANSI encoding" (a
Microsoft misnomer for different nonstandard 8-bit encodings), such as
windows-1252 in the Western world, as many programs do by default, they will
usually be automatically convented to that encoding. All is well until the
data is sent to some software without telling the encoding. And even then
things might appear to be OK as long as the software then guesses that the
data is windows-1252 encoded (as most web pages without encoding information
probably are).

If you like you can use &ldquo;, but it's really simpler to declare the data
as windows-1252 encoded.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[David E. Ross]

On 10/29/2008 10:20 AM, Swifty wrote [in part]:

>
My colleague told me that the page rendered correctly in Firefox, and I
had no idea that I'd somehow managed to get weird characters into my
HTML, so my initial reaction was that it might be an IE6 problem. Had
this been the case, I didn't want people telling us to upgrade to IE7,
as that is not an option at the moment.

Web pages should be written to be viewed with ALL browsers. This
applies to ALL of your Web pages, not merely the one in question. See
<http://www.anybrowser. org/campaign/index.htmlfor some design
guidelines in this direction.

More important, however, is that the pages use valid HTML or XHTML.
Your cited page (URL as corrected by Jeromin) has only 4 HTML errors,
much fewer than I usually see when someone has a problem like yours.
Fix those errors and see if that helps resolve your problem.

Firefox might have rendered the page correctly, but that was pure luck.
For whatever afflicts your page, the guess coded into Firefox was
fortuitous for you; and the guess coded into IE was not. In other
cases, IE guesses correctly; but Firefox does not. If there are no HTML
or XHTML errors, there is no guessing.

As for your assertion that "We are obliged to stay on IE6", you have
tied yourself to a falling star. By various measurements, the share of
the browser market held by all versions of IE (including both 6 and 7)
has fallen steadily over the past five years. In 2003, IE might have
held as much as 88% of the market. As of this fall, it holds between
49% and 57%. See my <http://www.rossde.com/internet/browsers.html>.

--

David E. Ross
<http://www.rossde.com/>

Q: What's a President Bush cocktail?
A: Business on the rocks.

[Ben C]

On 2008-10-29, David E. Ross <no****@nowhere .notwrote:

On 10/29/2008 10:20 AM, Swifty wrote [in part]:

>>
My colleague told me that the page rendered correctly in Firefox, and I
had no idea that I'd somehow managed to get weird characters into my
HTML, so my initial reaction was that it might be an IE6 problem. Had
this been the case, I didn't want people telling us to upgrade to IE7,
as that is not an option at the moment.

Web pages should be written to be viewed with ALL browsers. This
applies to ALL of your Web pages, not merely the one in question. See
<http://www.anybrowser. org/campaign/index.htmlfor some design
guidelines in this direction.

More important, however, is that the pages use valid HTML or XHTML.
Your cited page (URL as corrected by Jeromin) has only 4 HTML errors,
much fewer than I usually see when someone has a problem like yours.
Fix those errors and see if that helps resolve your problem.

Firefox might have rendered the page correctly, but that was pure luck.
For whatever afflicts your page, the guess coded into Firefox was
fortuitous for you; and the guess coded into IE was not. In other
cases, IE guesses correctly; but Firefox does not. If there are no HTML
or XHTML errors, there is no guessing.

There still may be plenty of guessing: the W3C specifications don't
define everything and some things they leave explicitly undefined.
Sometimes they even say the browser is free to make a guess.

But yes, getting rid of all the errors certainly helps a lot and is the
first thing to do.

[Andy Dingley]

On 29 Oct, 18:20, Swifty <steve.j.sw...@ gmail.comwrote:

I've changed them to &ldquo; and &rdquo; and I'll ask my
colleague to try again.

So did your colleague (as your original post suggests) try a document
with these _as_entity_refe rences_ and have a problem, or were they
coded as literal characters at the time they reported the problem?

[Swifty]

Andy Dingley wrote:

So did your colleague (as your original post suggests) try a document
with these _as_entity_refe rences_ and have a problem, or were they
coded as literal characters at the time they reported the problem?

At the time the problem was initially reported (both *to* me, and *by*
me, here) there were 0x92,0x93 and 0x94 hex values in my HTML, imported
by cut'n'paste from Powerpoint. All I did was add sufficient HTML to get
the formatting roughly right, and I didn't notice the "odd" characters
as *my* browser rendered them correctly.

Then my Chinese colleague reported a formatting problem (in case you're
wondering why I should be discussing the content of that page in a work
context, it is because I give lessons in spoken English, so it doesn't
matter *what* we talk about, as long as it is "interestin g" English, and
we'd wandered onto the topic of asking if we are fat, see the 11th rule)
and Jukka was kind enough to point out that my page contained characters
outside the allowed range (my words). I fixed the >0x7f characters,
using entity references where necessary, and my page now formats
perfectly. This may be a strange new use of the word "perfectly" that
you hadn't come across before.

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

[David Stone]

In article <09************ *************** ***@brightview. com>,
Swifty <st***********@ gmail.comwrote:

>
Andy Dingley wrote:

So did your colleague (as your original post suggests) try a document
with these _as_entity_refe rences_ and have a problem, or were they
coded as literal characters at the time they reported the problem?

At the time the problem was initially reported (both *to* me, and *by*
me, here) there were 0x92,0x93 and 0x94 hex values in my HTML, imported
by cut'n'paste from Powerpoint. All I did was add sufficient HTML to get
the formatting roughly right, and I didn't notice the "odd" characters
as *my* browser rendered them correctly.

Oddly enough, I experienced a similar problem just today when pasting
some text from a Word document into the "notes" area of a PowerPoint
slide. My version of Word has smart quotes enabled, and the pasted
text included both left and right double quotes. Once in PowerPoint,
I was intrigued to see that the left double quote and first character
immediately following were transformed into a Chinese character, while
the trailing double quote was converted to the "undefined character"
for the font face in use.

In short, beware of "smart quotes" when cutting/pasting!