Backslash ( \ ) in ordinary text

[James Dow Allen]

I have a website that uses only very simple html, for example
http://fabpedigree.com/s061/f004932.htm

As you can see, I use backslashes as a very primitive way
to develop diagonal lines. I've had these pages online for
several years with no problems.

Yesterday I get a report that the backslashes are displaying
as struck-out W's! The user had just reverted from
Windows XP to Windows 7 and is browsing with IE I think.

I've come across some mention of Windows Word mapping
backslash to struck-out W, but don't understand it.
And it shouldn't apply to webpages, right?

I hope someone can figure out what's happening and explain it to me!
Am I supposed to use an &-code for backslash?

James Dow Allen

 

[Jukka K. Korpela]

No, you don't need to use an entity reference for backslashes.

Right, "\" is just another data character in HTML. In software that
_generates_ HTML, e.g. a Perl or JavaScript program, things are different,
but that's a whole another world. Wait a sec... we have a web page about it,
don't I.... yes:
http://www.cs.tut.fi/~jkorpela/www/revsol.html

That said, I see the same thing on your page,

I can confirm that too: on the page
http://fabpedigree.com/s061/f004932.htm
I see backslashes as struck-out "W" on IE 8 (Windows Vista).

and found other pages
for which back slashes are correctly displayed. It's worth noting that
those sites used valid HTML and "standards mode" rendering. Your page
lacks a doctype declaration, so it triggers "quirks mode," and has a
few HTML errors as well.

Good guess, and the HTML errors should be fixed of course, but neither the
markup errors nor "quirks mode" seem to affect the issue.

The issue is that some versions of IE apparently display "\" in that very
odd way, when font-family: serif is specified in CSS. That's weird, even for
IE.

It's really a font issue, as you can see if you copy and paste the text into
a text editor for example: there you see the fancy character turned into
"\".

I don't know which font it uses when font-family: serif is specified, but
it's apparently a broken font, with a completely wrong glyph for "\". This
is mad, but it can easily be fixed by changing the CSS rule.

Wait... we have
http://www.fileformat.info/info/unicode/font/fontlist.htm
and using it, one can see that the following fonts on my computer have a
struck-out "W" in place of "\":
Batang
BatangChe
Gulim
GulimChe
Gungsuh
GungsuhChe
Malgun Gothic
And I'm pretty sure those fonts came with the operating system. For more
weirdness, but more undertandably (though not acceptably), some fonts
display "\" as the yen symbol - this is understandable because some Asian
variants of Ascii have replaced "\" by the yen sign. Wait... the struck-out
"W" is the wong symbol, _of course_. So this is not completely absurd, just
mind-boggingly wrong, a return to the world where monsters called "national
variants of Ascii" ruled the Earth.

So probably serif means, to IE, one of those broken fonts. (Broken at least
in the sense of rendering one character completely wrong.) And this explains
why the issue may arise in Word, too - if the font somehow gets changed to
Batang, for example.

Specifying serif means in theory that the browser should use the serif font
chosen by the user (either by accepting the browser default for it or by
setting it), but this doesn't really work. One reason to that is that IE has
no tools for setting the meaning of the keyword serif.

Using e.g. font-family: xxx, "Times Roman", "Times New Roman" where xxx is
the serif font that you really prefer would be better. Virtually any browser
that supports multiple fonts at all can use Times New Roman or Times Roman,
which can hardly be worse than the meaning of the keyword serif when it has
oddities like this. And, of course, you can leave the font unspecified,
which normally means Times New Roman, or something that the user has
selected.

I don't think the use of "\" in the construction of "Ascii graphic" is
particularly advanced, but the late Bob Bemer, the inventor of the
backslash, probably wouldn't object to it. After all, part of the motivation
for this character was to make it possible to write the symbols for logical
disjunction and logical conjunction, as defined in the Algol programming
language, as pairs of Ascii characters: \/ and /\. So the particular visual
appearance was more or less part of the idea.

 

[BootNic]

I have a website that uses only very simple html, for example
http://fabpedigree.com/s061/f004932.htm

As you can see, I use backslashes as a very primitive way to
develop diagonal lines. I've had these pages online for several
years with no problems.

Yesterday I get a report that the backslashes are displaying as
struck-out W's! The user had just reverted from Windows XP to
Windows 7 and is browsing with IE I think.

I've come across some mention of Windows Word mapping backslash
to struck-out W, but don't understand it. And it shouldn't apply
to webpages, right?

I hope someone can figure out what's happening and explain it to
me! Am I supposed to use an &-code for backslash?

This would be a CSS issue. The generic font-family serif, on two different
Vista IE 8 displays as described, winxp displays as a backslash.

Some browsers allow the user to change/select what the generic fonts are, as
far as I know IE does not provide such a thing.

Removing the font-family suggestions should resolve the issue.


