December, 2008

A couple of days ago, I went out with the iBOT into the still uncleared snowed-over sidewalks.

It was a test -- I had some Christmas day plans (a bunch of Seattle orphans sans travel plans all heading to Amy's places the top of Capitol Hill for Jumbalaya and wine and conversation) amd I wanted to make sure the iBOT would be able to navigate through the snow successfully.

You know I can count on one hand the number of white Christmas years I've seen in Seattle since O first git here in '96 on one hand and have as heap of fingers left over, so this is all quite weird.

Anyway, the test was a success -- I was able to move around and up an down the street with minimal difficulty.

I let Amy know I'd make it and I even practiced on the stairs at my place so I'd feel comfortable with the whole "strange stairs/weird handrails" type cases that might confront me once I got there.

I was ready.

We heard about some rain being forecast, which is the usual way that the snow goes away.

The old question I recalled "when did Noah build the ark?" and its answer "Before the rain, before the rain" were in my mind, and I figured with rain coming then things might not even have needed me to do the extra practice.

No worries, I still felt ready.

And then the rain came.

After that came a bit more snow.

The end result was a slushy, crappy mess.

Heading out at 2pm for a 2:35 bus that usually took just a few minutes to get to, I felt like I left adequate time to get to the bus stop.

I made it out of the Cambrian with minimal effort, but once I hit the street (well, the sidewalk next to 40th), I was in a world of hurt.

I was stuck within ten feet.

It took me 16 minutes of moving back and forth, turning, and mode changing (up into balasnce and then jumping down to 4-wheel proved to be particularly useful at moving out of a slightkly stuck position!) to get turned around and back into the Cambrian.

I called Amy to let her know I was going to miss the Jumbalaya. She shared with me that I was not the only one bailing -- several others were worried about the trip to the top of Capitol Hill too. She might endcup with the lion's share of the food.

It also means canceled plans last night and today and probably tomorrow and maybe the day after that and...

It kind of sucked realizing that I was basically trapped in my apartment for the time being.

I have food and I have power and I have heat and I have Internet connectivity, so being stuck here is not such a bad thing.

But the realization that I was stuck here for who knows how long is a depressing one.

Of course I know that the scooter wouldn't have even made it out of the Cambrian -- so the iBOT has opened many doors here. But short of getting chains or studded snow tires on it, the iBOT is not going to get me through every door. Certainly no the door to the top of Capitol Hill....

Maybe I should look into tire chains for the iBOT tires? You know, for just in case? :-)

If you were expecting me to pop by the office tomorrow then consider this your notice that it ain't gonna happen. We'll try again next week, maybe.

This post brought to you by ♿ (U+267f, a.k.a. WHEELCHAIR SYMBOL) 

As the end of the year approaches, I guess it is a time for reflection.

Oh, I suppose resolutions for the new year. For those you can paste in mine from four years ago, as I am still striving on them.

2008 was kind of my worst year for as long as I have been alive.

The year Liz died (ref: Burying the lead, aka A weekend perfected not by art but by mortality for the magical last time I saw her and It's not (aka She's not) for when I first talked about her passing).

I feel like I am much less than I was before she died, like maybe just a shell of that person.

How can someaone who I talked to only occasionally and saw even less than that have such an impact?

I've talked to her sister a few times since then. I now know that Liz really did imagine we'd end up together eventually, that she had been carrying a torch for years. She called up her sister and cried when she heard I was engaged (especially to someone she didn't approve of but even so...). And she actually threw a party for her friends with the theme of "Dong Dong, the Wench is Gone!" when we called it off and we subsequently broke up.

That last trip, spending time with me here, was (reportedly in her own words, according to her sister) her "Hail Michael pass" -- a pass at me, one that she wanted to make at me. Her last chance, so to speak.

Calling the weekend a Hail Michael pass would probably have been the coolest back-formation ever (for a Hail Mary pass) were it not for the fact that because of my block the pass was incomplete.

Of course when I think about that, I just feel stupid -- how could I have missed it? We shared so much and knew so much about each other, how could I have misread her in this one area to such a degree?

Non-strategic blindness would have also made a good title for this blog. The weekend, in retrospect, feels to me like the ultimate collection of the mother of all tactical mistakes.

Since then I have found many new friends, people who by the simple fact that they live in or at least hang out in Seattle have dran me out of what would have been a shell due to the huge collection of people leaving town and leaving entirely looking now like a serious changing of the guard in terms of the people I spend at least some if not a huge horking bunch of my time with.

Tomorrow I'm heading to Seattle for a dinner for all the Emerald City orphans, and I am going so far as to say maybe to invites for New Year's parties though I haven't accepted any yet. Doing something festive on THAT holiday is a bit too soon for me, I think. Some of the parties sounded cool, but there is always some other year, some day.

The Casey at the Bat imagery is in my head and I can't shake it except by thinking about the Aimee Mann song (It's Not) which is actually worse from a mood standpoint. When I am around people it is not so bad, but I can't be around people all the time, so....

and thus it ends, with the fixed up version of the final verse:

Though I keep looking in her eyes as I search for answers
go through motions although I really can't say why
could I have fixed it all or done something different?
No way too say anything but goodbye.
and I can't close my eyes to pretend she's still there
'cause she's not.
I know she's not.
no she's not.

Not necessarily better, but at least the worst of the scansion problems are gone (since the orginal song had no problems, the difficulties did distract me). I have probably composed more verses to this song in my head then I will ever admit to anyone, ever.

And maybe a re-jiggered last verse of the Ernest Thayer poem:

Oh, somewhere in this favored land the sun is shining bright;
Yes lovers are kissing somewhere, no end to love in sight,
And somewhere, couples smiling, laughing as they all meet;
But there is no joy in Michael--- not since Liz's pass was incomplete.

I don't know. It I know only when I stop to think about it that I feel that awful, and I am busy enough to make sure that isn't so very often.

Maybe I should fly somewhere -- out of town, out of state, out of the country. I probably won't, since it wouldn't make anything better. But the sight of people glad to see me and be with me on that night would probably just make me feel bad that the iBOT has just a 15.5 mile range. I feel like I need to be much farther (and further) away....

This blog brought to you by ⧜ (U+29dc, aka INCOMPLETE INFINITY)

After reading It isn't really RED versus GREEN, Cheong asked:

I've searched for a while in charmap.exe and yet to find a font that'll display these characters in WinXP. That brings me to a question: Is there a font that ships with Windows (not necessarily WinXP or Vista... just any version. Maybe even a future version. :) ) that'll display most non-user-defined range of Unicode characters? Or at least that'll display most of the "sponsor characters" in your blog?

Sorry if this question has already been answered, because I've been yet to come up with effective keywords for this question.

For good measure, after a less than 24 hour wait he asked over in the Suggestion Box:

