Q.: Characters browsers under Win XP can't show?

[tlvp]

I'm uncovering problems with browsers not always displaying the
"t-underdot" character at Unicode point U+1E6D (that looks like this --
"ṭ" -- if your news client offers Unicode support.

In particular, I'm finding that in Win XP neither IE nor WordPad nor even
Word 2000 can successfully display the glyphs that Ṭ (for Ṭ) resp.
ṭ (for ṭ) intend to call forth, while the related (but not
sufficiently similar) Ţ and ţ at code points 0162 and 0163, respectively,
render just fine in all three -- IE, WordPad, and Word 2000 (under XP).

Is my problem more that the default XP font both IE and Word 2000 are set
to use, viz. Times New Roman (TNR), doesn't provide those glyphs?

If that's it, will replacing the TNR font on that XP system with a copy of
the TNR font found on a Vista or Win 7 system -- where browsers *do*
support 1E6C and 1E6D -- solve my problem? Or will doing that only create
new and even worse headaches?

And finally, even if I can adjust *my* XP system to show those characters,
presumably others' XP systems will remain just as loathe to display them as
mine has been 'til now, eh?

TIA for all useful ideas. Cheers, -- tlvp
--
Avant de repondre, jeter la poubelle, SVP.

[Jukka K. Korpela]

2012-09-17 9:50, tlvp wrote:

>I'm finding that in Win XP neither IE nor WordPad nor even
> Word 2000 can successfully display the glyphs that Ṭ (for Ṭ) resp.
> ṭ (for ṭ) intend to call forth,

I don’t have Win XP any more (well, I do, but I won’t try to kick life
into any of the old computers around that have it), but this sounds
familiar. Old Windows versions had limited character repertoires even in
widely used fonts. Microsoft tried hard to improve the situation in
Vista (for “core fonts”).

> while the related (but not
> sufficiently similar) Ţ and ţ at code points 0162 and 0163, respectively,
> render just fine in all three -- IE, WordPad, and Word 2000 (under XP).

The probable explanations is that t with cedilla is used in the primary
writing system of some languages (most importantly Romanian, though the
Romanian standardization institute claims that the correct letter there
is t with comma, which has even narrower font support) whereas t with
dot below is only used transliteration (romanization) systems, and only
in more or less scientific systems at that.

> Is my problem more that the default XP font both IE and Word 2000 are set
> to use, viz. Times New Roman (TNR), doesn't provide those glyphs?

Most probably. I just added the following sentences to my “Guide to
using special characters in HTML”
(http://www.cs.tut.fi/~jkorpela/html/characters.html):
“However, a font may exist in multiple versions, and the information at
that site [Fileformat.info] mostly relates to newest versions. For
example, in older Windows systems, many of the common fonts like Times
New Roman have essentially narrower coverage than in modern systems.”

> If that's it, will replacing the TNR font on that XP system with a copy of
> the TNR font found on a Vista or Win 7 system -- where browsers *do*
> support 1E6C and 1E6D -- solve my problem? Or will doing that only create
> new and even worse headaches?

It would probably solve the problem in your system, and it would
probably constitute copyright infringement.

> And finally, even if I can adjust *my* XP system to show those characters,
> presumably others' XP systems will remain just as loathe to display them as
> mine has been 'til now, eh?

Quite right. But @font-face might solve the problem, if you can find a
suitable free (or reasonably licenseable) font. It can be tricky, as
“free”, “large”, and “typographically good” are often contradictory
requirements when searching for fonts. And a font may get rendered in
rather different ways on different systems (depending on OS and,
regarding Windows, on font smoothing settings). XITS, maybe?

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

[tlvp]

On Mon, 17 Sep 2012 10:59:44 +0300, Jukka K. Korpela wrote:

> It would probably solve the problem in your system, and it would
> probably constitute copyright infringement.

Ah, lovely, another "good news / bad news" joke, but with a "good news"
clincher:

: ... but no one would likely ever find out about it to sue you for it :-) .

Thanks, and cheers, -- tlvp

[tlvp]

On Mon, 17 Sep 2012 10:59:44 +0300, Jukka K. Korpela wrote:

> 2012-09-17 9:50, tlvp wrote:
>
>>I'm finding that in Win XP neither IE nor WordPad nor even
>> Word 2000 can successfully display the glyphs that Ṭ (for Ṭ) resp.
>> ṭ (for ṭ) intend to call forth,
>
> I don’t have Win XP any more (well, I do, but I won’t try to kick life
> into any of the old computers around that have it), but this sounds
> familiar. Old Windows versions had limited character repertoires even in
> widely used fonts. Microsoft tried hard to improve the situation in
> Vista (for “core fonts”).

Oddly enough, the TNR in Win 95 (or in Word for Win 95 on that system --
was that called Word 7 ?) *did* include the character at Unicode point
1E6D. Only when migrating to Win 2000 on XP did we run into the need to
find some close approximation thereto (and settle upon 0163). Now that
Vista & 7 (and/or Word 2007) have reinstated 1E6D, we'd like to restore it
into the texts it belongs in, and would most like to be able to do that
across all our current systems, XP (with Word 2000), Vista (no Word at
all), and 7 (Word 2007).

"Keep the sheep baa-ing and all stirred up" must be the MS motto, as it
constantly revises its fonts and auxiliary programs, converting menus to
ribbons to PowerPointSlide-like tombstones ... err, sorry: "tiles" :-) .

[tlvp]

On Mon, 17 Sep 2012 10:59:44 +0300, Jukka K. Korpela wrote:

> ... @font-face might solve the problem, if you can find a

> suitable free (or reasonably licenseable) font. It can be tricky, as
> “free”, “large”, and “typographically good” are often contradictory
> requirements

One even larger "if" hurdle I must overcome: mastering the syntax,
semantics, and/or usage principles of the @font-face idiom. I've tried ...
and failed. And haven't yet found a good tutorial or example of a working
@font-face instance. Suggestions?

Cheers, and TIA, -- tlvp

[Jukka K. Korpela]

2012-09-17 13:02, tlvp wrote:

> Oddly enough, the TNR in Win 95 (or in Word for Win 95 on that system --

> was that called Word 7 ?)*did* include the character at Unicode point

