Suggest a Topic!

re: Suggest a Topic!

Jan Kučera — Mon, 10 Nov 2008 13:22:14 GMT

Greetings! What references (and advices) would you suggest to someone considering implementing a complex script rendering engine? (on a platform where there is no such available of course :-))

Jan

re: Suggest a Topic!

Michał — Mon, 12 Jan 2009 15:09:01 GMT

With Dr. International (http://blogs.msdn.com/drintl/) being inactive for years - who's gonna write "Developing International Software, Third Edition" now? I think there is still some stuff missing:

- localized size units (French "octets") to cover...

- the Japanese (and Korean) path separators...

- more information on registry keys and paths translated in localized OSes...

Cheers,

Michał

re: Suggest a Topic!

locale breaks gets/printf — Mon, 12 Jan 2009 22:16:50 GMT

Hi. Here's a little program. I know it's not unicode, but the product I'm working on is 14yrs old, so it's just too late for that.

#include <iostream>

void info()
{
char line[1024];
printf("\n Input via gets() ");
gets(line);
printf(" Echo via printf() %s\n",line);
}

int main(int argc, char** argv)
{
info();
setlocale(LC_CTYPE,"");
info();
return 0;
}

So, on my dos console, built from visual studio 98, this works just fine, but built from visual studio 2008 the characters no longer round-trip.

For example, after the setlocale call, ALT+252 shows SUPERSCRIPT LATIN SMALL LETTER N as expected from cp437. And the byte from gets is xFC as expected. But when you give xFC to printf, it displays as LATIN SMALL LETTER U WITH DIAERESIS as would be expected from cp1252.

Now I realize that I can work around this by using ReadConsole/WriteConsole instead, but isn't is a little insidious that on a completely default system, using basic calls like gets/printf/setlocale, simple IO doesn't round-trip?

Maybe I'm missing something, but it seems like someone has intentionally gone out of their way to make me suffer.

I'd love to know why.

Thanks.

P.S. why call setlocale? Because we always have, and they're scared of what will happen to the database drivers, etc. if we change it.

P.S. why care about non-ascii? Because many apps talk to our db and all latin1 is legal. We've already gone to a lot of trouble to avoid best-fitting when printing to the console, and the new behaviour destroys that.

re: Suggest a Topic!

DreymaR — Wed, 21 Jan 2009 12:01:03 GMT

Hello Michael, and thanks ever so much for sharing insights about the workings of the Windows layout routines!

I hope you're the person to ask about this, or if you aren't, that you could tell me who might be?

In these days I'm very portable, and happily so. I 'take my digital life with me' by USB flash drive, and this allows me to work comfortably on computers where I have no installation rights. That's nice!

When it comes to the keyboard layout however, I'm not yet fully satisfied. I've used MSKLC to make an enhanced layout (Unicode, some keys moved around etc) that I'm very fond of. I can use the freeware script PortableKeyboardLayout to take that with me, but this solution is imperfect because it's too slow at times (it's written in a scripting language) and doesn't always play 100% nice with the input stream. (It has other virtues, but that's another matter.)

So what I'd really like would be to be able to code or script an analogue to the LoadKeyboardLayout API, that instead of looking in the registry and system folders could take its values from a specified file and an MSKLC-made install! (I hope I'm right in thinking that what the MSKLC installer does is detect the architecture and then simply copy the right .dll and some registry values to where the system expects them to be?)

That way, I could run a script or program that loaded and activated a layout from my USB drive, without installing anything to the local hard drive! Any tips/ideas whether this is doable and if so, how?

re: Suggest a Topic!

Gene Sorensen — Thu, 19 Feb 2009 04:02:47 GMT

Hi Michael,

I have created a keyboard for the Iñupiaq language using MKLC. In the properties I named it Iñupiaq, not Inupiaq. If I hover my mouse over the .dll the context menu says it is the "Iñupiaq US Keyboard Layout," etc. However, when I install it in the US version of Vista or XP the Language Bar displays its name as "Inupiaq," without the ñ. If I go into "Add or Remove Programs" in Control Panel it is correctly listed as "Iñupiaq". It appears the system will use the ñ in some places, but not in others. Is there a way to get the Language Bar to show the ñ?

Thanks,

Gene

re: Suggest a Topic!

dmelliott — Wed, 08 Apr 2009 12:10:26 GMT

I read what I could find about fonts installed in the system not being installed in IE, but I could not find anything about how to solve the problem. I would assume registry hacks?

re: Suggest a Topic!

Jan Kučera — Sat, 18 Apr 2009 15:58:12 GMT

Hi, glad to see you back, Michael!

Actually I've already tried twice to post the following question some time ago, but it did not go through. However, I know how you like sorting topics, so I thought I might try it once more… here we go:

Say I have a web page, and I'm providing the content in several languages. Now the question is, what do you thing is the best way to present the languages available, in which language and the most interesting – in which order?

I've told to myself – okay, let's see how the MSDN does it. If I open the MSDN web, I see "Česká Republika - Česky" in the top right corner. Hmm well, if you happen to not know the Czech language, I guess you have no idea this is the language selector. Anyway, here is the list expanded:

Argentina (Español)

Australia (English)

Brasil (Português)

Canada (English)

Canada (Français)

中国 (简体中文)

Colombia (Español)

Deutschland (Deutsch)

España (Español)

France (Français)

India (English)

México (Español)

Perú (Español)

Россия (Pусский)

United Kingdom (English)

United States (English)

What is the reason for listing the country first and then the language? I also see both country and language are displayed in the native language, which prevents you discovering the selector if the page is displayed in a language you are not familiar with. Now after couple of your posts about sorting, I see this list is sorted neither by language, nor by country (the non-Latin characters would go down, right?). So my first guess is that the list is sorted by country language in English – an item not in the list – a bit confusing, especially if you don't know the English names – though quite interesting idea for me. And now, what sort is used? Assuming the 中国 thing is China, it seems to be sorted using English rules, because in Czech (in which the web is shown), this would go after Colombia. Wasn't it me to whom did you advised to use the sorting expected by the user? Funny is that if you click to display more languages, the combo box is sorted different way, I would say by native country names (non-Latin at the bottom), accent insensitive (Česká republika before Chile) using English rules (Chile before Colombia) – at least that page is in English only. Though for me, looking for Česká republika in the middle of 'C' names is really weird.

Looking at another sites, I see everyone implemented it differently. So...I wonder, do you have any thoughts what could be the most correct way?

Thanks!

re: Suggest a Topic!

Jeroen Ruigrok van der Werven — Fri, 08 May 2009 17:38:16 GMT

Hi Michael,

any idea why the locale identifier is missing for Corsican at http://msdn.microsoft.com/en-us/library/ms776260(VS.85).aspx ? I already left a note at the bottom of the page, saying that it should be 0x0483 as according to http://msdn.microsoft.com/en-us/library/dd318693(VS.85).aspx .

Also, what additional locales does Windows 7 have over Vista?

re: Suggest a Topic!

Bruce Rusk — Wed, 24 Jun 2009 09:09:12 GMT

Michael,

Here's the deal: I'm loving the new IMEs installed with the East Asian language packs for Office 2007 (running under XP Pro). They are a significant improvement over past offerings.

The Chinese (Traditional) New Phonetic IME in particular is wonderful for me because it includes the whole CJK range, including Extensions A and B (well, presumably those characters within that range for which the Unicode database has Mandarin readings, at least using phonetic input).

There is a significant issue in how the IME displays characters for selection. After including CJK Extensions A & B (in the properties dialog, under General -> Character set), the whole range is available to input -- I think. See, what happens, so far as I can tell, is this: the IME candidate window shows basic CJK characters in black, Extension A characters in green, and Extension B characters in red. But on my system at least, the green characters show up only as those nasty character-not-found boxes. The Extension B ones appear quite nicely (so there's a bunch of black characters and a bunch of red ones, with the green boxes in the middle).

I've checked and do have fonts that support both ranges, but a different set for each and none that covers both fully. I've also noticed that, while the older version of MingLiu supplied with XP does not have the Extension A characters, the newer version that comes with Vista does--could that be what the IME is looking for?

Any ideas about what might be going on?

re: Suggest a Topic!

PerryN Newton — Wed, 22 Jul 2009 11:56:33 GMT

Michael,

Your blogs are very interesting reads and very informative - thanks!

Observation - you seem very informed on calendars and date functions, and have written several posts relating to them.

Question: Have you ever tried to import Visual FoxPro table data that simply lists U.S. Presidents and their birthdates into SQL-Server?

Suggestion: When I last tried this, using VFP 6.0 and SQL-Server 6.0 I would always get an error and discovered it was a limitation of the beginning date recognized in SQL-Server and I wondered if this limit has been since documented (KB) or modified by subsequent SQL-Server versions.

Thanks for all you do and share!

re: Suggest a Topic!

Santhosh Pillai — Thu, 27 Aug 2009 09:43:45 GMT

Question: Does Windows 7 provide OS level support for any non-Gregorian support, such as switching your calendar?

Also, are there any online calenders that you know of that support non-Gregorian other than (Google Calendar)?

re: Suggest a Topic!

Vincent — Sat, 26 Sep 2009 04:15:01 GMT

Why does Syriac display so poorly in WPF?

If you enter Syriac with vowels, the letters don't join as they should, often using the wrong form of the letter (final instead of medial or initial, etc.). The Syriac abbreviation mark doesn't function at all. You cannot combine a Fatha and Kasra on the same consonant. The tatweel won't join with consonants.

All of this is true in the .NET 4.0 Beta as well as the shipping version, so no progress has been made since initially reporting these issues over a year ago.

Syriac in WPF is just gibberish. The last time I reported these bugs, someone from Microsoft tried to blow me off by suggesting that Syriac wasn't a supported script in WPF, even though it is clearly listed as supported on Microsoft's website. What gives? The Office team doesn't have this many problems with Syriac, why can't the WPF team get it right?

re: Suggest a Topic!

alexcohn — Tue, 29 Sep 2009 17:58:19 GMT

I would like to find a way to enable Uniscribe bidi support in Windows Mobile. The available solutions by 3rd parties are expensive and use dangerous hooks all around the system. Furthermore, they are not standard, and it is a burden on aplication developers to look for glitches with each one of these tools.

What does it take to build Uniscribe - enabled smartphone? If it requires special licensing, who may be a relevant point of contact in Microsoft?

re: Suggest a Topic!

William Overington — Tue, 20 Oct 2009 16:40:10 GMT

Hi Michael

Could you possibly consider having a look at the problem in the following thread please?

http://forum.high-logic.com/viewtopic.php?f=3&t=2839

It is a problem with making a font for use in Word (2003) using some rarer scripts.

Thanks

William