I'm refering to article titled "It isn't really RED versus GREEN"

I've searched for a while in charmap.exe and yet to find a font that'll display these sponsor characters in WinXP. That brings me to a question: Is there a font that ships with Windows (not necessarily WinXP or Vista... just any version. Maybe even a future version. :) ) that'll display most non-user-defined range of Unicode characters? Or at least that'll display most of the "sponsor characters" in your blog?

Sorry if this question has already been answered, because I've been yet to come up with effective keywords for this question.

Now I am not making fun of him, it was actually the Suggestion Box comment that reminded me about the question.

So what was done here was the right thing to do, at least insofar as right and wrong can be determined by whether a blog is inspired.

Don't look now, we are heading into an über-metablogong topic -- Blog morality! Where right and wrong is only defined in terms of the content of a Blog!

I'll revisit that topic again some day, since although it has the risk of playing out really dumb, I think I'll probably enjoy it. Though for now I'll go back to Cheong's actual question.... :-)

There is no font that ships with any version of Windows currently available that will handle any possible character that an ornery person like me sets up sponsorship details with.

On the whole, I have found that due to limitations like the one I described in The importance of Tagalog to Burmese, aka "Of course I'd lie to you, I'm a font!" that for many of the ranges outside the ones listed in the table in that blog, Firefox seems to do a better job finding fonts that will work than Internet Explorer does.Not so much that I'd yet claim such blogs on this Blog are "optimized for Firefox" because I still have an ECMA Script bug to track down. But maybe one day....

In he meantime, I find that for most of Plane 1 if you have a font that supports the character on your machine that Firefox seems to find it more often than IE does -- even IE8.

IE seems to be optimized for the fonts supporting languages that Windows claims support for, which one again suggests that a browser less interested in its idea to its OS has the opportunity to do better here. But that is just a theory.

My IE team advice would be to either take over MLang so you can update it, or dump it like a bad habit and find a way to support features that require forward looking thinking, like the aforementioned Tagalog/Burmese/Mongolian bug.

But to get back to Cheong's question.... :-)

I also do not know of future plans for such a font. Though with each version coverage gets better it is harder to imagine coverage of very obscure historic scripts with limited user communities a being a priority.

So I'd guess that, given the way I often to go to the more obscure parts of Unicode, you could not claim that Windows is optimized for this Blog, either.

Of course you have to realize that this argument is quite a specious tail-wagging-the-dog type argument, and not only because claiming that the reason one reads this blog is for the sponsoring character is like the person who claims to be reading Playboy for the articles (with the exception of Microsoft employees and I believe the July 1994 issue!).

This blog brought to you by ᜀ (U+1700, aka TAGALOG LETTER A)

YAIB -- yet another IBOT blog -- feel free to ignore if they aren't your thing...

Prior blogs in the series here and here and here and here and here and here and here and here and here.

This blog is going to be about the good, the bad, and the ugly.

As the title indicates, the three items will be covered in that order.

First, the GOOD.

Now I know the title of these blogs have implied a rolling comparison/contrast between the old world (scooting) and the new world of the iBOT® 4000 Mobility System.

And mostly I stopped bothering, since it was just better in every way and I was getting tired of beating up on the scooters that had been serving me so well.

In fact, I was wondering what I should do with the scooters now, and I was going to write about my thoughts on that subject -- but hold on to that thought, I'll get back to it in a moment!

There was a snowstorm in Seattle.

Now growing up in Beachwood OH, snow was never such a big deal. If a foot of snow hit the ground overnight, it just meant the snow plow drivers had to get up an hour earlier. The only time they used "snow days" at school was when teachers who live out of town could not make it to the school!

I'll talk more about my theories on Beachwood another time, for now I'm not going to get into it.

Anyway, there was a lot of snow in Seattle.

Most people were either trapped at home or unwilling to brave the roads; the campus was much emptier than usual and I myself stayed home Thursday and Friday, working from there.

I did have a lunch on Friday with a friend/colleague over in SQL Server so I braved the roads around noon or so. And once again I was amazed by the ease with which the 4-wheel mode handled the snow that was really still on the ground and the streets and the sidewalk.

I realized that if I depended on the scooter (either scooter), I would not be going anywhere -- the scooter wouldn't be able to take any of it.

Even on the Microsoft campus, where the roads and even sidewalks had paths more or less cleared, the scooter wouldn't have worked so well. Because the people clearing sidewalks had cleared the corner of every street only at the tip of the corner, ignoring the cutouts.

Had I not been in a wheelchair capable of handling curbs so easily, I'd be pretty screwed.

Iris and I were even talking a bit about the iBOT on our way to the cafeteria, and how cool it was even over rougher terrain. It was doing awesomely. I was playing it safe in 4-wheel mode but around my apartment I did a little balance mode stuff and it did a wonderful job of catching itself from dropping me.

Once again, I found myself being amazed at this truly wonderful device.

iBALANCE rocks.

Which brings me to the next part.

Next, the BAD.

I received a letter via FedEx next day air on Friday.

It actually came on Monday, but FedEx has stopped leaving notes on doors when they drop things off at the leasing office. So I didn't find out about it until Friday.

The FedEx envelope contained a single letter. I have scanned it here for your enjoyment (my apartment number obfuscated to maintain the myth of privacy in our world today):

So that's it.

Independence Technology, the subsidiary of Johnson & Johnson that markets, sells, and services the iBOT is going to stop the marketing and selling in January of 2009 and then stop the servicing in 2013.

My first thought was about the fact that anytime I watched a TV show when it was originally aired rather than recording it to watch later, the show got canceled. Could this iBOT news be related to the fact that I was given one? Geez I hope not!

My second thought was "good thing I still have the scooters!"

Now of course that was specious; the iBOT would have been out of warranty then anyway, but it is still quite disturbing and annoying as it pretty much makes the whole thing feel less stable even though there is little overall change in the stability of the platform that would impact me.

Did you know that the company that sends out someone to do on-sight service my iBOT is one of the same companies that sends someone out to do on-sight service for my Dell laptops?

Literally even the same engineers, sometimes.

Thus the specifications for repair will exist even after Independence Technology is gone, and obviously someone will be able to step up to do out-of-warranty service. With people like me stocking up on parts like tires and batteries and lights and such for those anticipated potential future visits, I'll feel pretty covered. Even moreso than most since I'll hoard my spare parts in case they become scarce at some point.

The only thing truly missing are the cases when the iBOT goes into a warning mode after recovery from a bad situation that requires a phone call communicating error codes and release codes to clear things up. That will need a solution too, whether it is just publishing the codes (my preference) or giving them to those service companies (the next best thing).

