Sorting it all Out

(Couldn't resist) Isn't it possible to solve by comparing bitmaps, I mean pixels?

What he wants is really a function that detects if the rendered output contains one or more "block" characters instead of the real McCoy, right?

One approach might be then:

1) Render to an offscreen bitmap one occurrence of the "block" character. (This assumes of course it is possible to always get hold of it in a reproducible manner, maybe there is a Unicode entrance for that.)

2. Render the client Unicode string to another, similar bitmap. This one will normally be much wider and possible a bit higher.

3. Now step through bitmap #2 using BitBlts that ANDs bitmap #1 and #2 with each other yielding a third bitmap. If that third bitmap is identical to bitmap #1 we have detected an occurrence of the "block" character by comparing pixels.

Note that we have to step through all x positions in bitmap #2, say bitmap #1 is 10 pixels wide and bitmap #2 is 1000 pixels wide, then we have to perform 991 BitBlts.

Finally we'll have to repeat this for all y positions if bitmap #2 is taller than #1, then we have to repeat those 991 Bitblts for all y positions.

A human eye will of course perform this function in an instant, but maybe lots of BitBlts could solve this problem as well.

Rgrds Henry

@Henry: This could be a problem when subpixel rendering (ClearType) is used, since I don't believe the character has to start at the same subpixel position - at least not unless you only compare one character at a time.

Actually, comparing the individual characters should be a bit easier and more reliable, since you would have more information to go on (no need to try multiple different starting positions) - but since you need to work with more individual bitmaps, any potential speed difference might be consumed by the constant changing of the bitmap.

And, of course, this approach would fail in the event that the character you're trying to draw just happens to look like the "replacement character" character. Since a lot of the Windows fonts will use a square for this, this might be the case if you want to use one of the characters actually representing a square - but that might be acceptable as a false positive.

@Michael: ClearType I think is only applied when drawing on a screen. But to avoid it anyway, you could use 1-bit color depths (i.e. black and white only) for all the bitmaps.

I agree about the lack of a universal "fool's gold" character. But if you render the trial (#1 above) bitmap in the exact same font as you render the client string in, then hopefully whoeever designed that particular font chose a unique bit pattern for his/hers "fool's gold", so false positives could be avoided.

The easiest way to solve a problem is to not solve it at all :-)

Just ask everybody to have all the international support installed.

(it is there in Win 7 and Vista, just do it for XP)

If that is not possible, option two is to:

- assume everything is on in Vista/Win 7 (the support is there and the fallback works pretty well)

- for XP scan the string for characters in the possible supported "blocks" (simple script LTR, complex script and RTL, East Asian).

If you find an Arabic character (for instance) and "complex script and RTL" is not install, complain.

(http://img.microsoft.com/globaldev/Images/xp-kbd-step2.gif)

Yes, you can still wonder about some exotic scripts that Windows .

But you pretty much eliminated 99% of the problems. Deal with the rest in tech support, or an FAQ. Depending on the locations you are trying to sell, you might discover nobody is affected.

@Henry Skoglund: What if it substitutes another font in, and that font has a hardcoded box glyph for that character?

Unrelated to anything, what is the etymology of the term "stack" as used here, and as used in e.g. "TCP/IP stack"

@Random832: Well the question was  "I’m being given a Unicode string and I need to determine if it will render cleanly using the system font..."

Any font substition then *hopefully* will only occur at the beginning of the rendering so the "fool's gold" character will not change.

I'd say the meaning of "stack" here, you could also say "text rendering technology".

I meant the situation from the first comment under Is that character in the font or isn't it? .

Font A is the main selected font - it has its box glyph that is used for any characters can't be found in a substituted font.

Font B claims to support one character set and defines a box for some characters in that character set which it does not in fact properly support.

So for a character that B claims to support but does not _really_ support, you get B's box, whereas for other random unicode code points that nothing supports, you get A's box.

(the captcha's on this site interact badly with tabbed browsing)

Right, font switching might occur, but if we can find an event that is fired due to that, my suggestion might still hold.

The idea then, is to do the block pattern matching multiple times, as soon as the font changes (as well as doing it at the end of the text rendering as I suggested before). I.e. create multiple bitmaps #1 and #2, one pair created whenever the fonts switch, and toss them at the next event. That way the block glyph character that we match to should still be correct.

But alas, doing a cursory glance at the MSDN docs I find no such event :-(

(Nice discussion anyway!)