"Registered" symbol is entered in my html file either as ® or as ®
It is appearing pretty well as ® when I drag that file and drop in
browser, anyone.
but when I upload that file to the site, it is displayed as ? or � in
ff3, ie6, safari3.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
browsers indeed show utf-8 as encoding.
When I change the encoding of the browser displayed page to something
else, Windows European, etc. it starts getting shown correctly.
What gives?
When HTML ruled that ® shalt be displayedth as ®, why are you all
browsers ganging against me to not follow that?
--
V
Basic cause is the Fonts used to display the content. Modern UNCODE encoded
fonts have multiple character sets, formerly called "Code Pages". Some
fonts do not have valid Character maps for the UTF-8 encoding, so the
Unknown character '?' is substituted in the display. So basicaly if the Web
page declares the UTF-8 encoding as You have cited, browsers will honor
that, and will use any font-family declarations in Your CSS <style> tags,
even if they do not have an internal UTF-8 character map.
--
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported Major Error used BSOD to msg the enemy!
> but when I upload that file to the site, it is displayed as ? or � in
> ff3, ie6, safari3.
It's not a problem with the browser, but when I try to look at the page
where ® won't display, I find I have no URL for it.
> Basic cause is the Fonts used to display the content. Modern UNCODE
> encoded fonts have multiple character sets, formerly called "Code
> Pages". Some fonts do not have valid Character maps for the UTF-8
> encoding, so the Unknown character '?' is substituted in the display.
> So basicaly if the Web page declares the UTF-8 encoding as You have
> cited, browsers will honor that, and will use any font-family
> declarations in Your CSS <style> tags, even if they do not have an
> internal UTF-8 character map.
With Firefox, that shouldn't happen. If the specified font has no
glyph for a character, Fx should use a glyph from another font.
If Fx can't find a font which supports a valid unicode character, it
displays the character's hex code in a little box.
If Fx encounters an invalid character, it displays the replacement
character �.
AFAICT, when a font without Unicode mappings is specified for a UTF-8
html document, Fx just ignores the font specification.
Is this true also for the Gecko 1.8.1.* branch? I see many Undefined
characters � and other character errors at www.time.com the online version
of Time Magazine.
> »Q« on 9/8/2008 6:41 PM, keyboarded a reply:
> > On Mon, 08 Sep 2008 17:12:49 -0400
> > "Ron K." <kil...@gisco.net> wrote:
> >
> >> Basic cause is the Fonts used to display the content. Modern UNCODE
> >> encoded fonts have multiple character sets, formerly called "Code
> >> Pages". Some fonts do not have valid Character maps for the UTF-8
> >> encoding, so the Unknown character '?' is substituted in the
> >> display. So basicaly if the Web page declares the UTF-8 encoding
> >> as You have cited, browsers will honor that, and will use any
> >> font-family declarations in Your CSS <style> tags, even if they do
> >> not have an internal UTF-8 character map.
> >
> > With Firefox, that shouldn't happen. If the specified font has no
> > glyph for a character, Fx should use a glyph from another font.
> >
> > If Fx can't find a font which supports a valid unicode character, it
> > displays the character's hex code in a little box.
> >
> > If Fx encounters an invalid character, it displays the replacement
> > character �.
> >
> > AFAICT, when a font without Unicode mappings is specified for a
> > UTF-8 html document, Fx just ignores the font specification.
>
> Is this true also for the Gecko 1.8.1.* branch? I see many Undefined
> characters � and other character errors at www.time.com the online
> version of Time Magazine.
The first part, using a different font if the specified one doesn't
have a glyph for the character, goes back at least to Mozilla 1.0. I
remember this because people used to use the character p along with the
(non-Unicode) font "symbol" to make a pi character. That worked with
old IEs and Netscapes, but not with Moz 1.0 -- it would just find
another font to display the p.
The rest of it, I'm not sure. I think Windows versions of Gecko
1.8.1.* browsers may not have the little boxes, so they use � whenever
they can't find a suitable glyph.
Looking at the source for a few time.com pages, nothing jumps out at me,
but I don't have a 1.8.x browser.
I am not seeing any oddities at Time today. They do have a history of
having lots of CSS errors listed in the Console though. Some of those
errors are just plain stupid, ie. misspellings, missing punctuation, and
wrong syntax. By Fx standards Time is a "Broken Web Site".
--
There are three kinds of people -- those that can count and those that
can't.
> Not really a ff3 problem because, ie6 and safari 3.1.2 also show problem.
>
> "Registered" symbol is entered in my html file either as ® or as ®
>
> It is appearing pretty well as ® when I drag that file and drop in
> browser, anyone.
>
> but when I upload that file to the site, it is displayed as ? or � in
> ff3, ie6, safari3.
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
> <meta http-equiv="content-type" content="text/html; charset=utf-8">
>
> browsers indeed show utf-8 as encoding.
1. Check what the HTTP response headers say.
2. Post a URL.
--
Cheers
Ralph
Oh, that could be the cause.
I have used "font-family: times, serif".
I am on pc ff3 and my client whose website I am working on is at mac
safari. So, I thought to use these, instead of Windows proprietary fonts
that might not be usable on mac.
Any PC+MAC veteran here? Which font-family would work identically on both?
--
btw, a hit on the google said that it is possible that my server's
storage/ display mechanism is causing this problem. Maybe, the server is
not 100% unicode compatible at all places and they could be storing from
ftp in some non-utf-8 encoding, but they might be fetching for display
in utf-8 so the browsers are still getting utf-8 encoding to boast off
but the data has got corrupted.
Is that possible and is there any way around to it?
--
I am still irritated but finding a humor in the situation, that all four
browsers are showing identical problems when everything should be
working correctly, as if they all have planned together to mock at me.
--
V
OMG
http://www.time.com/time/
is having 115 Errors, 90 warning(s) in html validation.
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.time.com%2Ftime%2F&charset=(detect+automatically)&doctype=Inline&group=0
and
34 errors in css validation
http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fwww.time.com%2Ftime%2F&profile=css21&usermedium=all&warning=1&lang=en
Shame on their developers. They should be first to be gobbled up by the
blackholes created by LHC at Geneva today.
--
V
>> Basic cause is the Fonts used to display the content. Modern UNCODE
>> encoded fonts have multiple character sets, formerly called "Code
>> Pages". Some fonts do not have valid Character maps for the UTF-8
>> encoding, so the Unknown character '?' is substituted in the display.
>> So basicaly if the Web page declares the UTF-8 encoding as You have
>> cited, browsers will honor that, and will use any font-family
>> declarations in Your CSS <style> tags, even if they do not have an
>> internal UTF-8 character map.
>>
>
> Oh, that could be the cause.
>
> I have used "font-family: times, serif".
>
> I am on pc ff3 and my client whose website I am working on is at mac
> safari. So, I thought to use these, instead of Windows proprietary fonts
> that might not be usable on mac.
Actually that was a smart decision. However, times is both a generic and
specific family, where as Times New Roman is a specific family. With the
advent of the Open Type Format (OTF) and Mac OS-X OS's, the split with
Windows PC's is gone. This means You can specify a PC font and then add a
general family and ending with the universal generic as a fail safe.
In the history of typography, Times is a much older design than Times New
Roman.
Given rise of the internet, font designers responded with "Web Fonts" which
are designs optimized for computer monitor displays rather than printer
output. So if the client wants a serif type face, on PC this would be
Georgia with a fair possibility that new Mac's have it also. So I suggest
"Font-Family: Georgia,Times,Serif;" which accommodates PC & New Mac, Old
Mac, and Linux.
> Any PC+MAC veteran here? Which font-family would work identically on both?
> --
>
> btw, a hit on the google said that it is possible that my server's
> storage/ display mechanism is causing this problem. Maybe, the server is
> not 100% unicode compatible at all places and they could be storing from
> ftp in some non-utf-8 encoding, but they might be fetching for display
> in utf-8 so the browsers are still getting utf-8 encoding to boast off
> but the data has got corrupted.
>
> Is that possible and is there any way around to it?
>
> --
>
> I am still irritated but finding a humor in the situation, that all four
> browsers are showing identical problems when everything should be
> working correctly, as if they all have planned together to mock at me.
>
Well, the bit You cite about the Google hit does sound possible.
> Any PC+MAC veteran here? Which font-family would work identically on
> both?
None, but you shouldn't expect pages to look identical in different
browsers. The page should work even if you don't use a font-family
rule.
> btw, a hit on the google said that it is possible that my server's
> storage/ display mechanism is causing this problem. Maybe, the server
> is not 100% unicode compatible at all places and they could be
> storing from ftp in some non-utf-8 encoding, but they might be
> fetching for display in utf-8 so the browsers are still getting utf-8
> encoding to boast off but the data has got corrupted.
>
> Is that possible and is there any way around to it?
Generally, the solution to that would be using ® instead of just
putting the unicode character directly in your source. Since "®"
is only 7-bit ASCII text stored on and sent from the server, there
should be no server-side corruption of it.
What started as a specific question, but without a URL, has moved to a
general discussion of hypothetical Unicode problems. Since you say the
problem occurs with all browsers, it seems it wasn't a Firefox
problem. I'd take it to alt.www.webmaster or alt.html if I were you,
but they'll also need a URL to make any progress.