I was already planning on hacking the iBOT to pimp my ride after the warranty expired anyway, so perhaps I'll just go that route a bit too. We'll see -- pulling out the challenge/response table for error situations may be the only thing I steal off the computer if it isn't published somewhere when Independence Technology closes its doors. I see no need to much more to the computer -- I'd rather it not get changed too much at all if I can help it.

Okay, now this brings us to the next part of this blog.

And finally, the UGLY.

we'll start with the letter.

Dated the 12th (probably sent then, by next day FedEx without weekend delivery).

Arrived on the 15th.

Now according to folks at Independence Technology, they are not doing any more marketing at all -- in fact, anyone who is not already in the pipeline now and set to get their assessment done before March 2009 is not ever going to get an iBOT.

They took down the main information on the site, with the home page of the iBOT site (http://www.ibotnow.com/) containing little more than the following text:

Independence Technology L.L.C. is no longer selling and marketing the iBOT® Mobility System. The Company remains committed to provide technical support and service to all iBOT® Mobility System owners through the end of 2013.

If you are an iBOT® Mobility System owner, please be assured that you can call the Technical Support Center in the U.S. at (800) 463-3669 and in the U.K. at 0800 404 9605 anytime you have an issue with your device. All other inquiries should be directed to the Customer Zone at: (877) 794-3125.

We appreciate your interest in the iBOT® Mobility System.

With the link to the owner's area gone, anyone whodoes not have the link is kind of screwed until they remedy the situation (the link is http://www.ibotnow.com/ibot/ibot-owners.html for those people who have iBOTs who want easy access to all of the instructions to do things in more convenient ways than the manual says, like deep discharging and such.

But given the way this impacts USERS of the iBOT much more than anyone else, the way this was handled -- whether by Johnson & Johnson or by Independence Technology -- really kind of sucked. Way to breed panic to your customer base. :-(

Dean Kamen still owns the technology and has a lot of options on the service side after the company closes its doors, though many of those options will be limited by the potential liability issues. Though the whole "out of warranty" area does make something possible.

Even though no word on what might be happening, or even that anyone is considering coming up with a plan at some pont, was communicated, clearly there will be one.

Oh, by the way, none of this is news.

Neither Live News nor Google News was reporting on this at all as of a few minutes ago. Though both do cover the "news" of its FDA approval from years back and Google news noted a few very recent mentions of the iBOT:

1) an offhand suggestion in a Computerworld blog from Steven J, Vaughn-Nichols entitled Steve Jobs' health doesn't matter:

Could it be that Apple wants to hide a decline in his health? By not showing up, all Apple has done is fuel endless online speculation about his health. It would be better for Apple if Jobs showed up, if need be, in a wheelchair, perhaps in Dean Kamen's iBOT - it even has the right name!-- tricked out with Apple hardware, than to simply not be there.

Note that the blog is dated December 17th, five days sfter the non-news stor that the iBOT is no longer going to be available.

2) an article from the San Jose Mercury News from December 6th entitled Wish Book: Striving for independence, a story about how Ron Wexler's wheelchair is falling apart, and his dream chair is an iBOT. It concludes with the following text:

But the wheelchair, which employs three computers and six gyroscopes, costs $23,500. And an extra charger that Wexler could keep at work would cost another $550. Wexler has scheduled an iBOT test drive this month, during which a therapist will confirm that he is able to properly control the machine. Wexler is confident, but if the test drive doesn't work out, he would still need a similarly priced power wheelchair to guarantee his independence.

Wish Book readers' donations in increments of $50 can help make that happen for Wexler and ensure that his co-workers continue to benefit from his good nature and designer coffee.

FWIW, both the price of the chair (the iBOT is actually $26,100) and the spare charger (only $225 refurbished, which is almost certinly good enough for the second charger) reported aren't exactly right. A good example of professionalism and good fact checking from newspapers.Since the assessment is scheduled already he stands a chance of getting the chair if they get the money in before March.

3) a very poorly timed article in InventorSpot from December 1st by Beth Hodgson entitled The Year in Review: 2008’s Top Industries for New Businesses, which includes the following gem:

 

4. The Mobility Product Industry

This industry rolls up under senior care, so I needn't say why breaking into this industry is a good idea. New technology to improve the market of motorized scooters, wheelchairs, ramps and lifts are always becoming available; however, ‘interesting' or ‘unique' are terms that MOSTLY do not apply. I did say mostly; the IBOT 4000 Mobility System definitely ticks both of these boxes. It's essentially a wheelchair, but inventors of this product have taken it to a level seniors have never seen before, and in some ways I mean that literally. Even sitting in this device, seniors are at eye level, they can climb stairs, curbs and travel across just about any terrain. While this innovative product was not introduced in 2008, the newly released model included some great improvements like a fold-and-store design, more comfortable armrests and supports.

Wow, I wonder if they would have talked about it like such a top industry/business example if they knew that the company was getting out of the industry/business in half a decade?