> 1E6D. Only when migrating to Win 2000 on XP did we run into the need to
> find some close approximation thereto

Odd indeed, but such things may happen. It's possible that some Word
versions were shipped with an enhanced TNR, but later this was dropped.
Maybe they decided that it was not necessary any more since new Windows
systems have a rich enough TNR, without considering (or deciding to
ignore) the fact that Word might be installed on older systems.

In any case, the repertoire of fonts in Windows systems is greatly
affected by application software, such as Microsoft Office or
LibreOffice, which come with some additional (and maybe updated) fonts.

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

[Jukka K. Korpela]

2012-09-17 13:07, tlvp wrote:

> One even larger "if" hurdle I must overcome: mastering the syntax,
> semantics, and/or usage principles of the @font-face idiom. I've tried ...
> and failed. And haven't yet found a good tutorial or example of a working
> @font-face instance. Suggestions?

I'm just preparing a course on web typography, and I included the
following to demonstrate how easy things can be:

<link href='http://fonts.googleapis.com/css?family=Petit+Formal+Script'
rel='stylesheet'>
<style>
.typodemo {
font-family: 'Petit Formal Script', cursive;
}
</style>
<p class=typodemo>Text to appear in the Petit Formal Script font.</p>

This leaves the technical mess (of using different font formats for
different browsers etc.) to the Google Web Fonts service,
http://www.google.com/webfonts

But the bad news is that most of those fonts have poor character
coverage, they suffer from typographic flaws, and they too often render
differently depending on OS. So there's hope, but proceed with caution.
It can be difficult to find e.g. a serif font sufficient repertoire of
math symbols, and you probably won't get far with Google Web Fonts only,
but with http://www.fontsquirrel.com/ you might find something. (Getting
rather far from HTML now, though.)

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

[Andreas Prilop]

On Mon, 17 Sep 2012, tlvp wrote:

> Oddly enough, the TNR in Win 95 (or in Word for Win 95 on that system --
> was that called Word 7 ?) *did* include the character at Unicode point
> 1E6D.

I do not believe you.

--
I used to believe in reincarnation in a former life.

[Andreas Prilop]

On Mon, 17 Sep 2012, tlvp wrote:

> "t-underdot" U+1E6D

> Is my problem more that the default XP font both IE and Word 2000 are
> set to use, viz. Times New Roman (TNR), doesn't provide those glyphs?

Take Tahoma.

[Martin Leese]

tlvp wrote:
> I'm uncovering problems with browsers not always displaying the
> "t-underdot" character at Unicode point U+1E6D (that looks like this --
> "ṭ" -- if your news client offers Unicode support.

Andreas Prilop wrote:
> On Mon, 17 Sep 2012, tlvp wrote:
>
>> Oddly enough, the TNR in Win 95 (or in Word for Win 95 on that system --
>> was that called Word 7 ?) *did* include the character at Unicode point
>> 1E6D.
>
> I do not believe you.

I do. I am running Win 95, and I can see it.

--
Regards,
Martin Leese
E-mail: ple...@see.Web.for.e-mail.INVALID
Web: http://members.tripod.com/martin_leese/

[Jukka K. Korpela]

2012-09-17 20:39, Andreas Prilop wrote:

> On Mon, 17 Sep 2012, tlvp wrote:
>
>> "t-underdot" U+1E6D
>> Is my problem more that the default XP font both IE and Word 2000 are
>> set to use, viz. Times New Roman (TNR), doesn't provide those glyphs?
>
> Take Tahoma.

Is this a trick suggestion?

On the top of my head, I can only list about four reasons not to do that:
1) Tahoma is more or less condensed Verdana. So not.
2) Sans serif fonts are generally unsuitable for mathematical texts,
which are what tlvp is probably working with.
3) The glyph for U+1E6D is poor in Tahoma (placed too much to the right).
4) You should not select a font for a particular character but for text
in a rather abstract sense, covering all the characters that appear in
it or will appear in it in the foreseeable future.

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

[Andreas Prilop]

On Mon, 17 Sep 2012, Jukka K. Korpela wrote:

>>> "t-underdot" U+1E6D

>>
>> Take Tahoma.
>
> Is this a trick suggestion?

No.

> 1) Tahoma is more or less condensed Verdana.

For ASCII characters. Tahoma also contains Extended Latin, Arabic,
Hebrew, and Thai.

> 2) Sans serif fonts are generally unsuitable for mathematical texts,
> which are what tlvp is probably working with.

T with dot below is need for transliterated Sanskrit:
<news:1xpg58tk1528h.1evqtubrafpti$.d...@40tude.net> in comp.fonts

[Chris F.A. Johnson]

On 2012-09-17, Jukka K. Korpela wrote:
> 2012-09-17 13:07, tlvp wrote:
>
>> One even larger "if" hurdle I must overcome: mastering the syntax,
>> semantics, and/or usage principles of the @font-face idiom. I've tried ...
>> and failed. And haven't yet found a good tutorial or example of a working
>> @font-face instance. Suggestions?
>
> I'm just preparing a course on web typography, and I included the
> following to demonstrate how easy things can be:
>
><link href='http://fonts.googleapis.com/css?family=Petit+Formal+Script'
> rel='stylesheet'>
><style>
> .typodemo {
> font-family: 'Petit Formal Script', cursive;
> }
></style>

I put the call in my .css files, e.g.:

@import url(http://fonts.googleapis.com/css?family=Metrophobic|Anton);


--
Chris F.A. Johnson
<http://cfaj.ca/>

[Jukka K. Korpela]

2012-09-17 20:57, Andreas Prilop wrote:

>> 1) Tahoma is more or less condensed Verdana.
>
> For ASCII characters. Tahoma also contains Extended Latin, Arabic,
> Hebrew, and Thai.

It has the same overall style (like Verdana but condensed) for all
characters. I suppose you mean that it has larger character repertoire
than some alternatives. It's still rather limited (3,414 glyphs in
version 5.10).

>> 2) Sans serif fonts are generally unsuitable for mathematical texts,
>> which are what tlvp is probably working with.
>
> T with dot below is need for transliterated Sanskrit:

