It's a bug, it's always been a bug. In either direction....

by Michael S. Kaplan, published on 2010/07/19 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/07/19/10031197.aspx

So the other day someone pointed me to a thread going on over on the forums.

The post in question was: Problem with symbols when drawing Hebrew text by Graphics.DrawString function from the RichTextBox control, if you want to skip ahead of my description and see what I’m going to talk about before I start talking…

The stated problem from winrazor:

Hi all,

I have a question:
I'm trying to draw RightToLeft (Hebrew) text on the Image object using "Graphics.DrawString" function.
Text is previously loaded from the RTF file into RichTextBox control, and in this control it seems correct.
But after drawing on the image symbols like "(" , ":"  and "." displayed on the incorrect positions when they are last or first in the text line.
In other words mixing Hebrew with Simbols (English) does not work correct.

Do you have any idea?

Thanks a lot!
Timur.

Now regular readers here might know what is going on already.

This is the typical problem with neutral characters at the end of an RTL run of characters that are embedded in an LTR context – the neutral character takes the overiding directionality to decide where it should be placed rather than the preceding text.

The user has just noticed that the RichTextBox (as well as WordPad and Word and Outlook) have been doing a slightly better job than GDI+ (as well as plain old Notepad, plain old EDIT controls, plain old Uniscribe).

We can start with an easy point.

The bug in question will never be [intentionally] fixed. Period.

GDI+ is in maintenance mode now and only high severity bugs like crashing or security exploit bugs are being fixed. And while a misplaced period can sometimes crash one’s plans for an evening, it is never going to crash a version of Windows.

So Graphics.DrawString is going to live with the same limitations as Notepad, the regular EDIT control, the TextBox control, and plain old Uniscribe that it has roughly for the lifetime of Bidi support on Microsoft products that do these “mixed directionality with neutral characters on the border of items” scenarios.

Now for the rest of the thread, it gets a little weird, with the MS person claiming the bug can’t be reproduced even though the sample written by the MS person completely reproduces the bug that the customer reported. A screenshot of the non-repro that was repro’ed was provided:

The post was then moved to “General Discussion” since requested information wasn’t provided after just four days. Even though it really had been (this is a problem that anyone with knowledge of Bidi can easily speak to).

Ten days later, WinRazor responded (I added checkmarks to the lines that are accurate):

Dear Friend,

✔Hebrew is Right to Left language, it means that dot should be from the left side. (in the end of the frase)

✔Initial string also has dot from the right - it's another bug of this online tool.

Dots braces and other symbols are placed incorrectly by MS new functions.
Finally I've fixed the problem by using old functions, which have awfull preformance with long texts, this problem is also fixed by manual separating pages with additional optimization.

In other words:  MS should fix 2 bugs:
✔1) In the new function "MeasureString" - RTL is not supported as needed!!! (symbols mixed with Hebrew text have incorrect positions)
✔2) Bug in this online tool - typing and copy\paste have the same problem with symbols as 1) .

I did serious investigation in the net, and a lot of people have the same problem and suggest to use old interface,
it also suggested in the MS example. I think that a nice way or fix this bug or notice about this problem in the help of the new functions.

✔And please don't say that you don't have enough info - you can see the problem in your answer.

Anyway, thank you for your answer! And please let me know when 1) is fixed. (if it's possible)
Timur.

Well, the first few lines were right (in fact all the lines I put a check in front of are correct!).

Now it is unclear what is meant here by “old functions” since this only works correctly in newer versions of certain controls. I assume the problem is that it used to work with other RichTextBox editing stuff and that can make the definition of “old” and “new” change a bit (it is easy to think of these functions as NEW to the people using it, I suppose).

But there have been misunderstandings about what is going on here on both sides!

So be it, though.

Microsoft never responded to this last post, even after nine months, which is more than enough time for cow, countess, or response from support. So it probably won’t be responded to ever at this point.

I mean except for me weighing in, of course! :-)

This is the kind of bug that really ought to be just fixed given the many reports over the years and the real impact it has, though of course when/who/how type questions clearly will impact such a fix…

John Cowan on 19 Jul 2010 9:01 AM:

Michael S. Kaplan on 19 Jul 2010 10:19 AM:

rs on 19 Jul 2010 11:33 AM:

Michael S. Kaplan on 19 Jul 2010 11:50 AM:

jon on 19 Jul 2010 1:52 PM:

referenced by

go to newer or older post, or back to index or month or day