Anyway, I guess we can blame Independence Technology for not issuing a press release -- had they done so, the news sites would doubtless have picked up the news. Note that regular web searches can find news (just include the number 2013  in your search and you'll find more articles covering the announcement that is now "news"....

I know that the folks at Independence Technology are working on a better plan here to talk about all of the issues here in more intelligent and reassuring ways. I guess in some ways it was handled better than the WinFS Update marking the death of WinFS, but from the point of view of an owner of the technology, in some ways it was worse.

Because although WinFS did fall, I never paid to have it keep me upright. Something that definitely happened with the iBOT.

And of course we can blame the stupidity and ugliness that is the default behavior of insurance companies. Since it is the underlying cause of this problem. You know, the jerks who figure dignity is found in the dictionary somewhere between dickhead and dumbass and treat their patients (who they could help) as not being worthy of having human dignity unless they are capable of standing up for themselves, literally....

This post brought to you by ♿ (U+267f, a.k.a. WHEELCHAIR SYMBOL)

Computerized apologies to Soundgarden, an awesome band that at a minimum deserves more intelligent puns....

Someone was having trouble getting something to work in Vista (yes, yes, alert the news media). The problem description:

Hi, there, sorry for spam. I want to use weather service gadget on my Vista sidebar, but it shows “Services not available”.... Do I have to set up any configuration like firewall, proxy? Thanks.

Several others chimed in with a helpful "works for me!". Scroan.

Then thankfully someone else inquired about the language settings. We'll get back to that in a second.

Someone else then pointed out KB article 931272 (Message that you may receive when you try to view the Weather gadget on the Windows Sidebar in Windows Vista: “Service not available in your language or region”).

I hate that article, by the way.

The resolution steps it gives:

To resolve this issue follow these steps.

Note These steps resolve this issue only if you are in a location that supports the Web service that is used to retrieve weather data.

1. Click Start
   Collapse this imageExpand this image

   
   , type intl.cpl in the Start Search box, and then click intl.cpl in the Programs list.
2. Click the Format tab, and then in the Current format list, select the format that you want to use for your region.
3. Click the Location tab, and then in the Current location list, click the location that corresponds to the region that is set on the Format tab.
4. Close the Regional and Language Options dialog box.
5. In the Windows Sidebar, close the Weather gadget.
6. Click the plus sign (+) that appears at the top of the Windows Sidebar.
7. Locate the Weather gadget, and then drag it to the Windows Sidebar.
8. Close the Gadgets window.

Note After you change the regional settings, some programs may not work correctly. Some programs and some services provide local information, such as news and weather. These programs and services provide this information based on the regional settings.

If you are a regular reader then you probably know why this annoys me.

It is not so much the article -- that just annoys me.

Or the description -- that just annoys me too.

It is the flaw in the gadget that leads to the problem that I hate. The terrible description is just the cherry on top of the inedible sundae....

It is yet another instance of the If you play with your gadget, there are all kinds of problems you can run into problem.

Scary.

Anyway, the person having the trouble admitted to having Simplified Chinese/China settings, at which point someone else pointed out a fascinating reference.

And when I say fascinating I mean the way traffic accidents or train crashes or fascinating....

The pointer was to Meteorology Law of the People's Republic of China, specifically Article 22 and Article 25 in that document:

Article 22 The State applies a unified system for the issue of public meteorological forecast and severe weather warning. Meteorological offices and stations subordinate to the competent meteorological departments at different levels shall, in compliance with their functions and duties, issue to the community public meteorological forecast and severe weather warning, with timely supplements or corrections added as the weather changes. No other organizations or individuals may issue to the community such forecast or warning. Meteorological offices and stations subordinate to other relevant departments under the State Council or under the people's governments of provinces, autonomous regions or municipalities directly under the Central Government may issue specialized meteorological forecast to be used within the frame work of their departments. The competent meteorological departments at different levels and the meteorological offices and stations subordinate to them shall issue public meteorological forecast and severe weather warning with improved accuracy, timeliness and service.

...

Article 25 When the media, including radio, television, newspaper and telecommunication, issue to the community public meteorological forecast or severe weather warning, they shall use the latest meteorological information provided by a meteorological office or station subordinate to a competent meteorological department, while indicating the time of issue and the name of the office or station. Part of the revenues from the distribution of meteorological information shall be drawn to support the development of meteorological service.

Some of the other articles are also fascinating. But if it were up to me I'm not sure I would want to be required to use one service and required to pay their (not subject to competition) rates.

I have no idea if that is why the service is not available in China, but I've heard of stranger things. Both from in China and from other countries.

What was Shakespeare said about the Law? :-)

This blog brlought to you by ☀ (U+2600, aka BLACK SUN WITH RAYS)

Frank's question is one any reasonable person could have:

So, why is XmlWriter producing a document with encoding = UTF16 when I specify UTF8 ?

static void Main(string[] args)
{
    XmlWriterSettings xws = new XmlWriterSettings();
    xws.Encoding = Encoding.UTF8;
    StringBuilder sb = new StringBuilder();
    XmlWriter xw = XmlWriter.Create(sb, xws);
    xw.WriteStartDocument();
    xw.WriteElementString("Element", "Value");
    xw.WriteEndDocument();
    xw.Flush();
    xw.Close();
}

--
Frank

That code prodcuces XML with the following preamble:

<?xml version="1.0" encoding="utf-16"?><Element>Value</Element>

I can see what he was talking about. Weird!

Someone pointed out that looking at the XmlWriterSettings.Encoding property documentation would explain what was going on:

Remarks
The XmlWriter encodes a buffer of characters all at once, rather than character by character. An exception is thrown when the Flush method is called if any encoding errors are encountered.

The Encoding property only applies to the XmlWriter instances that are created either with the specified Stream or with the specified file name. If the XmlWriter instance is created with the specified TextWriter, the Encoding property is overridden by the encoding of the underlying TextWriter. For example, if this property is set to Unicode (UTF-16 ) for a particular XmlWriter, but the underlying writer is an StreamWriter (which derives from TextWriter) with its encoding set to UTF8, the output will be UTF8 encoded.

If the XmlWriter instance is created with other output parameters, the Encoding property is ignored.

Personally, I think that is all designed slightly more confusingly than it had to be. But that is just me. :-)

This blog brought to you by 𝌏 (U+1d30f, aka TETRAGRAM FOR DEFECTIVENESS OR DISTORTION)

WARNING: This blog has nothing whatsoever¹ do with Nordic sex.

Regular reader Santhosh Pillai had a question not too long ago that I found to be rather kick ass and cool, professionally speaking.

It was:

Hi,

I am trying to figure out how these characters sort in Danish: A, Å, Æ, B, Ø, Z

1. If I follow the Danish and Norwegian Sort Order documentation in MSDN, it should be: A, B, Z, Å, Æ, Ø.
2. If I follow, Unicode sort order, it will be: A, Å, Æ, B, Ø, Z
3. If I follow the order by which they are pronounced, it will be: A, Å, Æ, B, Ø, Z (because Å is Aa, Æ is Ae, and Ø is Oe)
4. And if I look at the alphabet list and how they appear in the list, the order will be: A, B, Z, Æ, Ø, Å

Which one is “more correct”?

In the product I work on, here is what happens:

• In "task list”, the letters are sorted as: A, B, Z, Æ, Ø, Å
• In "event list", the letters are sorted as: Å. A, B, Z, Æ, Ø
• In "contact list", the letters are sorted as: B, A, Z, Æ, Ø, Å (don’t know where this comes from!)
  

Thanks

Fascinating!

The MSDN "topic" he was talking about in #1 above is from the appendix from v1 of Developing International Software. That table doesn't appear to be as complete as I once thought it was, and I'll have to remember to consider giving Cathy a hard time about that at some point in the not too distant future! :-)

We know that #2 (the "Unicode" order) is wrong because it is from the default table and we know Danish has some different rules.

And we know that #3 is wrong since it is not how someone in Denmark would pronounce things....

And that #4 list from Wikipedia is tempting though the format doesn't appeal to me quite as much. I am much more of glutton for punishment. :-)

Looking at what Windows does, we can go to the protocol documents and (excerpting the relevant data from the Active Directory Sort Table it points to to get both the entries in the default table and the ones that control exceptions for Danish):

0x0041   14    2    2   18 ; A   Latin Capital Letter A
0x0042   14    9    2   18 ; B   Latin Capital Letter B
0x005a   14  169    2   18 ; Z   Latin Capital Letter Z
0x00c6   14  172    2   18 ; Æ   Latin Capital Letter AE
0x00d8   14  174    2   18 ; Ø   Latin Capital Letter O With Stroke
0x00c5   14  177    2   18 ; Å   Latin Capital Letter A With Ring Above