And for many other transliteration schemes used by scholars. If you are
using such a scheme, then the font should be selected so that it
contains all the characters needed in it. (However, in the case of
underlined letters, you could use normal letters underlined, as with
<u>t</u>, though this is of course by no means ideal.)

Another reason why Tahoma is unsuitable for mathematical texts (and many
other types of text) is that it has only regular and bold typeface, no
italic (or italic bold). If you have, say, <i>a</i> or <var>a</var> in
HTML and the font is Tahoma, browsers algorithmically slant (quite a
lot) a regular letter "a", causing ugly rendering that surely differs
from practices of math books and papers.

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

[Scott Bryce]

On 9/17/2012 4:50 AM, Jukka K. Korpela wrote:
> I'm just preparing a course on web typography, and I included the
> following to demonstrate how easy things can be:
>
> <link href='http://fonts.googleapis.com/css?family=Petit+Formal+Script'
> rel='stylesheet'>
> <style>
> .typodemo {
> font-family: 'Petit Formal Script', cursive;
> }
> </style>
> <p class=typodemo>Text to appear in the Petit Formal Script font.</p>

I am not seeing the fonts in Firefox 15.01 on Windows Vista. I see them
on IE, Safari, Chrome and Opera.

Is this something that Firefox does not support?

[Jukka K. Korpela]

2012-09-18 18:11, Scott Bryce wrote:

>> <link href='http://fonts.googleapis.com/css?family=Petit+Formal+Script'
>> rel='stylesheet'>
>> <style>
>> .typodemo {
>> font-family: 'Petit Formal Script', cursive;
>> }
>> </style>
>> <p class=typodemo>Text to appear in the Petit Formal Script font.</p>
>
> I am not seeing the fonts in Firefox 15.01 on Windows Vista. I see them
> on IE, Safari, Chrome and Opera.

Strange. I have no problem with this on Firefox 15.0.1 Windows 7, and I
don't think it depends on Windows version. Rather, it might be something
in your installation.

As far as I know, the only normal way (apart from trying to find a
variable in about:config) to disallow web fonts in Firefox is to prevent
pages from specifying fonts at all. People might do that for
accessibility reasons, but I would expect that to be rare.

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

[Scott Bryce]

On 9/18/2012 9:11 AM, Scott Bryce wrote:
> I am not seeing the fonts in Firefox 15.01 on Windows Vista. I see
> them on IE, Safari, Chrome and Opera.
>
> Is this something that Firefox does not support?

I changed my settings. I see the fonts now.

[David Stone]

In article <k3a5cc$pil$1...@dont-email.me>,

The NoScript plug-in has an option to block @font-face, although I
forget what the default is. I think I set it to block font-face about
the time there was a remote code execution vulnerability involving
font-face for Firefox (back in 2010), and I never reset that option...

[Scott Bryce]

On 9/18/2012 9:52 AM, Jukka K. Korpela wrote:
> As far as I know, the only normal way (apart from trying to find a
> variable in about:config) to disallow web fonts in Firefox is to
> prevent pages from specifying fonts at all.

It looks like that's what I had done. I thought I was specifying a
default font when the page did not specify a font. It turns out I was
overriding the page's fonts. I changed the settings. I see the fonts now.

This is why I still find this newsgroup useful. I would not have known
about Google web fonts, or discovered that I had my browser settings
wrong, had it not been for this thread.

[Andreas Prilop]

On Mon, 17 Sep 2012, Martin Leese wrote:

>>> Oddly enough, the TNR in Win 95 (or in Word for Win 95 on that system --
>>> was that called Word 7 ?) *did* include the character at Unicode point
>>> 1E6D.
>>
>> I do not believe you.
>
> I do. I am running Win 95, and I can see it.

I do not believe you either.

I have inspected Times New Roman "MS core font V2.00"
with modification date 1995-07-12.
http://www.microsoft.com/typography/fonts/font.aspx?FMID=73

It contains virtually no characters from Latin Extended Additional
- except the Welsh letters "W with grave, acute, diaeresis".

I think you confuse "T with cedilla" and "T with dot below".

[Jukka K. Korpela]

2012-09-18 19:22, David Stone wrote:

> The NoScript plug-in has an option to block @font-face, although I
> forget what the default is.

Thanks for the information! I just installed the Firefox plug-in
NoScript (with no intention of keeping it in use...), current version
2.5.5, and it indeed has @font-face prevented by default. Rather
strange, I would say, since @font-face has nothing to do with scripting.

ObHTML: NoScript also prevents <audio> and <video> in its default
settings. It also has settings for preventing some other HTML elements,
though these are off by default: <iframe>, <frame>, <a ping...>, and
<noscript> (!).

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

[David Stone]

In article <k3ab9m$3mn$1...@dont-email.me>,

"Jukka K. Korpela" <jkor...@cs.tut.fi> wrote:

> 2012-09-18 19:22, David Stone wrote:
>
> > The NoScript plug-in has an option to block @font-face, although I
> > forget what the default is.
>
> Thanks for the information! I just installed the Firefox plug-in
> NoScript (with no intention of keeping it in use...), current version
> 2.5.5, and it indeed has @font-face prevented by default. Rather
> strange, I would say, since @font-face has nothing to do with scripting.

No, but see my snipped comment about the remote code execution flaw
associated with Firefox. Plus, who knows what glyphs are lurking in
some creative genius' custom font-face!

> ObHTML: NoScript also prevents <audio> and <video> in its default
> settings. It also has settings for preventing some other HTML elements,
> though these are off by default: <iframe>, <frame>, <a ping...>, and
> <noscript> (!).

Don't forget that NoScript's primary purpose is to block unwanted
advertising. The default off for audio and video elements prevents
unexpectedly loud noises from web sites misguided enough to think
that autoplay is a good thing. I haven't played with those settings,
but certainly with Flash and JS, you can enable or block on a
site-specific basis. Until I installed NoScript, I had no idea just
how many web sites trigger JS visits through google.com systems...

[tlvp]

On Mon, 17 Sep 2012 20:47:02 +0300, Jukka K. Korpela wrote:

