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 [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=79246 --- shadow/79246 2006-09-05 01:45:55.000000000 -0400 +++ shadow/79246.tmp.9423 2006-09-05 09:10:00.000000000 -0400 @@ -72,6 +72,21 @@ right thing" here, because I doubt anybody will actually want alpha forced to 255 in BMP files (and if they do and they complain about it, we can change it then). I have yet to look at the other System.Drawing.Imaging test cases marked [NotWorking]. + +------- Additional Comments From [EMAIL PROTECTED] 2006-09-05 09:09 ------- +[1] not sure how many tests depends on this but we should look at +updating the file with a true 1bpp bitmap. FWIW all bitmaps should be +checked (and probably a few more added as well). + +[2] I may be misunderstanding BitmapData, but why would the bitmap +return different data with a different implementation ? (unless the +format uses a non-lossless compresssion). Anyway please explain why +moving by Z bytes would results in a different X, Y pixel position (as +this seems to be the main motivation of BitmapData). + +[3] Unless we're 100% sure about this being a bug we should strive for +compatibility with MS implementation. People won't like having Mono/MS +dependant code when using System.Drawing. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