And there we have it -- the Wikipedia article is right.

And 2/3 of the pieces of the nameless product are doing their own thing, off the reservation. And they definitely aren't doing it like Danes do it!

1 - Sorry if you jumped in, based on the title, thinking I was go all totally inappropriate about my last stay in Copenhagen².
2 - It was actually for a trip to Malmo³ with several evenings in Copenhagen⁴.
3 - For the Festival, you see....
4 - This was done primarily⁵ for the cooler hotel on the Denmark side.
5 - Oh, and also the nightlife⁶ in Copenhagen on the non-Malmo nights.
6 - Ah, never mind; I said this blog wouldn't be about Nordic sex! :-)

This blog brought to you by Ø (U+00d8, aka LATIN CAPITAL LETTER O WITH STROKE)

In the past 10 days I have had four people ask me the same question. Here is one if the most recent ones:

Hi Michael,

One of my friends was asking if there is an ICU for .NET. icu4c-4_0-Win32-msvc8.zip that he got from http://www.icu-project.org/download/4.0.html seems to be the one for Native Win32.

Thanks

Hmmm. I can honestly say that I have no idea whatsoever. :-)

But the whole inquiry scores pretty well on my "scale of 1 to interesting" metric so I think I'll talk about it for a minute. Not as an ICU expert (which I am not), but as an eager and interested external observer who is insanely curious about some of the weirdest things....

As far as I know there are only version for C (ICU4C) and for Java (ICU4J).

Now I do know that many features in ICU4J depend on features and functionality in Java itself, which tells me that ICU4J is not a straight port of ICU4C -- it is an extension to Java to provide the full features of ICU (you must have a minimum version of Java to get full ICU support, for example).

This suggests that someone could choose to build an ICU.NET that took all of the built in features from the appropriate namespaces like System.Globalization and System.Text, and then extended them to add in the other features ICU boasts like the UCA, transliteration, and fuller Unicode Character Database support.

Though I can't imagine Microsoft doing such a project, it does sound like parts of it would be pretty exciting. If I were still a consultant and some client with deep pockets wanted such a deliverable I imagine I'd really push to be one of the deliverers of the deliverable.

But back in the real world, I don't have that kind of time. :-)

I don't know of anyone else working on such a thing either. If anyone does and it isn't a secret they could probably chime in and add a comment or two here. I think it does sound like an interesting idea, and technically speaking it would be a fascinating cross-platform extension of ICU itself (not to mention of .NET which does have other platforms of its own from the Mac to mobile devices and so on).

Anyone out there working on ICU.NET?

This blog brought to you by ? (U+003f, aka QUESTION MARK)

Earlier today, tshirk (probably not his real name?) asked via the Contact link:

Okay, I'm sorry.  This is a support question.  I suck.

I'm just asking if you've ever heard of applications that use Marlett (super secret Windows system symbol font) being unable to use it over an RDP connection?

We've got a bug in a 3rd party component where, when it creates PDFs from HTML forms, it uses the Marlett check to simulate the chekbox on a webpage.  Works great, but when run within a remote desktop connection the Marlett font is substituted with Arial, which makes checks look like Bs.

If you have ever heard of anything like this, or if you are interested enough in this weird situation to look into it, any hints you can give us will be greatly appreciated.

If not, don't worry about it.  I'm pushing to replace all the damn checkboxes on the HTML forms with bitmaps and be done with it....

Now I know that I tell people not to expect support from me, and they shouldn't.

But sometimes the question will intrigue me, so I will jump in anyway.

Besides, there is just something about Marlett (last discussed in A bit about Marlett).

My psychic debugging powers leads me in a specific direction here -- this is a bug that I feel pretty comfortable laying at the feet of whoever/whatever component creates the PDFs.

In fact, this is a bug that was reported during Office 2007 (pre-RTM) in their own "save as PDF" functionality, and fixed prior to RTM.

Does it count as cheating on the "psychic debugging" if you remember running across the bug being reported by someone else, somewhere else? :-)

The circumstances leading up to the bug are something I talked a bit about in blogs like How best to keep the font switcheroo from happening?, where I emphasize that functions creating fonts are actually requests for fonts based on parameters passed to the functions themselves.

In this case, if you create a font with the name Marlett (and likely other symbol fonts) but do not specify SYMBOL_CHARSET, there are some code paths, commonly used by PDF renderers if our sample of two is scientific enough, that will end up seeing the font mapper in GDI substitute a different font.

Of course many tools that create PDFs don't tend to allow one to specify information at this level of detail, but if in this case the component allows one to specify the information then there is a simple workaround....

This post brought to you by B (U+0042, aka LATIN CAPITAL LETTER B)

Ben's question was a reasonable one:

Hello,

I am currently running into an issue on an Arabic localized box in which an ArgumentOutOfRangeException is being thrown when DateTime.ToString() is called on a DateTime object with the value set to MaxValue.  I understand that the valid range for DateTime values varies from culture to culture and I suspect that the MaxValue being set is not in the valid range for the Arabic locale’s calendar.  Given the variety of different calendars that need to be supported, are there are any guidelines for choosing default Max/Min DateTime values that will be valid for all cultures?

Thanks,
Ben

If you are a regular reader then this may seem like a kind of familiar problem (ref: Long term planning is not always done).

But in the meantime, Melitta stepped up with a very good and practical answer to the question:

Hi Ben,

If you look at the documentation for DateTime.MaxValue (http://msdn.microsoft.com/en-us/library/system.datetime.maxvalue.aspx), the Remarks section mentions a similar problem. 

Remarks:
The value of this constant is equivalent to 23:59:59.9999999, December 31, 9999, exactly one 100-nanosecond tick before 00:00:00, January 1, 10000.

Some calendars, such as the UmAlQuraCalendar, support an upper date range that is earlier than MaxValue. In these cases, trying to access MaxValue in variable assignments or formatting and parsing operations can throw an ArgumentOutOfRangeException. Rather than retrieving the value of DateTime..::.MaxValue, you can retrieve the value of the specified culture's latest valid date value from the System.Globalization.CultureInfo.DateTimeFormat.Calendar.MaxSupportedDateTime property.

So if you wanted to get, for example, the CurrentCulture’s Calendar’s MaxSupprotedDateTime you could have:

System.Globalization.CultureInfo.CurrentCulture.Calendar.MaxSupportedDateTime;  System.Globalization.CultureInfo.CurrentCulture.Calendar.MinSupportedDateTime;

Or you could replace System.Globalization.CultureInfo.CurrentCulture with any culture of your choice.

Here are links to the documentation on those properties:

http://msdn.microsoft.com/en-us/library/system.globalization.calendar.maxsupporteddatetime.aspx
http://msdn.microsoft.com/en-us/library/system.globalization.calendar.minsupporteddatetime.aspx

This doesn’t help if you need to have a known, hard-coded default.  But since you were using DateTime.MaxValue already, it seems like you’d be able to handle getting the data at runtime.  I hope this helps.

Thanks,
Melitta

Now this is correct -- and helpful.

It would even nicely work around the issues I mention in Theory vs. practice in software development if these dates took those issues into account (unfortunately they do not, in most cases). This meansd it will help work around the bug being reported, but not the design flaw that is the cause.

And also with an additional caveat -- note that it still won't help in the case of the Japanese Emperor calendar, which is based on the rule (and potentially the life) of the Emperor and is therefore not a known value until it happens (for more on that see Long live the Emperor).

But there really is nothing to help with that particular case. At least not that I would want to know about. :-)