> 2012-09-17 20:39, Andreas Prilop wrote:
>
>> On Mon, 17 Sep 2012, tlvp wrote:
>>
>>> "t-underdot" U+1E6D
>>> Is my problem more that the default XP font both IE and Word 2000 are
>>> set to use, viz. Times New Roman (TNR), doesn't provide those glyphs?
>>
>> Take Tahoma.
>
> Is this a trick suggestion?
>
> On the top of my head, I can only list about four reasons not to do that:
> 1) Tahoma is more or less condensed Verdana. So not.
> 2) Sans serif fonts are generally unsuitable for mathematical texts,
> which are what tlvp is probably working with.

In this instance, actually, not math, but a retelling, in Polish, of the
classic Sanskrit Hindu epic /Mahabharata/, both as web-page "instalments"
or "episodes", and as book volumes to be published ink-on-paper fashion,
using a serif typeface for the body text of the book (whence Tahoma would
require total redesign).

> 3) The glyph for U+1E6D is poor in Tahoma (placed too much to the right).

We can't have serif characters preceding and following a sans serif
instance of "t-underdot" U+1E6D in one and the same word -- our eyes won't
stand for it. Better a "t-cedilla", or even a simple undecorated "t", in
the same serif font :-) .

> 4) You should not select a font for a particular character but for text
> in a rather abstract sense, covering all the characters that appear in
> it or will appear in it in the foreseeable future.

[Jukka K. Korpela]

2012-09-19 2:58, tlvp wrote:

>> 2) Sans serif fonts are generally unsuitable for mathematical texts,
>> which are what tlvp is probably working with.
>
> In this instance, actually, not math, but a retelling, in Polish, of the
> classic Sanskrit Hindu epic /Mahabharata/, both as web-page "instalments"
> or "episodes", and as book volumes to be published ink-on-paper fashion,
> using a serif typeface for the body text of the book (whence Tahoma would
> require total redesign).

Attempts at facsimile-like publishing in HTML format suffer from serious
limitations. To begin with, no matter what you do in HTML, CSS,
JavaScript, etc., the resolutions of devices that people use are still
still much poorer than in decent-quality or better book printing. So any
font used in the book won’t look the same, even if you could use the
best possible digitalized version of the font. And if you specifically
aim at producing something that people just print, then PDF, or even MS
Word (used well) tends to be a better approach than HTML and friends.

But assuming that it’s not really facsimile, or ink-on-paper, but
something stylistically similar to an original, then surely you should
not replace a normal book font with Tahoma.

>> 3) The glyph for U+1E6D is poor in Tahoma (placed too much to the right).
>
> We can't have serif characters preceding and following a sans serif
> instance of "t-underdot" U+1E6D in one and the same word -- our eyes won't
> stand for it.

Right. Even a mix like text in Arial, isolated letters in Tahoma, is
bad; even more so when mixing serif and sans-serif.

> Better a "t-cedilla", or even a simple undecorated "t", in
> the same serif font :-) .

Typographically better, but not adequate at all in terms of content.

I think the best approach here is to try to find a free font family that
contains the characters you need and that has the typefaces (regular,
italic, bold,...?) you need. Perhaps Junicode?
http://junicode.sourceforge.net/
You would then need to use e.g.
http://www.fontsquirrel.com/fontface/generator
to generate the various font formats from the TTF fonts; it will also
show the CSS code needed for using the fonts. (The various formats are
needed because different browsers recognize different formats.)

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

[tlvp]

Agreed. A Sanskritologist would be appalled (and rightly so); but a lay
Polish reader will simply note that this is not an ordinary everyday "t",
but one requiring a decoration reminiscent of a Polish "ogonek" -- and be
content with that simple distinction between it and an ordinary "t".

> I think the best approach here is to try to find a free font family that
> contains the characters you need and that has the typefaces (regular,
> italic, bold,...?) you need. Perhaps Junicode?

For the Word documents the books are PDFed from, that's an interesting
thing for us to consider, thanks, particularly in that it's a fairly
TNR-like font (in the sense that as typographical amateur won't very likely
spot the difference except in a side-by-side comparison of samples).

> http://junicode.sourceforge.net/
> You would then need to use e.g.
> http://www.fontsquirrel.com/fontface/generator
> to generate the various font formats from the TTF fonts; it will also
> show the CSS code needed for using the fonts. (The various formats are
> needed because different browsers recognize different formats.)

For the web pages that's interesting for us to consider, too, thanks.
For them, though, what I'd really love to learn is actually available
(though I have my doubts) is something like the alt="" mechanism for
images, but for character references in HTML. In that way I might be able
to write, for "Viraṭa",

: Vira<span alt="&#x0163; t">&#x1E6D</span>ta

confident that, where possible, a browser will write Virata with an
under-dot decorating the t, or (next-best) a cedilla, or (those both
failing) a "just plain" t devoid of any under-decoration.

As I say, though, I have my doubts.

As for Word, it's because of the vagaries of the various incarnations of
Word as running on various iterations of Windows that this problem came to
my attention in the first place.

In the dim dark distant days of Windows 9* and Word from Office 9*, we had
a Times New Roman (henceforth: TNR) character looking for all the world
like what U+1E6D should look like (clearly different from what U+0163, also
available there, looks like).

Then came Office 2000 and Windows XP and, kerflooey, no more U+1E6D.
Even documents supposedly having fonts embedded showed only a blank
rectangular box outline where a U+1E6D should have appeared.

Sighing sadly and resignedly, we replaced all the t-underdots with U=0163
t-cedillas.

Now that Word is up to version 2007 (and beyond) and Windows is up to Vista
(and beyond), MS has rehabilitated U+1E6D, so we thought we'd undo that
replacement, and put U+1E6D characters back in for all the instances of
t-cedilla that we compromised with ... but, once again, even a Word
document saved with fonts embedded and in Word 2000 compatibility form
(i.e., as a .doc file rather than a .docX file) shows only those garish
blank rectangular box outlines, where a U+1E6D should appear, when opened
in Word 2000 on our XP system.

Our printing gets done via PDFs generated (by an ancient Adobe Distiller)
on that XP machine. PDFs generated either by Word 2007 itself, or by
BullZIP PDF printer, on the Win 7 machine, have other font-loss defects, as
the Win 7 machine neither has, nor seems to respect the embeddedness, of
fonts in use on the XP machine.

