Re: Embedding fonts

On Tue, 11 Oct 2005, Gérard Talbot wrote:

Alan J. Flavell a écrit :
AbSans (Aboriginal Sans) *also* contains the characters, and *also*
for this font there's no mention in the MS Font Properties Extension
that it supports these writing systems,

Well, the characters are listed under Language: "Private Use Area"
in the Subset Editor.

Gosh, well spotted! So it does. However, these *do* seem to be
the PUA "per se", as opposed to the U+14xx... range that we are
looking for. Are you in fact seeing anything more in this area than
the PUA itself?

I'll come back to that point in a moment...

I agree ... it's not well designed...

Basically the "subset editor" seems to lack any facility to access the
parts of the Unicode table that it hasn't already been told about.
And U+14xx etc. (Canadian Syllabics) isn't one of them.

I almost achieved a version which would render correctly on a system with
Aboriginal Sans installed and without Aboriginal Sans in MSIE 6.

But were you using characters (or &#number; references) from the
U+14xx area, or from the PUA?

(ViewGlyph can display the font's Cmap table, but the PUA entries seem
to be pointing to *different* glyph positions than are the entries in
the U+14xx area. So it's not as if these are synonyms for the same
glyphs. Unless you know better!)

I see some characters replaced with rectangles with the large X
inside.

OK

I believe these indicate failures of converting the font characters
at a certain code position into synthetic glyphs.

So it seems...

WEFT 3.2 might have a bug ... hard to say.

hmmm...

Try this:

Load Aboriginal Sans into WEFT 3.2 (v. 5.3.2).

Confirmed that's also the version that I downloaded from Galactic^W
the MS web site.

Add it in the list of fonts to embed (Add... button), then click the
"Subset..." button and then add manually each of the characters
needed in the document.

OK. Curious thing to me is that what appear to be similar glyphs in
the PUA and in the U+14xx area, appear to be listed in the Cmap table
(as reported by ViewGlyph) with different glyph IDs and different
"postscript names".

Hmm.. There ought to be a way to better do this. There is a webpage
analysis tool... hmm..

Yes, but the analysis tool fails in a similar way to any manual
attempt to access the U+14xx area directly! I'd dare to say: "no
additional surprises there".

I'll take a further look at this myself later. *Many thanks* for
posting your observations so far - this is most interesting. I hope
it turns out to be useful, too! Is it time for some of us to write to
the MS contacts for WEFT and ask about an update?

On Wed, 12 Oct 2005, Alan J. Flavell wrote:

Gosh, well spotted! So it does. However, these *do* seem to be
the PUA "per se", as opposed to the U+14xx... range that we are
looking for. Are you in fact seeing anything more in this area than
the PUA itself?

OK, here's my first stab at a test, but *beware* of the downloaded
font:

http://ppewww.ph.gla.ac.uk/~flavell/...nacomDemo.htm8

I somehow seem to have made a massive embedded font, merely by
choosing the "Private Use Area" in the font subset editor.

Even stranger, whereas SIL ViewGlyph reports that this font has 4,892
glyphs in it, MS WEFT reports the number of characters in the font as
"*6399", whatever the "*" might mean?

This "web" font (.eot file) is 107kB

At any rate, it appears to put MSIE in a position where it's capable -
even though I de-installed my Can.Syl-capable fonts - of displaying
these characters - as specified by their real (U+14xx etc.) character
positions, without using the PUA.

But I honestly don't know *what* characters the WEFT tool has really
stashed into this web font. It's not merely the PUA, I feel sure,
even though in the subsetting UI, the only characters which I could
see seemed to be the PUA characters.

And, something very odd is happening. When I allow the .eot file to
be downloaded, some of the characters on the test HTML page aren't
rendered. But MSIE then seems to remember this font somehow, and if I
reload the page and, this time, refuse to download the font, then the
page seems to be rendered correctly. Strange. I might mention that
the font was designated "Installable" in the list of available fonts.
Could it be that Windows has kept a sneaky copy of it somewhere, even
though it doesn't appear in the fonts control panel? Unfortunately I
don't now know how to get rid of it...

This is all rather confusing. But there's a semblance of almost
working...

cheers

On Wed, 12 Oct 2005, Gérard Talbot wrote:

If it's 107KB, then it's most likely all of the characters of the font.

I note you renamed the font to mynuna too; that's interesting.

This was a diagnostic technique suggested in the MS pages:
http://www.microsoft.com/typography/...3/trouble.aspx

I noticed that too. No 2nd download of the webfont. I know that the
webfont is temporary installed in the Temporary Internet Files
directory.

Yes...

When in that directory, you can sort the type of file and then find
the .eot files that you have recently downloaded: their internet
address will be listed.

Confirmed. However, even if I delete the file from there, and reload
the browser - refusing the downloaded font, I can't now get IE to
forget how to render these characters. Even when I haven't got an
installed font for them. Very odd.

On Thu, 13 Oct 2005, Alan J. Flavell wrote:

On Wed, 12 Oct 2005, Gérard Talbot wrote:


When in that directory, you can sort the type of file and then find
the .eot files that you have recently downloaded: their internet
address will be listed.

Confirmed.

Sorry for following-up to myself, but I need to correct the following
bit:

However, even if I delete the file from there, and reload
the browser - refusing the downloaded font, I can't now get IE to
forget how to render these characters. Even when I haven't got an
installed font for them. Very odd.

I *have* now persuaded IE to forget the downloaded font, although to
be honest I'm not exactly sure which it was of the various things I
was trying.

Going back to what you were saying before, though, it *does* rather
look as if only a proportion of characters are working from this
downloaded font. I've kludged up the following URLs, using material
from my normal unicode test area, to help in diagnosing the situation:

http://ppewww.ph.gla.ac.uk/~flavell/...unidata14.htm8
http://ppewww.ph.gla.ac.uk/~flavell/...unidata15.htm8

View these URLs in MSIE and in a situation where there is no installed
font for viewing the Can.Syl repertoire (this can be verified in MSIE
by going Tools> Internet Options> Fonts..., selecting the "Language
script" of Canadian Syllabics, and verifying that there are no fonts
available there to be selected - but you already knew that).

As yet, I don't know what characterises those which are working, from
those which aren't. I just present these observations.

On Tue, 8 Nov 2005, Gérard Talbot wrote:

I think I found a way to go around this issue... sort of. You can
ask WEFT to analyze the webpage and then figure out the characters
which will be needed from which fonts.

Indeed you can, in fact that's how WEFT is *supposed* to work, but at
my first attempt (with this Unicode range, which post-dates the latest
WEFT version, 3, that I found) it hadn't seemed to be working.

I've kludged up the following URLs, using material
from my normal unicode test area, to help in diagnosing the situation:
http://ppewww.ph.gla.ac.uk/~flavell/...unidata14.htm8
http://ppewww.ph.gla.ac.uk/~flavell/...unidata15.htm8

Really, those are of no further use now, as they reference the
incomplete downloadable font which I was testing. But if you still
want to see how far I got...

If you could change the file extension to html, I would try this
feature.

Sorry, I don't understand why that's a problem? "htm8" is just a local
server convention for getting the server to advertise utf-8 encoding.
Well, alright: try the same URLs ending in .html (which will be served
with the page encoding advertised as iso-8859-1) or ending in
..utf8.html , whichever appeals to you. I've symlinked these
alternative URLs in the /tests/ subdirectory.

But as soon as they have fulfilled this purpose I'd expect to remove
them, as you have already achieved better results.

http://www.gtalbot.org/DHTMLSection/...SerifDemo.html

ABORIGI4.eot and ABORIGI5.eot are 25KB each and holding 19
characters each.

WEFT was able to analyze the webpage and then figure out the required
characters from the Aboriginal Serif font.

Well done.

On a different note, I downloaded Pigiarniq font from
http://www.gov.nu.ca/Nunavut/English/font/
and couldn't figure out where the Inuktitut characters were.

SIL Viewglyph shows them to be in their proper place, U+14xx and
U+15xx, I'm relieved to say. There's some other glyphs in the PUA
(U+E002, U+E008, U+F7xx etc.) but your sample doesn't seem to make any
use of them - which is good in terms of web compatibility.

So I let Weft figure this out:

PIGIARN1.eot is 17.2KB

http://www.gtalbot.org/DHTMLSection/...SerifDemo.html

So, both of your test pages are displayed OK here on Mozilla (when I
have appropriate fonts available locally), and on IE6 using the
downloaded font (even when I haven't got a suitable font available
locally). Good stuff.

If/when I get a bit of spare time, I'd like to understand why that
didn't work for me, because you don't seem to be describing anything
different than what I was trying myself. But well done, anyway. You
going to write this up somewhere as a how-to?

cheers

On Wed, 9 Nov 2005, Gérard Talbot wrote, quoting me:

because you don't seem to be describing anything different than
what I was trying myself. But well done, anyway. You going to
write this up somewhere as a how-to?

No immediate plan to write an how-to document right now.. but it
certainly should be done somewhere. Too busy actually, stretched.

Understood...

But I did think I *must* warn the Nunavut government and other
Nunavut sites to stop promoting or using fonts which are not Unicode
compliant. Prosyl.ttf, which can be downloaded at
http://www.gov.nu.ca/Nunavut/English/font/ and nunacom.ttf
(downloadable at nunatsiaq.com) are good examples of a bad fonts to
download and to install.

Well, I think you have several W3C references to cite for that as bad
practice. So you should be all set to present a well-founded argument
(and warn against them continuing to develop a legacy of document
content which would need to be converted in due course if it's to work
properly with modern browsers).

These WEFT/MSIE downloadable fonts (of the Unicode kind we are
discussing, I mean, *not* the fake-Latin fonts) are just icing on the
cake, seeing that a properly-made and properly-installed Unicode font
has been proved to work with MSIE as well as with modern web browsers.

Incidentally I see that WEFT 3.1 was issued in October 2001, whereas
WEFT 3.2 is dated Feb 2003. Unicode 3.1.0 is dated March 2001, while
Unicode 3.2.0 is dated March 2002. Might there be some pattern to
this? But Canadian Syllabics were already present in Unicode 3.1.0,
so it's unfortunate that not even WEFT/3.2 supports them "in so many
words" - albeit you managed to tame it somehow.

all the best