So in the end it is reasonable to question the original requirement, since there will be cases where it is impossible to fulfill.....

This post brought to you by 平 (U+5e73, a.k.a. CJK IDEOGRAPH meaning 'flat, level, even; peaceful')

Previous blogs in this series of blogs on this Blog:

• Part 0: The intro, sans content
• Part 1: Getting the obvious out of the way
• Part 2: A&P of a 'linguistic character'
• Part 3: It starts with cursor movement (where MS simultaneously gets better and worse)
• Part 4: Talking about the ask 
• Part 5: What's on the Next Level?
• Part 6: An exercise left for whoever needs some exercise
• Part 7: If it makes the SQL Server columns too small then it made the Oracle columns either too smallER or too smallEST
• Part 8: It's the end of the string as we know it (and I feel ellipses)
  

It was way back in January of 2005 where I first mentioned how CharNext(ch) != ch+1, a lot of the time, which explained about how just incrementing a character pointer was not all that the CharNext function did.

Then James pointed out in a comment (here) that, as it turns out, on Windows XP and Server 2003, that kind of was all that CharNext was doing.

Remember how I talked about the way that even though NLS did not own some of these USER functions, that we pretty much "owned" them since we control their behavior, in this post?

Well, this is one of those functions.

Details on the breakage cause were described soon thereafter in We broke CharNext/CharPrev (or, bugs found through blogging?).

So the decision was made to fix the bug (restoring the old functionality from NT <= Windows 2000, and at the same time to look at the other common complaint related to surrogate pairs.

Vista, therefore, supports the old functionality and took steps to add the new functionality (not splitting surrogate pairs).

There was a problem, though.

The code in there swapped the check for high and low surrogates such that it was always skipping the high surrogate and always returning the low surrogate -- which is exactly the opposite of the behavior you want.

Now no one found the bug because as it turns out the tested case (and admittedly the most common scenario for the function?), which is "a more linguistically appropriate lstrlenW based on user character principles" will still work here, even though a single call will return the wrong result when faced with a high surrogate.

Here is where it gets more complicated.

What happens in the next version, and/or possibly in the next service pack of Vista/Server 2008?

There are many choices:

2) Do we fix the bug with supplementary characters so that both they and the combining characters case will both work?

3) Do we give up on both and go back to the XP level behavior, which even though it was a regression from prior versions does represent a very popular platform?

4) Do we give up on trying to do anything here and just leave it broken as it is now, and perhaps in some unknown future version (it is a bit late in the cycle to start designing all new features) look into all new solutions to the problem(s) once they are identified?

Now the order of these four choices, due to the way the code is written and under the principle of minimal change, is technically in order from most difficult to least difficult. Though really the amount of difficulty involved here is not that much even as you move across all four options, so that does not really provide very much insight into a triage process.

In terms of platform popularity, I don't think there are many people outside of fans of the Windows "Mohave" commercials who would claim that XP isn't the most popular platform -- which does suggest that #3 is worth considering, at least.

My personal preference would be #2 since it is "the right thing to do" though when you have behavior that has been changing every few versions it might perhaps better to take some time to think about the backward compatibility issues before concluding that "the right thing to do" and "the best thing to do" are necessarily the same.

The fact that so few people noticed the bug suggests that either

• no one is paying attention to/relying on the results, or
• the function is being used for a "linguistic character" version of lstrlenW.

And obviously in both of those cases #2 would not represent a breaking change.

But let's assume that a certain number of developers have noticed the odd behavior and chosen to work around it in their own code. Plenty of people do that, and many of them are either too cynical to report the bug or don't know of a good way to make the report. Or they just don't like Microsoft -- it happens.

The ones who just decide the function is unreliable and write their own can be removed from our consideration here, since even though they may be right, they will not be broken if the behavior changes. So we'll leave them aside for a moment.

If we don't want to break the people who found the bug and worked around it, we'd have to assume that they were essentially detecting the case where CharNext or CharPrev incorrectly return a high surrogate value (whether using the IS_HIGH_SURROGATE macro or simple range checking or whatever), and then doing an additional increment/decrement in those cases.

Perhaps they feel that their code was a really good idea since it will even "fix" prior versions like NT 4.0 or Windows 2000 or XP and thus they feel they are "future-proof" since no right-thinking developer would break against every version (note that none of the above solutions do that!).

Now if history is to be a guide, people might not do the full job here -- they might not be detecting the errant cases like unpaired surrogates or multiple high surrogates, so it might just be blind one WCHAR increment/decrement.

And some might go even farther and validate that a valid surrogate pair exists, which is not something Windows necessarily does but isn't unreasonable here.

But note that even in all of the above potential circumstances, the full fix described above in #2 is still entirely safe since the function would never return a character that was a high surrogate.

On balance, my gut feeling that #2 would be the best thing to do (in the next version of Windows and possibly even in future Vista/Server 2008 service packs) mainly on the basis that it is the right thing to do also does appear to be the best solution for technical reasons as well.

I mean, as UTF-16 detection mechanisms go, the best that can be said about CharNext and CharPrev is that they [sometimes, in some versions] work. Which is not saying much, but is saying something, at least. It is better at least in the abstract to improve with each version, in my opinion....

Though perhaps others would analyze the situation and circumstances and come to a different conclusion.

What would you do?

This post brought to you by å (U+00e5, a.k.a. LATIN SMALL LETTER A WITH RING ABOVE)
A character that is downright snooty about the fact that it has none of the problems mentioned in this article.
Despite the fact that a circle almost bigger than its body is super-glued to its head, something that would make me feel at least a little self-conscious.

Over in the Suggestion Box, Aaron asked:

