GNOME Bugzilla – Bug 737039
t6101-mathfuns-ods.pl fails
Last modified: 2014-09-25 04:30:17 UTC
t6101-mathfuns-ods.pl currently fails, see below. That failure is caused by an attribute order inversion that probably isn't serious but certainly is curious. This was in all likelihood caused by me changing pango_attr_list_insert_before into pango_attr_list_change in odf_text_p_apply_pango_attribute. We needed that change to prevent attribute ranges from becoming fragmented. We want, say, 0-10 to be bold, not 0-5 and 5-10. pango_attr_list_insert_before is too primitive here. But why did we need the "_before" part anyway? Are we saving or loading things in the wrong order? welinder@toshiba ~/gnome/gnumeric/test $ ./t6101-mathfuns-ods.pl --verbose ------------------------------------------------------------------------------- t6101-mathfuns-ods.pl: Check the ods exporter. # ../src/ssconvert 'mathfuns.ods' 'mathfuns.gnumeric' # ../src/ssconvert 'mathfuns.ods' 'mathfuns-new.ods' # ../src/ssconvert 'mathfuns-new.ods' 'mathfuns-new.gnumeric' --- mathfuns.xml 2014-09-20 14:41:19.718053191 -0400 +++ mathfuns-new.xml 2014-09-20 14:41:19.722053215 -0400 @@ -353,7 +353,7 @@ <gnm:Selection startCol="0" startRow="0" endCol="0" endRow="0"/> </gnm:Selections> <gnm:Objects> - <gnm:CellComment ObjectBound="H30" ObjectOffset="1 0 1 0" Direction="17" Print="1" Author="welinder" Text="welinder: The formula here is carefully set up to check actual equality, not almost-equality." TextFormat="@[color=00x00x00:0:93][bold=1:0:9]"/> + <gnm:CellComment ObjectBound="H30" ObjectOffset="1 0 1 0" Direction="17" Print="1" Author="welinder" Text="welinder: The formula here is carefully set up to check actual equality, not almost-equality." TextFormat="@[bold=1:0:9][color=00x00x00:0:93]"/> </gnm:Objects> <gnm:Cells> <gnm:Cell Row="0" Col="0" ValueType="60">MATH AND TRIGONOMETRY FUNCTIONS</gnm:Cell> diff died due to signal 1
odf_text_p_apply_pango_attribute is effectively called from odf_text_span_end so using pango_attr_list_change simply will not work: spans can be nested, so when we set the style of a span we cannot simply remove all styles that we set for included spans just because they are of the same type. In fact we need to keep those! I don't see how this has anything to do with fragmenting styles. If the spans are fragmented then using _before does not fix it, but really the problem is that one should never have written those fragmented spans.
I am considering raising the severity to major because we are now no longer correctly read a span of bold text that contains a subspan of normal weight text, or any such situation!
Don't worry about severity -- this is unreleased. If we change back, t6514 fails with this problem. Note, that italic has been split in two. - <gnm:CellComment ObjectBound="B15" ObjectOffset="1 0 1 0" Direction="17" Print="1" Author="Morten Welinder" Text="Rich text found here on this line. Very rich text. " TextFormat="@[italic=1:0:4][bold=1:5:9][underline=single:10:15][underline=double:16:20][strikethrough=1:21:23][underline=low:29:33][italic=1:35:44][bold=1:40:49]"/> + <gnm:CellComment ObjectBound="B15" ObjectOffset="1 0 1 0" Direction="17" Print="1" Author="Morten Welinder" Text="Rich text found here on this line. Very rich text. " TextFormat="@[italic=1:0:4][bold=1:5:9][underline=single:10:15][underline=double:16:20][strikethrough=1:21:23][underline=low:29:33][italic=1:35:40][italic=1:40:44][bold=1:40:44][bold=1:44:49]"/>
To save this in an ODF file we have to split the italic into two parts: we cannot have overlapping runs there. When we read it we may need to do the _before first (in case the generator used subspans of the same type, note that we do not and I haven't seen them with LO either but the standard allows them) and then do some normalization afterwards.
Andreas, can I ask you to come up with a patch? I would like to get a new release out soon due to (unrelated crasher) bug 737261.
Created attachment 287035 [details] [review] proposed patch This patch continues to use pango_attr_list_change by first collecting all spans (determining the endpoints of the spans) and then applying them in order as they appear.
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.