> Another thing we had looked at was implementing Pango in 2.0's > System.Windows.Forms.TextRenderer instead of going through > System.Drawing. (We have an internal version for 1.1, so we don't need > separate code paths.) > > It supports a different set of formatting options that may be easier to > replicate. > > Also, implementing it here would not have the potential to break as much > existing code, as not as many things use it. Once it is implemented, > controls would need to be updated to use this instead of System.Drawing. > Updating every control will not be fun, but as you already noticed, > every control assumes LTR, so they would all have to be changed to > support RTL anyways.
I've considered that. I may look into the different formatting options to see if they make more sense in terms of pango. One other thing that I'm working on is adding some of the functionality needed to the internal TextBoxTextRenderer class. To do an editor control correctly there is a lot more to worry about than for a control that just draws text, so it makes sense in that regard. On the Windows side of things, I may use Uniscribe in TextBoxTextRenderer as there are some things you need for complex scripts you just can't get from GDI. Drawing is fine using GDI because it will pass any complex script through to Uniscribe already - you just can't get back information like good line breaking points (Thai doesn't use white space, for example), and both possible caret positions for a character (needed for bidirectional text). I'm pretty sure Microsoft's TextBox controls are using Uniscribe when necessary because I've done some testing with them using bidirectional text and get proper behavior that I don't think you could get just using GDI. Also mixed font/color text in the RtfTextBox would need to be done with Uniscribe in Windows. Jonathan Anderson _______________________________________________ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list