Hi again - question about one of your favorite codepages - 1258 (Vietnamese) and combining diacritics in regards to Unicode character U+1EB7 (LATIN SMALL LETTER A WITH BREVE AND DOT BELOW - http://www.fileformat.info/info/unicode/char/1eb7/index.htm)

Windows Installer, for some unknown reason, has never gone unicode, so it always requires an ANSI codepage. For Vietnamese, this character, while extremely common, isn't actually in the codepage list, so I assume the correct way to get it is via usage of combining diacritics. Unfortunately, no matter how I try to break out the letter into diacritical marks, MSI refuses to show it correctly (yes, I have the font packs, etc...). I can get it to stop showing question marks, but not actually the correct character.

Which leaves me with a few questions:

1) Any ideas on how to get this character to show up correctly in MSI's UI for codepage 1258?

2) What's the best way to automatically convert from System.String for this character into a StreamWriter'd out GetEncoding(1258) version to get this decomposition correctly? Normalizing into FormD or FormKD first is not working, unfortunately, which was my hope. (Managed or Unmanaged is fine with me - just hope there's a way!)

3) Any other codepages you can think of that we should watch out for with problems like this?

4) Have you heard any push from the MSI team on getting to UTF-8 or UTF-16 support any time soon? It seems way behind the times.

Thanks!

Now I won't go so far as to say that 1258 is a favorite code page, so I'll take that as sarcasm. :-)

When I read the questions here, I immediately thought of the Robert Frost poem The Road Not Taken:

Two roads diverged in a yellow wood,
And sorry I could not travel both
And be one traveler, long I stood
And looked down one as far as I could
To where it bent in the undergrowth;

Then took the other, as just as fair,
And having perhaps the better claim,
Because it was grassy and wanted wear;
Though as for that the passing there
Had worn them really about the same,

And both that morning equally lay
In leaves no step had trodden black.
Oh, I kept the first for another day!
Yet knowing how way leads on to way,
I doubted if I should ever come back.

I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood, and I—
I took the one less traveled by,
And that has made all the difference.

Now the poem has been interpreted by others much greater than I, so I'll just go so far as to say that one popular interpretation is an ironic one -- that despite the speaker's bold proclamation at the end about how this different choice made all the difference, in truth it made very little difference, and the two paths were really pretty much equivalent.

I thought I'd twist that up a bit with Aaron's example that leads to a specific scenario where refusing to go down the road not taken can more or less kick your ass!

I'll start by pointing to a blog that comes close to helping here but in the end fails (Getting intermediate forms).

Then I'll point to a blog that comes a bit closer to the mark (Harder intermediate forms of characters).

It's all well and good to talk about U+1eb7 (ặ), aka LATIN SMALL LETTER A WITH BREVE AND DOT BELOW.

Now this character is in Unicode Normalization Form C.

If you decompose it once via the data in the Unicode Character Database, you get U+1ea1 U+0306, aka LATIN SMALL LETTER A WITH DOT BELOW + COMBINING BREVE.

And if you decompose it again, you get U+0061 U+0323 U+0306, aka LATIN SMALL LETTER A + COMBINING DOT BELOW + COMBINING BREVE.

That last sequence? That is the character in Unicode Normalization Form D.

You might notice a bit of lack of coverage of either form in Windows code page 1258. Even with the odd ccombing characters it has, which I mentioned in A few of the gotchas of MultiByteToWideChar.

However, as that blog points out, Windows code page 1258 does have U+0323 (COMBINING DOT BELOW).

And id you look at the code page table itself, you will see that it does have U+0103 (LATIN SMALL LETTER A WITH COMBINING BREVE).

Now this is one of those harder intermediate forms -- U+0103 U+0323 (ặ), aka LATIN SMALL LETTER A WITH BREVE + COMBINING DOT BELOW is, while definitely the road not taken by Unicode normalization, is actually the de facto road taken by (for lack of an official term) Microsoft's "Normalization Form V", as used by its code page 1258.

Note that this sequence will see both Unicode Normalization Forms C and KC convert to U+1eb7, and both Unicode Normalization Forms D and KD convert to U+0061 U+0323 U+0306.

Now there is no conversion built into Windows or .NET to get this form not taken that will look right using code page 1258. Though if I ever had an interview candidate who understood all about code pages, I suspect that writing a converter that could do such a job would make for a fascinating interview question!

So, getting back to Aaron's questions, I handle #1 above and point out how though there is no good specific way to do #2 I'd be very impressed by the person who wrote the code to do it!

For #3, code page 1258 is the only conventional ACP under Windows with this specific problem.

And as for #4, while technically UTF-8 (code page 65001) is unsupported by Windows Installer, as I pointed out in MSI Databases and Unicode, MSKLC was able to successfully use UTF-8 and support the setup packages for many Unicode-only languages such as Hindi and Lao and Tibetan. Which suggests that it can in fact be used for Vietnamese.

Note that there are some characters that even if you do manage to create your own implementation of the so my so called Microsoft Normalization Form V can't be represented by the code page, thus UTF-8 is really the only option that can support the Vietnamese language itself, in the long run.

And although using UTF-8 here will make that conversion code unnecessary, I'd still want to hire the person who came up with an elegant code solution there. :-)

Thinking of all the work that fonts do to support the fictional Form V as well as the other, more valid and less valid forms, it is unfortunate that this support was never made more widespread so that it would be easier to support languages like Vietnamese while waiting for everyone like MSI and others to move to Unicode.

Now Windows code page 1258 is clearly an example where The Road Not Taken may well look the same in fonts and rendering, but in terms of code pages and components that do not use Unicode and/or do not normalize will see the road not taken as one with very very tall weeds blocking the way of folks like Aaron whose actual work might not afford them the ironic detachment of Robert Frost when it turns out that the two paths aren't the same....

This blog brought to you by ặ (U+1eb7, aka LATIN SMALL LETTER  WITH BREVE AND DOT BELOW)

YIAB -- yet another IBOT blog -- feel free to ignore if they aren't your thing...

Prior blogs in the series here and here and here and here and here and here and here and here.

Yesterday was an interesting day.

We had a morale event, an Argosy lunch cruise.

We managed to get the whole International Fundamentals team there, which was cool.:-)

My manager and others kept asking me if I could be there; a quick call to Argosy confirmed that they could handle a powered wheelchair.

Interestingly, they pointed out that the elevator was in the kitchen; they asked me I would have trouble with that. Are there people in wheelchairs who actually would? That is just downright odd!

Lunch was cool, and of course ther were the requisite number of people on the boat (crew and passengers) who came up to say they thought the iBOT was cool.

Am I a junky for the positive attention? I thought I'd be tired of it but I thibk the technical details of the iBOT appeal to me enough that I aall I can do is agree -- it is cool!

anyway, people kept offering to carpool, but I pointed out that since they don't have trucks it wouldn't work. I'd just take the 545 and head down to the waterfront....

And this is what I did -- straight down Spring in 4-wheel mode, into balance once I hit Alaskan, and onto the boat shortly thereafter.

