GNOME Bugzilla – Bug 470089
Rich text attributes off-by-one when single quote gets removed
Last modified: 2007-12-04 17:31:24 UTC
Please describe the problem: if one change some format for chars after '/' in any cell, format info for 1st character will be lost as soon as focus changed to another cell. Steps to reproduce: 1. Type '+/??? in cell A1 2. Choose ??? and make it bold 3. Switch to cell A2 Actual results: only last two ? are bold Expected results: all three ? have to be bold Does this happen every time? yes Other information:
THis seems to depend on the first character. Is happens for /? but not for /g
'+/ggg gives the same thing. I see the reason -- it's the initial single quote that, when removed, make the offsets off by one. (And + might start an expression.) This might be messy to fix.
Created attachment 99943 [details] [review] Patch Not too bad. Review needed for this patch. It is tempting to move gnm_pango_attr_list_open_hole and gnm_pango_attr_list_open_hole over to goffice.
Created attachment 99991 [details] [review] Updated patch This patch also fixes the fact that currently there is no way to unset attributes.
gnm_debug_object? I guess this has nothing dirctly to do with this fix. I guess it's a short function for debugging purposes only. Do you want to commit it?
Created attachment 99998 [details] gnumeric sample file I have tried the updated patch and found the following issue: open the attachment in cell A2 celect the first two question marks since they are bold the bold button in the toolbar is depressed click on that bold button, it becomes undepressd and the question marks change to unbold enter the question marks are bold again when they should be unbold...
I see that problem too. Re. gnm_debug_object -- I might add that to gnumeric or goffice. It's a life saver when gdb acts up and thinks everything returns integers.
Created attachment 100016 [details] [review] Updated patch That was easy because I had just looked at the pango_attribute_equal documentation.
Created attachment 100042 [details] [review] Updated patch Minor optimization: empty markup is now treated as no markup.
The logic seems correct, but as long as we are moving the pango support code around let's stick it into a goffice/utils/go-pango-extras The same logic is going to be necessary for more complete rich text support there.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.