It's for that reason that I am leaning to the "solution" of replacing TNR
on the XP box with a copy of TNR suite from Windows 7 (or Win Vista),
though I'm not sure whether (a) that won't lead to other incompatibilities,
or (b) it doesn't contravene terms of relevant EULA or copyrights.

Fortunately, there's only one (so far) volume in which U+1E6D wants to
appear, in print, and for the corresponding web pages we don't mind
omitting all diacritical decorations on the letters t that might have them,
so that annoyance is limited in scope.

Well, sorry. This has been very OT, very diffuse, and very rambling, so
I'll stop now.

Cheers, and many thanks for the Junicode suggestion, -- tlvp

[Jukka K. Korpela]

2012-09-22 8:13, tlvp wrote:

> Agreed. A Sanskritologist would be appalled (and rightly so); but a lay
> Polish reader will simply note that this is not an ordinary everyday "t",
> but one requiring a decoration reminiscent of a Polish "ogonek" -- and be
> content with that simple distinction between it and an ordinary "t".

Ouch! Ogonek and dot below are entirely different monsters in my book.
This is different from, say, substituting ê for ē when transliterating
Greek – such substitutions have been common for technical reasons
(mainly the reason that ê is in Latin 1, ē is not), but this does not
mean that a diacritic could generally be replaced by another diacritic.

> For the web pages [...] what I'd really love to learn is actually available

> (though I have my doubts) is something like the alt="" mechanism for
> images, but for character references in HTML. In that way I might be able
> to write, for "Viraṭa",
>
> : Vira<span alt="&#x0163; t">&#x1E6D</span>ta

No, unfortunately you cannot do that. People have often looked for
markup that would sort-of reverse the roles of an image and a piece of
text in <img src=... alt=...>, in the sense that if a character cannot
be rendered, an image would be displayed in its stead. And similarly for
replacing an unrepresentable character by an alternative. Not possible.
I’m afraid we cannot even test dynamically, in JavaScript or otherwise,
whether a browser is able to render a character or not – that is, to
intercept the process where the browser may eventually end up with
displaying a small rectangle or something like that.

What we can do, in principle, is to specify alternate fonts in CSS,
either simply using font-family: foo, bar, YetAnotherFont or by using
unicode-range in @font-face rules. (The latter is slowly getting
support; Chrome now OK.) But this means using different glyphs for a
character, not using different characters (though there are dirty tricks
like creating a font that displays characters using glyphs that
represent other characters).

> Then came Office 2000 and Windows XP and, kerflooey, no more U+1E6D.
> Even documents supposedly having fonts embedded showed only a blank
> rectangular box outline where a U+1E6D should have appeared.

If embedding actually took place, I wonder whether the font used was
broken, so that the box came from the font. That would be foolish font
design, but possible, and I think I may have seen such things.

> Now that Word is up to version 2007 (and beyond) and Windows is up to Vista
> (and beyond), MS has rehabilitated U+1E6D, so we thought we'd undo that
> replacement, and put U+1E6D characters back in for all the instances of
> t-cedilla that we compromised with ... but, once again, even a Word
> document saved with fonts embedded and in Word 2000 compatibility form
> (i.e., as a .doc file rather than a .docX file) shows only those garish
> blank rectangular box outlines, where a U+1E6D should appear, when opened
> in Word 2000 on our XP system.
>
> Our printing gets done via PDFs generated (by an ancient Adobe Distiller)
> on that XP machine. PDFs generated either by Word 2007 itself, or by
> BullZIP PDF printer, on the Win 7 machine, have other font-loss defects, as
> the Win 7 machine neither has, nor seems to respect the embeddedness, of
> fonts in use on the XP machine.

This sounds strange. Are you sure the Word document was saved with
embedded TTF font(s), as instructed at
http://support.microsoft.com/kb/290952 ?
I tested with a .doc file saved that way and then saved as PDF (in Word
2007) with default settings, and the font appears as embedded in the .pdf.

I recently realized something that should have been obvious: Nowadays,
you can effectively embed fonts even in an HTML document that is meant
for offline use, for use as a distribution format without necessarily
involving the net at all. You can put the font files in the same folder
as the HTML document and use them via @font-face, and perhaps zip the
folder if desired. Naturally, this requires that the font is free (or
you otherwise have right to distribute it.

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

[tlvp]

Maybe the t-underdot arose not from the Win 9* font provisions, or even the
Word 199* font allocations, but from the Multilingual Proofing add-ons we
have. No matter, it's gone again in XP and Word 2000, and back again in
Word 2007 on Win 7.

Anyway, I'm confident that I'm about as likely to 'confuse "T with cedilla"
and "T with dot below" ' as I am to confuse comma with period :-) .

[William F. Adams]

To determine what font is used for a character in a browser make
a .pdf of the page, then look at the .pdf characteristics.

William

[Jonathan N. Little]

Much simpler to use the Web Developers Bar or Firebug extensions in Firefox.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

[Jukka K. Korpela]

2012-09-25 17:10, Jonathan N. Little wrote:

> William F. Adams wrote:
[...]

>> To determine what font is used for a character in a browser make
>> a .pdf of the page, then look at the .pdf characteristics.
>
> Much simpler to use the Web Developers Bar or Firebug extensions in
> Firefox.

No, not really. Consider the following:

<!doctype html>
<html lang=fi>
<meta charset=utf-8>
Hello world
<p style="font-family: serif">Hello again

The Web Developer Extension and Firebug both report the fonts as
"serif", which is of course not the name of a font but a generic name
that is mapped to a specific font name in a browser-dependent way.

(Incidentally, on IE 9, Win 7, the document is displayed using two
different fonts: the browser default font, though a serif font, is not
the same font as the one corresponding to the generic name "serif"!)

I'm afraid PDF format does not give a direct answer either, but it does
give a specific answer. On Adobe Reader, the font is specified as
"Times-Roman". I suppose this means the same as "Times New Roman". On
Foxit Reader, the font is shown as "MDCZEU+Times-Roman". For more fun
(and addressing a more important question), when I open the document on
IE and print to a virtual printer in PDF format, the fonts are shown as
"BLDMJH+51ogbe" and "QTPJOZ+19fubkffbonphwm"

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

[William F. Adams]

Times is from Linotype, Times New Roman is from Monotype --- see
Walter Tracy's _Letters of Credit_ for the backstory there.

The all caps+fontname indicates that the font has been subsetted ---
use a .pdf specification which dis-allows that and you should get the
un-adorned font name.

William

[tlvp]

You remind me, Jukka, of the tale (perhaps apocryphal) of the stable-boy
whom Francis Bacon felt inspired to discharge when, hearing Francis and his
supper-mates discussing all the theoretical grounds on which one might
infer how many teeth grow in the mouth of a healthy stallion, he offered to
go out into the stable, count a stallion's teeth, and report back with the
answer to the assembled discussants. Alas, poor stable-boy: Sir Francis
far preferred the refined discussion to the brutal facts :-) .