I could have taken a different route down than Spring (some people balk at the steep hill and prefer other ways down to the water that involve stairs), but I have determined something about stairs and the iBOT.

Don't get me wrong, It is an incredibly useful feature, a lifesaver from situations that would otherwise be blocking

But most of the time, if you do it, then you're just showing off....

And I am not above showing off (that is why I spend so much time in balance mode!), but sowing off in balance mode is actually more comfortable and less work involved. Climbing stairs is more work!

So I took Spring, and I took the elevator once I was onboard.

Lunch was cool, and I headed out with everyone after, until we parted ways so people could head back to work and pack (yes, we're finally doing the gratuitous move -- more on that another time!).

So I headed out, in balance mode, up to the base of Spring Street and Alaskan Way, when I suddenly remembered something I had recently learned.

The directions for the iBOT suggest that you should not do more than a 10° incline in Balance mode (20° in 4-wheel), but they aren't really all that accurate -- it can take a much bigger incline -- even in training I was taken on steeper ones.

The key is that the hill has to be straught ahead, because the iBOT does not have lateral iBALANCE, only forward/backward iBALANCE.

So I decided to test that theory by going up Spring Street all the way to 4th Avenue, in Balance mode.

You want to know something?

I am pissed.

I could have taken somebody with me, someione with a camera. Someone to capture me going up a street with a 30° to 40° incline, with me flat and level all the way up, going at the same speed as if I were on level ground.

It was awesome!

I tried to get my head around how odd/interesting it must have looked, but I'm going to have to get it captured on film -- not just pictures but live motion video.

I don't have access to a Steadicam:

A steadicam is a stabilizing mount for a motion picture camera, which mechanically isolates the operator's movement from the camera, allowing a very smooth shot even when the operator is moving quickly over an uneven surface. 

But even so, a little amateur footage might be just the thing here, though I imagine there are logistical problems with walking up that hill at the same speed. We'll have to do some figuring out here, certainly. Both up and down, since being at a a 50°-60° angle is just as cool as being at a 120°-130° angle....

I guess it is too much to ask if anyone in the Seattle area has a Steadicam and a few hours? :-)

This post brought to you by ♿ (U+267f, a.k.a. WHEELCHAIR SYMBOL)

Looking back at the my blog Ready... set... Reboot Redux, part Deux!, in order tp get the link to help answer someone's question, I realized something very important.

That blog does not give the solution, it really only states the problem.

A problem that, while MUI becomes more and more popular at the same time that it's user interface language can remain so easily out of sync with the default system locale, that localizations can find themselves quite easily broken.

But I did not talk about solutions, or even more directly about the nature of the exact problem that a developer needs to be looking at to be in the frame of mind to think about solutions.

Today that is what I am going to do. :-)

Now there are two common reasons that the problem can be happening in an application that a developer might believe to be quite localizable:

• The application might have the font name and size in a string table, with font attributes either included in the name string by default (eg Tahoma Bold)  added by the localizer later (eg Tahoma Gras);
• The application might have the font name and size in a DIALOG or DIALOGEX resource, again with font attributes either included in the name string by default (eg Tahoma Bold)  added by the localizer later (eg Tahoma Gras).

Now the core issue here in both cases is that the attribute has to be kept out of the name.

This all applies to italics as well, but that is a single Boolean parameter (LOGFONT.lfItalic), so it easier to store elsewhere if it it needs to be exposed, which it usually doesn't...

When the name is in a string table, all you really have is the name -- the attribute is most often not stored in a string table as anything but a string with the name.

To make that first case localizable, you have to store the LOGFONT.lfWeight value there too -- 700 (FW_BOLD) or 800 (FW_ULTRABOLD), generally, if you want it to be bold.

And of course make siure there is a comment for the localizer to understand what the numbers are -- because that is very unwieldy and hard to understand, otherwise.

Of course by the time you add four strings to a string table (the face name, the size, the weight, and whether it was italic, you may wish you had put the information in a resource directly.

Which brings us to the other option.

If you have the face name in a DIALOG resource, then get it the hell out of there. The FONT keyword in a DIALOG resource only exposes the size and the name. So it leaves you back where you started. Use a DIALOGEX resource instead.

And then if you are using a DIALOGEX resource, then you can specify the font name, size, weight, and italic settings explicitly in a way that is not subject to localization strangeness -- and all of which is nevertheless exposed to localizers.

In case you are wondering why you can't just do the bold/italic stuff yourself always and just not expose those attributes to localization, this other blog explains it -- these attributes should be localizable.

And there you go -- the solution for the problem that was previously described.

Localizability can be hard and the bugs an be subtle -- especially in cases like this where incorrect localizability work can cause the act of localization to break an application....

This post brought to you by ಬ (U+0cac, KANNADA LETTER BA)

Not a technical issues but kind of a language one. Feel free to skip...

When I was growing up in Beachwood, Ohio, I remember a children's rhyme involving a rabbit that was harassing the local field mice.

After ignoring the warnings of Good Fairy (usually three, allusions to the three strikes rule in prisoner sentencing!), the rabbit is made to pay.

The words that I learned:

Little Rabbit Foo Foo
Hopping through the forest
Scooping up the field mice
And bopping them on the head!
Down came the Good Fairy, and she said:
"Little Rabbit Foo Foo
I don't wanna see you
Scooping up the field mice
And bopping them on the head!
I will give you three chances,
And if you don't behave, I will turn you into a GOON!"

 Then after the rabbit continued his illegal harrassment pattern and ignored the warnings, eventually the threat was carried out.

And the moral of the story was:

Hare today, GOON tomorrow.

(Insert eye roll and groan here!)

Now I have been informed that others who learned this growing up heard a variant involving Little BUNNY Foo Foo, not Little Rabbit Foo Foo.

Now Google Fight doesn't show too much difference (~185,000 vs. ~189,000), but apparently there is a bit of a difference of opinion, one that has even led to a couple of heated discussions, on both side of the country and both side of the Atlantic.

I thought that it would be best for me to put out all my thoughts on the matter here and then do my best to try to never think about the rodent again...

Now the notion of calling him a bunny?

This makes no sense to me.

I mean, assuming you ignore the Killer Rabbit of Caerbannog from Monty Python and the Holy Grail, sometimes called the Killer Bunny (YouTube link here), bunnies are small cute animals.

In fact, the way that the Killer Rabbit is NOT called a bunny kind of proves my point.

The described behavior in the rhyme of a bullying, practically stalking Sylvilagus is completely inconsistent with the whole notion of a bunny.

If an animal is going to be terrorizing the local apodemus sylvaticus population, he's no bunny; he's a goddamn rabbit.

Okay, that is all I had to say. You may now expect me to go back to more normal blogs than this one was....

This blog brought to you by ꀨ (U+a028, aka YI SYLLABLE BOP)