> Thank you for taking the trouble to try this. Indeed we both seem to > come to the conclusion that it isn't working. But I don't know how to > discern whether it's the WEFT3 tool or MSIE which is the problem, > since there seem to be no detailed diagnostics for what's been put > into the downloadable font.
> However, I do have a further question for you. When I try to display > your page (URL above) on MSIE6, I get empty rectangular boxes, which > is the same as what I get when no downloadable font is specified, and > no appropriate font is installed/available for MSIE to use.
Set this: Tools/Internet Options.../Security tab/Internet web content zone icon/Custom level/Downloads section/Font download/Prompt
so that you can see/use/temporary install/download the webfonts by clicking Yes when the prompt alert pops up or you can see the assigned or available font by clicking No when the prompt alert pops up.
I see rectangular boxes when I click Yes but I see all the correct glyphs when I click No because nunacom is [permanently] installed on my system.
> However, when I try my own version of this, I get rectangular boxes > with diagonal crosses through them (as I mentioned before). The > diagonal crosses go away if I comment-out the specification of the > downloadable font (@font-face stanza specifying the .eot file) in the > CSS.
I don't know. You need to indicate to WEFT where on the web (domain name) and where on your computer (local drives) you will be using the webfonts.
> I note that the MS WEFT documentation talks about permissible URLs > from which the downloadable font can be used. Maybe the presence or > absence of these diagonal crosses is indicative of an error in that > area?
I don't know. Not sure.
I *thought* I had specified the permissible URLs correctly when
> I made the downloadable font, but maybe not - I'm new to this WEFT > tool.
> If you happened to know, one way or the other, what these diagonal > crosses mean, it would be helpful.
I don't know.
If it seems useful (and if you
> would consent to a lightly-modified version of your own HTML file > appearing in my test area, at least while we discuss it), I could try > to put this up on our web server.
Well, just ask. What do you want me to do/change exactly? What do you need?
> Well, just ask. What do you want me to do/change exactly? What do you need?
I tried to subset code2000's Canadian Aboriginal Syllabics in WEFT but this range isn't listed. Some others are not either like Ethiopic and Cherokee. code2000 does not support the Canadian Aboriginal Syllabics, Ethiopic and Cherokee (1200 to 167F).
If I could have an 1400 to 167F unicode font installed, I might be able to do with WEFT a real accessible and web standards webpage.
On Mon, 10 Oct 2005, Gérard Talbot wrote: > Alan J. Flavell a écrit :
[...]
> Set this: > Tools/Internet Options.../Security tab/Internet web content zone > icon/Custom level/Downloads section/Font download/Prompt
Matter of fact, on the office machine where I had this working, that setting is imposed by non-optional policy anyway.
> I see rectangular boxes when I click Yes but I see all the correct glyphs when > I click No because nunacom is [permanently] installed on my system.
Thanks - that's useful input, I think.
> > However, when I try my own version of this, I get rectangular > > boxes with diagonal crosses through them (as I mentioned before). > > The diagonal crosses go away if I comment-out the specification of > > the downloadable font (@font-face stanza specifying the .eot file) > > in the CSS.
> I don't know. You need to indicate to WEFT where on the web (domain > name) and where on your computer (local drives) you will be using > the webfonts.
Indeed, I understood that much - but I wasn't sure if I was doing it right :-{ But see other followup, which I'm just about to compose.
> > If it seems useful (and if you would consent to a > > lightly-modified version of your own HTML file appearing in my > > test area, at least while we discuss it), I could try to put this > > up on our web server.
> Well, just ask.
I just did ;-)
> What do you want me to do/change exactly?
I don't want you to change anything. I just want you to say that you won't pursue me for copyright infringement if a modified version of your page appears (temporarily, at least) in the test area on our server.
On Mon, 10 Oct 2005, Gérard Talbot wrote: > I tried to subset code2000's Canadian Aboriginal Syllabics in WEFT > but this range isn't listed. Some others are not either like > Ethiopic and Cherokee.
I see what you mean...
> code2000 does not support the Canadian Aboriginal Syllabics, > Ethiopic and Cherokee (1200 to 167F).
Curious. According to SIL ViewGlyph, the font *does* contain the characters. But according to the MS Font Properties Extension, there's no indication that the font supports these writing systems in so many words, although there are some cryptic indications:
Reserved for Unicode SubRanges Bit xx
for various values of xx. This notation was unfamiliar to me. But the values 75, 76 and 77 are amongst those present (see below why this is significant).
> If I could have an 1400 to 167F unicode font installed, I might be > able to do with WEFT a real accessible and web standards webpage.
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, and *again* there's this mention of "Reserved for Unicode SubRanges Bit xx", in this case for values 76 and 77.
Indeed, bit 75 is Ethiopic, 76 is Cherokee, and 77 is Unified Canadian Aboriginal Syllabics.
So it appears that these fonts are correctly marked, but the diagnostic tool that I'm using (MS Font Properties Extension) doesn't know how to correctly report them.
And it further seems that WEFT3 doesn't know either, based on what you are reporting, and on what I also saw for myself.
However, MSIE6 *does* understand them, seeing that it's quite happy via its "Internet Options"> "Fonts" dialog to select a default font for "Canadian Syllabics", and offer a selection list which contains (in my case, provided that they are installed) precisely these two fonts, no more and no less.
Seems to me that we need an updated version of WEFT before we could progress this any further. (I bet this would have been quite easy with open source, grumble...).
On Mon, 10 Oct 2005, Gérard Talbot wrote: > Without the nunacom font, the word we see/can read is "eu3DN4tsJ5" > and taht is what is in the page as ascii (basic latin).
Which, according to HTML standards, *is* what the page contains. That was my point.
Changing the encoding from ascii to utf-8 *in no way* improves that situation, since for characters 0-127 the two encodings are identical.
*With* the nunacom font (which I categorise as "faked"), one may see something different, in fact one may get the visual impression which the misguided author intended. However, I repeat that this does not accord with the HTML specification - it's a fake.
Your postings have gradually moved towards agreeing with me on this, without quite saying it in as many words.
On Tue, 11 Oct 2005, Alan J. Flavell wrote: > But according to the MS Font Properties Extension, > there's no indication that the font supports these writing systems > in so many words, although there are some cryptic indications:
> Reserved for Unicode SubRanges Bit xx
> for various values of xx. This notation was unfamiliar to me. > But the values 75, 76 and 77 are amongst those present
On Mon, 10 Oct 2005, Gérard Talbot wrote: > When I double-click on the filename, I get the Inuktitut alphabet at the > place of the basic latin ascii (32-128).
Can't you see the contradiction? The Inuktitut alphabet is obviously NOT basic Latin.
On Tue, 11 Oct 2005, Andreas Prilop wrote: > On Mon, 10 Oct 2005, Alan J. Flavell wrote:
> > Canadian Syllabics.[1] > > [1] It might be that Google doesn't yet index Canadian Syllabics,
> Why not?
I pasted-in what I took to be a "word" from a properly-encoded web page (one that I had made myself locally), and Google found no matches for the word.
You can now use this page from Gérard Talbot - http://www.gtalbot.org/DHTMLSection/ImprovedNunacomDemo.html - as an online example to use in your search. Again I find no matches for any of the words, leading me to conclude that Google isn't indexing them. Also, Canadian Syllabics is not one of the writing systems mentioned on their languages page, nor are the associated individual languages, not even on the Canadian Google page: http://www.google.ca/language_tools
I think that proves that Google has indexed a (primarily Latin-1) web page which happens to contain some of the relevant characters - but that wasn't what I was investigating. A search for those characters themselves, nor words built with them, does not produce any web pages. "Unless you know better".
On Tue, 11 Oct 2005, Alan J. Flavell wrote: > You can now use this page from Gérard Talbot - > http://www.gtalbot.org/DHTMLSection/ImprovedNunacomDemo.html - as an > online example to use in your search. Again I find no matches for any > of the words, leading me to conclude that Google isn't indexing them.
> A search for those characters > themselves, nor words built with them, does not produce any web pages.
I don't know any other pages with *words* of such characters. So let's wait until the above page is in Google's index. (I have submitted it to Google.)
>>Without the nunacom font, the word we see/can read is "eu3DN4tsJ5" >>and taht is what is in the page as ascii (basic latin).
> Which, according to HTML standards, *is* what the page contains. > That was my point.
I see your point. I understand. But wouldn't it more accurate to say that such nunacom font was not properly coded, constructed from a unicode point of view? was not properly constructed according to Unicode standards... back in may 1999...
> Changing the encoding from ascii to utf-8 *in no way* improves that > situation, since for characters 0-127 the two encodings are identical.
Yes. I understand that.
> *With* the nunacom font (which I categorise as "faked"),
When you first mentioned the "faked" adjective in this thread, I thought you were referring to the webfont... not to the nunacom font itself.
"Ontologically" speaking, a webfont is a synthesis/synthetic font. Webfont tools analyze font description matters (panose, hinting instructions, metrics, language information, ascent, descender, attachment points for diacritical marks, etc..) which are supposedly included into a font and then creates/renders/synthesizes the glyphs on a webpage. That is what I understand on that issue.
one may see
> something different, in fact one may get the visual impression which > the misguided author intended. However, I repeat that this does not > accord with the HTML specification - it's a fake.
I understand. nunacom font is not a well constructed font. It should have put those characters at the proper place, in the 1400-167F range.
> Your postings have gradually moved towards agreeing with me on this, > without quite saying it in as many words.
On Tue, 11 Oct 2005, Andreas Prilop wrote: > It takes some time before a (new) page gets into the index.
Sure! I was hoping that Google would find this word somewhere else.
> I don't know any other pages with *words* of such characters. > So let's wait until the above page is in Google's index.
Here's a search string which will find you some pages already known to Google, and which contain some properly-formed Can.Syl strings:
"Please download a Languagegeek.com font to view"
But when asked to search for those Can.Syl strings, Google comes up empty handed. I can't see any other explanation than to assume that Google isn't indexing these strings. (Yet, anyway).
> On Mon, 10 Oct 2005, Gérard Talbot wrote: > 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. I agree ... it's not well designed...
> and *again* there's this > mention of "Reserved for Unicode SubRanges Bit xx", in this case for > values 76 and 77.
I almost achieved a version which would render correctly on a system with Aboriginal Sans installed and without Aboriginal Sans in MSIE 6. I see some characters replaced with rectangles with the large X inside. I believe these indicate failures of converting the font characters at a certain code position into synthetic glyphs. WEFT 3.2 might have a bug ... hard to say.
Try this:
Load Aboriginal Sans into WEFT 3.2 (v. 5.3.2). 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. Hmm.. There ought to be a way to better do this. There is a webpage analysis tool... hmm.. it seems that 19 characters can not be embedded. Still trying...
> when I try my own version of this, I get rectangular boxes > with diagonal crosses through them (as I mentioned before). The > diagonal crosses go away if I comment-out the specification of the > downloadable font (@font-face stanza specifying the .eot file) in the > CSS.
> I note that the MS WEFT documentation talks about permissible URLs > from which the downloadable font can be used. Maybe the presence or > absence of these diagonal crosses is indicative of an error in that > area?
I believe these rectangular boxes with diagonal crosses indicate failure/inability of WEFT software to convert the character into a synthetic glyph for possibly various reasons.
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:
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...
>>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:
It works! No problem whatsoever with MSIE 6. With the use of the eot file or without it (since I have the font Aboriginal Sans installed already).
> 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?
I think (not sure) "*" means that it's a subset.
> This "web" font (.eot file) is 107kB
Yeah.. I noticed it was rather long for that file to be loaded. Ideally, would be to subset the characters needed from the Aboriginal Sans font.
> 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.
Yes.
> But I honestly don't know *what* characters the WEFT tool has really > stashed into this web font.
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. I see no problem with this.
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 noticed that too. No 2nd download of the webfont. I know that the webfont is temporary installed in the Temporary Internet Files directory.
Do: Tools/Internet Options.../General tab/Settings... button/ will show the current location of your Temporary Internet Files directory. 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.
So I believe the webfonts are just reloaded from cache.
> 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:
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.
>>>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 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.
> I've kludged up the following URLs, using material
> from my normal unicode test area, to help in diagnosing the situation:
If you could change the file extension to html, I would try this feature.
> 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.
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.
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. So I let Weft figure this out:
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.
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.
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, 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?
> "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.
Ok. You can remove these files, as you wish. I've saved them.
> 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,
Hmm.. not sure how/if I could figure this out.
> 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. 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.
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.
|