So: thanks for those brutal facts :-) !

[Jukka K. Korpela]

2012-09-26 3:16, William F. Adams wrote:

> On Sep 25, 10:29 am, "Jukka K. Korpela" <jkorp...@cs.tut.fi> wrote:

[...]

>> I'm afraid PDF format does not give a direct answer either, but it does
>> give a specific answer. On Adobe Reader, the font is specified as
>> "Times-Roman". I suppose this means the same as "Times New Roman". On
>> Foxit Reader, the font is shown as "MDCZEU+Times-Roman". For more fun
>> (and addressing a more important question), when I open the document on
>> IE and print to a virtual printer in PDF format, the fonts are shown as
>> "BLDMJH+51ogbe" and "QTPJOZ+19fubkffbonphwm"
>
> Times is from Linotype, Times New Roman is from Monotype

Right, so the question is why it is reported as "Times-Roman" on a
system where the font name is "Times New Roman" and the information says
that the author is Monotype Type Drawing Office. My guess is that it
just gets messed up by the PDF writing software.

I now installed PDF24 Creator, and it shows the font as TimesNewRoman.
But this happens when printing from Firefox.

When printing from IE, which is really the interesting part here, due to
its odd mapping of the generic name "serif", I still get cryptic names.

> The all caps+fontname indicates that the font has been subsetted ---
> use a .pdf specification which dis-allows that and you should get the
> un-adorned font name.

Tried that with PDF24 Creator, using a profile where subsetting has been
ticked off. The font information in Properties in Adobe Reader still
shows "embedded subset" (and cryptic names when the PDF file was created
from IE).

I'm lost now... perhaps subsetting (in font embedding) cannot be turned
off. Or I'm not doing it right. Tried even using MS Word and a free
font. Still reported as "embedded subset".

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

[tlvp]

On Wed, 26 Sep 2012 08:39:35 +0300, Jukka K. Korpela wrote:

> ...

> I'm lost now... perhaps subsetting (in font embedding) cannot be turned
> off. Or I'm not doing it right. Tried even using MS Word and a free
> font. Still reported as "embedded subset".

I'm lost way before that, even. Am I correct in understanding that the
whole point of using font-embedding in a Word document is to enable folks
who haven't got the font in question installed on their systems see what
text in that font looks like in the context of that document?

I fear I may *not* be, by virtue of two seeming counter-examples:

one, a .doc file, created and saved in Word 2000, on a Win XP system having
available a TrueType font called American Typewriter Medium BT, fontname
AmerType Md BT -- even with that font embedded in the document, an instance
of Word running on a system *not* endowed with that font winds up
_substituting a different font for it_(!); and

two, a doc file, created and saved in Word 2007, on a Win 7 system whose
Times New Roman includes the t-underdot glyph for code point 1E6D -- even
with all fonts embedded in the document, an instance of Word 2000 running
on the first Win XP system (whose TNR does *not* extend to 1E6D) fails to
display anything other than a blank rectangular box-outline where U+1E6D
should appear.

PDF files made from either of those .doc files, on the other hand, display
all the problematic characters correctly on either system, indeed, on all
the systems I've tried them in.

What am I missing or failing to understand here?

Cheers, and TIA, -- tlvp

[Jukka K. Korpela]

2012-09-26 9:23, tlvp wrote:

> On Wed, 26 Sep 2012 08:39:35 +0300, Jukka K. Korpela wrote:
>
>> ...
>> I'm lost now... perhaps subsetting (in font embedding) cannot be turned
>> off. Or I'm not doing it right. Tried even using MS Word and a free
>> font. Still reported as "embedded subset".
>
> I'm lost way before that, even. Am I correct in understanding that the
> whole point of using font-embedding in a Word document is to enable folks
> who haven't got the font in question installed on their systems see what
> text in that font looks like in the context of that document?

That's the point indeed. Things may fail, though. They may fail because
the font may get rendered differently on different systems, e.g. due to
different subpixel rendering (or lack thereof). But there are other ways
to fail, too. When using embedded fonts on web pages, you need to send
the font in different formats to different browsers, and this may cause
problems if some of the formats is broken.

> I fear I may *not* be, by virtue of two seeming counter-examples:
>
> one, a .doc file, created and saved in Word 2000, on a Win XP system having
> available a TrueType font called American Typewriter Medium BT, fontname
> AmerType Md BT -- even with that font embedded in the document, an instance
> of Word running on a system *not* endowed with that font winds up
> _substituting a different font for it_(!);

This would probably be the dreaded font substitution mechanism that is
used in Microsoft software. In Word, there's probably a setting for it,
or at least a way to find the substitution table.

> and
>
> two, a doc file, created and saved in Word 2007, on a Win 7 system whose
> Times New Roman includes the t-underdot glyph for code point 1E6D -- even
> with all fonts embedded in the document, an instance of Word 2000 running
> on the first Win XP system (whose TNR does *not* extend to 1E6D) fails to
> display anything other than a blank rectangular box-outline where U+1E6D
> should appear.

I'm afraid Word might still decide to use the local font and not the
embedded font, without knowing that they aren't the same at all in
character coverage.

> PDF files made from either of those .doc files, on the other hand, display
> all the problematic characters correctly on either system, indeed, on all
> the systems I've tried them in.