--
BootNic Wed Aug 18, 2010 01:16 pm
The only thing that saves us from the bureaucracy is inefficiency. An
efficient bureaucracy is the greatest threat to liberty.
*Eugene McCarthy*

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkxsFVcACgkQmo2774GZ7qk9eACg49yCfBMQKqlhNyrNRCfmBAO3
8SEAn3yvN6Py5QjSe3+Mwe2crkGe47yj
=sFIk
-----END PGP SIGNATURE-----

 

[James Dow Allen]

Thank you very much to all responders!
This seems like a friendly group!

I can confirm that too: on the page
http://fabpedigree.com/s061/f004932.htm
I see backslashes as struck-out "W" on IE 8 (Windows Vista).

Using e.g. font-family: xxx, "Times Roman", "Times New Roman" where xxx is
the serif font that you really prefer would be better.

I've just now modifed the "qstyle.css" as you suggested.
(But omitted the "xxx," as I don't have any particular preference.)

Perhaps kind readers will click again and verify problem
has gone away. And -- displaying my ignorance again -- what
exactly is needed to clear any cache?

I'll add the Doctype to every page next time I rebuild the website.
The only other errors reported by the HTML validator were
missing </small> after <small>, which I omitted deliberately
to save space: the <small> within <td> ... <td> is cancelled
by the end of the <td> region, or at least that's what I've
observed. Am I wrong again?

James Dow Allen

 

[Jukka K. Korpela]

Thank you very much to all responders!
This seems like a friendly group!

We are, at times... but beware of the Dark Side of alt.html!

I've just now modifed the "qstyle.css" as you suggested.
(But omitted the "xxx," as I don't have any particular preference.)

Perhaps kind readers will click again and verify problem
has gone away.

Strangely, it hasn't. The page
http://fabpedigree.com/s061/f004932.htm
refers to "../qstyle.css", i.e.
http://fabpedigree.com/qstyle.css
(I admit that I accidentally tried http://fabpedigree.com/s061/qstyle.css
first - and saw the funniest 404 error pages ever, though I'd hesitate to
use such a page on a business site!)
which contains
td {font-family: serif; font-size: large}
and comes with HTTP headers saying
Last-Modified: Tue, 29 Sep 2009 13:36:30 GMT

And -- displaying my ignorance again -- what
exactly is needed to clear any cache?

Beats me! But this does not seem to be any normal cache issue. Even when I
access the CSS resource on a browser that has never been used to retrieve it
before, I get the version with font-family: serif. I think this is something
between your authoring software and the server.

The only other errors reported by the HTML validator were
missing </small> after <small>, which I omitted deliberately
to save space: the <small> within <td> ... <td> is cancelled
by the end of the <td> region, or at least that's what I've
observed. Am I wrong again?

In practice browsers tend to imply a closing tag for any open text-level
element when they encounter </td>. But it's still wrong, and I would not
count on it. Saving a few characters is really immaterial. The load time of
web pages is dominated by the size of images, bulky script codes, or
sometimes very verbose CSS or HTML markup, but closing tags aren't really
that verbose. And you would probably save more by using CSS for all
rendering issues than by leaving elements unclosed.

By the way, it seems that Batang is the font that (some versions of) IE use
as the font corresponding to the CSS keyword serif and that the only Ascii
character that it gets wrong is the backslash "\". Batang has been designed
especially for the Korean language, and this explains why "\" has been
replaced by the won symbol, the symbol for the monetary unit of South Korea
(looking like overstruck "W") - but it's still all wrong, since the won
symbol has a code position of its own and should appear there, in any font
that wants to support it. - And encoding "\" as "&#92,", though permitted in
HTML, is useless, since the problem does not depend on the representation of
the character in HTML source but in rendering, in some fonts.

 

[dorayme]

<[email protected]

,

Thank you very much to all responders!
This seems like a friendly group!

Nevertheless, stay on guard pal, there are a couple of
techniques, sometimes folk are immediately torn apart like they
are a lone monkey walking into a rival group. Sometimes they are
lured in and thrown some juicy morsels to fatten them up for
later... <g>

 

[dorayme]

<[email protected]

,

Thank you very much to all responders!
This seems like a friendly group!



I've just now modifed the "qstyle.css" as you suggested.
(But omitted the "xxx," as I don't have any particular preference.)

Just in case someone does not have the font you suggest in the
modification, and just in case their browser implements the
offending serif fonts for your diagonal lines, you could

<span class="lines">\</span>
<span class="lines">|</span>

and choose a sans-serif. Or, for that matter, be daring and do
the unusual:

..lines {font-family: "Times Roman", "Times New Roman,
sans-serif;"}

Perhaps kind readers will click again and verify problem
has gone away. And -- displaying my ignorance again -- what
exactly is needed to clear any cache?

If there is a problem, consider the above suggestion.

I'll add the Doctype to every page next time I rebuild the website.

Don't wait, I can't think of a more deserving site (that is a
compliment to you btw) than yours for a doctype. You can do all
this stuff automatically, both the suggestion above to deck out
your lines in classed spans and sticking in a doctype, you might
probably best use for now:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

(right at the top)

by using a good editor's *Search and Replace* function (mine, for
example, can replace instances of anything or add anything
anywhere over a whole folder, yours might be able to do this
too).

The only other errors reported by the HTML validator were
missing </small> after <small>, which I omitted deliberately
to save space: the <small> within <td> ... <td> is cancelled
by the end of the <td> region, or at least that's what I've
observed. Am I wrong again?

Best to mark the end of the element with </small>. If space
saving is the game, you *could* close the smalls and leave off
all the considerable number of </td>s. But I would not do either.

If you are interested in saving space and gaining elegance in
markup, maybe utilise more CSS. You will eventually give up stuff
like

<font color="#68ECFC"><strong>&amp;</strong></font>

for something like

<strong>&amp;</strong>

and have a CSS rule like

strong {color: #68ECFC; background: #fff;}

or, if not all strong things are this colour:

<strong class="class">&amp;</strong>

strong.class {color: #68ECFC; background: #fff;}

Just a taste of the delights awaiting you.

 

[Neredbojias]

Thank you very much to all responders!
This seems like a friendly group!



I've just now modifed the "qstyle.css" as you suggested.
(But omitted the "xxx," as I don't have any particular preference.)

Perhaps kind readers will click again and verify problem
has gone away.

Hmm, I checked last night and got the w-thingy in ie8. Now I don't get
it. Yet another replier known for his persnicketiness states that he
does still get it. That's a mystery to me.

 

[James Dow Allen]

Ouch! I think I changed the wrong element in the .css file;
I hope it works now.

<Excuse follows> I'm fairly competent with simple Linux tools,
but no good on Windows. My only Internet connection
is via Windows. Usually I reboot into Linux
to do anything, but with only one computer this is a big
slow-down during "emergencies." Thus, in a hurry, I
edited the .css file using "Notepad". Lack of carriage-returns
in my files made that difficult for me (especially since I'm
frazzled with unrelated virus problem). :-(
</Excuse>

We are, at times... but beware of the Dark Side of alt.html!

(I admit that I accidentally tried http://fabpedigree.com/s061/qstyle.css
first - and saw the funniest 404 error pages ever, though I'd hesitate to
use such a page on a business site!)

I was going to apologize for wasting everyone's time, but
maybe my 404 page will pay the admission charge for me!

Saving a few characters is really immaterial.

I make an exact copy of the website available on 700 MB CD-Rom,
and am at that 700 MB limit now, making minor reductions as the
database
continues to grow so it will still fit. I've not tried to add up what
all the </td>'s and </small>'s are, but think it's in the MEGABYTES!
(Rather than upgrading to larger-capacity CD, I wonder if distributing
via Flashdrive makes sense??

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

I'll use that line exactly. (One reason I didn't add Doctype before
is
that the examples I saw were more complicated and inexplicable
to me in my ignorance.)

If you are interested in saving space and gaining elegance in
markup, maybe utilise more CSS. You will eventually give up stuff
like
<font color="#68ECFC"><strong>&amp;</strong></font>
for something like
<strong>&amp;</strong>
strong {color: #68ECFC; background: #fff;}

I'll look into this!

Just a taste of the delights awaiting you.

Oh, you sweet-mouth, you!

James

 

[Harlan Messinger]

I don't think the use of "\" in the construction of "Ascii graphic" is
particularly advanced, but the late Bob Bemer, the inventor of the
backslash, probably wouldn't object to it. After all, part of the
motivation for this character was to make it possible to write the
symbols for logical disjunction and logical conjunction, as defined in
the Algol programming language, as pairs of Ascii characters: \/ and /\.
So the particular visual appearance was more or less part of the idea.

SERIOUSLY? I'd always wondered how the damn thing had gotten introduced.
Not quite as creative as the APL symbol set, though.

 

[Jukka K. Korpela]

Ouch! I think I changed the wrong element in the .css file;
I hope it works now.

Yep, http://fabpedigree.com/s061/f004932.htm now shows "\" OK on my IE 8.

 

[Jukka K. Korpela]

SERIOUSLY?

Yes, seriously, see
http://www.cs.tut.fi/~jkorpela/latin1/ascii-hist.html#5C

Some fonts still have "/" and "\" designed so that when they occur in
succession, in either order, they form a continuous symbol. See
http://www.cs.tut.fi/cgi-bin/run/~jkorpela/string.cgi?code=/\
This might be partly a coincidence, because a very simple design creates
that phenomenon.

Of course, if someone really need logical disjunction or conjunction symbol
these days, he should consider using U+2228 LOGICAL OR and U+2227 LOGICAL
AND, even though this implies some need for font considerations.