[Mono-bugs] [Bug 78777][Wis] Changed - MeasureCharacterRanges returns incorrect bounding rectangles when string contains an embedded \n

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by sebastien at ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=78777

--- shadow/78777	2007-08-02 10:41:13.000000000 -0400
+++ shadow/78777.tmp.30905	2007-08-02 10:58:57.000000000 -0400
@@ -1,13 +1,13 @@
 Bug#: 78777
 Product: Mono: Class Libraries
 Version: unspecified
 OS: unknown
 OS Details: 
-Status: REOPENED   
-Resolution: 
+Status: RESOLVED   
+Resolution: FIXED
 Severity: Unknown
 Priority: Wishlist
 Component: libgdiplus
 AssignedTo: mono-bugs at ximian.com                            
 ReportedBy: toshok at ximian.com               
 QAContact: mono-bugs at ximian.com
@@ -76,6 +76,34 @@
 #81572.
 
 The real problem is that the ranges works on the supplied string
 (which includes the /n) while the calculations are done on a
 "modified" string (that include more details). However this
 StringDetail has removed the \n characters so everything is "range" off.
+
+------- Additional Comments From sebastien at ximian.com  2007-08-02 10:58 -------
+Now using SVN (r83282) we get:
+
+region 0 bounds = {X=0,Y=0,Width=27,Height=23}
+region 1 bounds = {X=5,Y=18,Width=54,Height=23}
+
+region 1 X value is 5 because it's not looking at the "i" but "s" (see
+previous comment)
+
+[  0] X:   0, Y:  0, 't'  | [  1] X:   5, Y:  0, 'h'  | [  2] X:  14,
+Y:  0, 'i'  | [  3] X:  19, Y:  0, 's'  | <LF>
+[  4] X:   0, Y: 18, 'i'  | [  5] X:   5, Y: 18, 's'  | [  6] X:  13,
+Y: 18, ' '  | [  7] X:  18, Y: 18, 'a'  | [  8] X:  27, Y: 18, ' '  |
+[  9] X:  32, Y: 18, 't'  | [ 10] X:  37, Y: 18, 'e'  | [ 11] X:  46,
+Y: 18, 's'  | [ 12] X:  54, Y: 18, 't'  | [  0] X:   0, Y:  0, 't'  |
+[  1] X:   5, Y:  0, 'h'  | [  2] X:  14, Y:  0, 'i'  | [  3] X:  19,
+Y:  0, 's'  | <LF>
+
+But both height are now equals (fixed in SVN). This problem was due to
+the fact that the code is interpreting LF to be on the next line.
+
+So much stuff is wrong in that code...
+
+I'm closing this bug (as the unit test works correctly) and will open
+a new one about the \n
+
+sigh