So this looks like an issue with Word specifically.

When embedding fonts in HTML documents, the @font-face rule may specify
a local name for the font, so that a local font is used if available.
Otherwise, local fonts are not used. I haven't heard of problems with
_this_ logic.

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

[David Lasher]

There's a Firefox add-on that simply tells you what fonts are actually
used on a page.
https://addons.mozilla.org/en-US/firefox/addon/fontinfo/

David

[Jukka K. Korpela]

2012-09-26 12:29, David Lasher wrote:

> There's a Firefox add-on that simply tells you what fonts are actually
> used on a page.
> https://addons.mozilla.org/en-US/firefox/addon/fontinfo/

Great! It tells, in Page Info, a list of all actual fonts, and it also
lets you select some text and get a list of fonts used in that fragment.

(I thought I had tested such an add-on earlier and found it wanting -
like so many other tools that don't really tell the specific name - but
maybe it was another add-on with a similar name, or an earlier version.)

If only we could get something similar for IE...

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

[Andreas Prilop]

On Wed, 26 Sep 2012, Jukka K. Korpela wrote:

> so the question is why it is reported as "Times-Roman"
> on a system where the font name is "Times New Roman"

Times and Times New Roman are names of font families.
(PostScript terminology: FamilyName)
Times-Roman, Times-Italic, Times-Bold, Times-BoldItalic
are names of single fonts.
(PostScript terminology: FontName)
http://www.google.co.uk/search?q=%22Times-BoldItalic.afm%22

I repeat this again and again:
It is important to distinguish between a single font
and font family.
http://www.google.co.uk/search?q=%22A.Prilop+rebukes%22filter=0

--
Outgoing mail is certified free from defamation of Islam™
and insult of the Prophet™.
Checked by Thinkpol anti-obscenity system v. 6.66.

[Andreas Prilop]

On Wed, 26 Sep 2012, Jukka K. Korpela wrote:

> so the question is why it is reported as "Times-Roman"
> on a system where the font name is "Times New Roman"

Times and Times New Roman are names of font families.
(PostScript terminology: FamilyName)
Times-Roman, Times-Italic, Times-Bold, Times-BoldItalic
are names of single fonts.
(PostScript terminology: FontName)
http://www.google.co.uk/search?q=%22Times-BoldItalic.afm%22

I repeat this again and again:
It is important to distinguish between a single font
and font family.

http://www.google.co.uk/search?q=%22A.Prilop+rebukes%22&filter=0

[tlvp]

Should I infer that we'd be better off doing our compositing in HTML, using
the @font-face mechanism, than in Word? I'm almost starting to think so:-).

Cheers, -- tlvp

[David Stone]

In article <1prnlbr6pzvnt.g...@40tude.net>,

tlvp <mPiOsUcB...@att.net> wrote:
> On Wed, 26 Sep 2012 10:27:06 +0300, Jukka K. Korpela wrote:

[Huge snip]

> > So this looks like an issue with Word specifically.
> >
> > When embedding fonts in HTML documents, the @font-face rule may specify
> > a local name for the font, so that a local font is used if available.
> > Otherwise, local fonts are not used. I haven't heard of problems with
> > _this_ logic.
>
> Should I infer that we'd be better off doing our compositing in HTML, using
> the @font-face mechanism, than in Word? I'm almost starting to think so:-).

It would certainly be better than using Word to generate HTML/CSS
documents!

[Jukka K. Korpela]

2012-09-26 19:09, Andreas Prilop wrote:

> On Wed, 26 Sep 2012, Jukka K. Korpela wrote:
>
>> so the question is why it is reported as "Times-Roman"
>> on a system where the font name is "Times New Roman"
>
> Times and Times New Roman are names of font families.

Yes, and this is the reason why I asked about the discrepancy.

> Times-Roman, Times-Italic, Times-Bold, Times-BoldItalic
> are names of single fonts.

My question was why the report says "Times-Roman", suggesting a normal
typeface of the Times family, on a system that has no such font family
but has a (very similar) family called Times New Roman.

The two are easily confused with each other, and Microsoft has
contributed to the confusion. Using the Font Information add-on to
Firefox, I checked a web page with font declared with font-family:
Times, and the add-on reports that it's actually Times New Roman, and
this can be confirmed with simple tests.

Similarly, declaring, say, <font face="Helvetica, Verdana"> on a Windows
system that lacks Helvetica but has Verdana (as most Windows systems do)
causes the text to be displayed in Arial. So automatic and largely
undocumented font mapping is taking place.

> It is important to distinguish between a single font
> and font family.

Yes, and this is becoming even more important. It is less important
which terms we use. Often "font" refers to a font family whereas
"typeface" denotes an individual font in a family. Some confusion may
arise from this, but the important thing is to understand the difference.

For example, if you use FontSquirrel to generate font files for you
(generating different formats from a given format), it also generates a
CSS file. The problem is that it makes each specific font (typeface) a
font family, with rules like

@font-face {
font-family: 'open_sansbold';
[...]
font-weight: normal;
font-style: normal;
}

This is illogical, but it works - if you are cautious. You then need to
explicitly specify open_sansbold for any element that is to be rendered
in bold. And you should explicitly set font-weight to normal for any
element that would otherwise have font-weight: bold, like <b>, <strong>,
and <th>. If you don't do this, some browsers (Safari at least) "bold
the bold", causing bad appearance, since they take the open_sansbold
font, notice that font-weight: bold is set and that the font is declared
as being normal weight - and lacking a bold typeface, the browser then
algorithmically bolds the bold font!

This does not happen if you use Google fonts directly, but they should
really not be used that way in production, for several reasons. And for
CSS code generated by FontSquirrel, the fix is simple (use the same
font-family name for all typefaces and set font-weight and font-style
properly in @font-face rules), but I'm afraid many people miss it.

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

[Scott Bryce]

On 9/27/2012 8:43 AM, Jukka K. Korpela wrote:
>> Times-Roman, Times-Italic, Times-Bold, Times-BoldItalic are names
>> of single fonts.
>
> My question was why the report says "Times-Roman", suggesting a
> normal typeface of the Times family, on a system that has no such
> font family but has a (very similar) family called Times New Roman.

