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:
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!
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):
✔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)
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:
Using strategically placed RLE characters, or a RLO/PDF pair, might solve the immediate problem.
Michael S. Kaplan on 19 Jul 2010 10:19 AM:
Of course. :-)
I was focusing on the bigger issues, as they were....
rs on 19 Jul 2010 11:33 AM:
I am wondering whether the behavior described (using the directionality of the surrounding text for symbols) isn't actually correct: What I mean is that the text
abc (in Hebrew, אבג)
should appear as
abc (in Hebrew, ℷℶℵ)
abc (in Hebrew, (ℷℶℵ
Michael S. Kaplan on 19 Jul 2010 11:50 AM:
There is a context issue here for parens that is also relevant (and which Office does correctly here). In this case, parens that start before the RTL zone need to follow the same context rules when the parens end.
jon on 19 Jul 2010 1:52 PM:
Par-for-the-course when reporting bugs to Microsoft unfortunately. I'm not saying the official company policy is to claim non-reproducability without actually trying or attempting to try to reproduce, but it sure feels like that at times...
go to newer or older post, or back to index or month or day