You read these font names out of a PDF file, right? Times-Roman,
Times-Italic, Times-Bold, and Times-BoldItalic are fonts that are part
of the PDF package. They are installed with a PDF reader. You will find
them in the PDF reader directory. The PDF spec says that they, along
with a small handful of other fonts, are always available to a PDF
reader, so someone creating a PDF file can know that they will always be
available to the PDF file without embedding them.

So if you are creating a PDF file from a document that uses Times New
Roman, the PDF creator is likely to use Times-Roman in its place.
Likewise, if the document uses Arial, the PDF creator is likely to
substitute Helvetica.

The complete list of PDF standard fonts is:

Times-Roman
Helvetica
Courier
Symbol
Times-Bold
Helvetica-Bold
Courier-Bold
ZapfDingbats
Times-Italic
Helvetica-Oblique
Courier-Oblique
Times-BoldItalic
Helvetica-BoldOblique
Courier-BoldOblique

[Jonathan N. Little]

Using a dead cat would be better

[tlvp]

On Thu, 27 Sep 2012 08:55:08 -0400, David Stone wrote:

>> ... Should I infer that we'd be better off doing our compositing in HTML, using

>> the @font-face mechanism, than in Word? I'm almost starting to think so:-).
>
> It would certainly be better than using Word to generate HTML/CSS
> documents!

Amen! :-) . Cheers, -- tlvp

[tlvp]

So what, then, must one do if hoping to create a PDF faithfully
representing the fonts actually used in a document, rather than
substituting the fonts the PDF vendor thinks it best to substitute?

Cheers, and TIA, -- tlvp

[Osmo Saarikumpu]

On 27.9.2012 17:43, Jukka K. Korpela wrote:

> This does not happen if you use Google fonts directly, but they should
> really not be used that way in production, for several reasons.

Would you please elaborate on the reasons?

(Followup-To: ciwas)

--
Best wishes, Osmo

[Scott Bryce]

On 9/27/2012 7:29 PM, tlvp wrote:
> So what, then, must one do if hoping to create a PDF faithfully
> representing the fonts actually used in a document, rather than
> substituting the fonts the PDF vendor thinks it best to substitute?

If the font is copyrighted, and there is meta information in the font
file indicating that it is illegal to embed the font in a document,
there may be nothing you can do. A polite PDF creator will honor the
copyright, and use a different font.

[Andreas Prilop]

On Thu, 27 Sep 2012, Jukka K. Korpela wrote:

> So automatic and largely undocumented font mapping is taking place.

This is well known and well documented:
http://www.google.co.uk/search?q=Windows+Registry+FontSubstitutes

[Jukka K. Korpela]

2012-09-28 20:31, Andreas Prilop wrote:

> On Thu, 27 Sep 2012, Jukka K. Korpela wrote:
>
>> So automatic and largely undocumented font mapping is taking place.
>
> This is well known and well documented:
> http://www.google.co.uk/search?q=Windows+Registry+FontSubstitutes

Thanks for the tip, but I cannot call it well documented when you need
to open the Windows registry and look for specific items there, namely
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\FontSubstitutes
and you will then only find out what the mapping is in your computer.
You cannot tell whether they are so by system (factory) defaults or
partly affected by software installed – and whether other people have
the same settings in their computers.

After all, a web author for example should worry about what happens on
visitors’ computers when he uses a font family name.

Apparently it is not well known either. When I have mentioned such
phenomena, people – even IT professionals – have been rather surprised.

Most of the settings appear to be rather irrelevant, except for mapping
Helvetica to Arial and Times to Times New Roman. I can see some oddities
like mapping Helv to MS Sans Serif and Tms Rmn to MS Serif, but
otherwise the mappings. Othr mappings are more obscure, like mappaing
“Arial Greek,161” to “Arial,161”.

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

[tlvp]

On Fri, 28 Sep 2012 19:31:23 +0200, Andreas Prilop wrote:

> On Thu, 27 Sep 2012, Jukka K. Korpela wrote:
>
>> So automatic and largely undocumented font mapping is taking place.
>
> This is well known and well documented:
> http://www.google.co.uk/search?q=Windows+Registry+FontSubstitutes

Well, thanks for making this "well-known and well-documented" information
(all of it new to me) more widely available here at least. Cheers, -- tlvp

[tlvp]

On Wed, 26 Sep 2012 05:29:09 -0400, David Lasher wrote:

> ... a Firefox add-on that simply tells you what fonts are actually

> used on a page.
> https://addons.mozilla.org/en-US/firefox/addon/fontinfo/
>
> David

Got it. Thank you! Cheers, -- tlvp

[Andreas Prilop]

On Fri, 28 Sep 2012, Jukka K. Korpela wrote:

> Othr mappings are more obscure, like mappaing “Arial Greek,161”
> to “Arial,161”.

161 denotes the Greek code page 1253:
http://msdn.microsoft.com/en-us/library/cc194829.aspx
These mappings are important for documents created by (older) programs
that use(d) different names for different code pages, for example
Arial Greek, Arial Cyr, Arial CE, Arial Baltic.

In terms of CSS, this means {font-family: 'Arial Greek'} .

[Jukka K. Korpela]

2012-09-29 17:27, Andreas Prilop wrote:

> On Fri, 28 Sep 2012, Jukka K. Korpela wrote:
>
>> Othr mappings are more obscure, like mappaing “Arial Greek,161”
>> to “Arial,161”.
>
> 161 denotes the Greek code page 1253:

The question arises what this means. How does character encoding relate
to a font? I could understand a setup where the number refers to the
encoding of the font, but this does not seem to be the case.

> In terms of CSS, this means {font-family: 'Arial Greek'} .

So this gets mapped to “Arial,161”. How does this differ from plain
“Arial”? A quick test suggests that there is no difference.


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

[Andreas Prilop]

On Sat, 29 Sep 2012, Jukka K. Korpela wrote:

> How does character encoding relate to a font?
>

> So this gets mapped to “Arial,161”.
> How does this differ from plain “Arial”?

http://www.microsoft.com/typography/links/news.aspx?NID=901

I’ve lost interest in this thread.