Super- and subscript also fail:

-            <gnm:Font Unit="10" Bold="1" Italic="0" Underline="0" StrikeThrough="0" Script="1">Sans</gnm:Font>
+            <gnm:Font Unit="10" Bold="1" Italic="0" Underline="0" StrikeThrough="0" Script="0">Sans</gnm:Font>


(With identical failure for xlsx; xls passes, somehow.)

xlsx fixed.

LO reads our xlsx files and shows super/subscript so ods ought to have a
place to put super/subscript.

There seems to be lots of code related to the GNM_HALIGN_FILL on the "write" side, but we write the wrong cell content: rather than the real cell content we write the filled version.

We have
<table:table-cell table:style-name="ACE-0x161a9f0" office:value-type="string"><text:p>hh​hh​hh​hh​hh​hh​hh</text:p>          </table:table-cell>
when the cell content should just be 'hh'.

Note that in ODF we can store the string values in two ways: as character content of the table:table-cell element or as value of the string-value attribute of the table:table-cell element. The former can carry formatting, the latter cannot. Since the 'filled' values can carry formatting, we need to use the former. Currently we use the formatted value. Clearly that cannot be done in the presence of GNM_HALIGN_FILL.

The let-LO-read-our-xlsx trick produces this style for B91 which shows
correctly as "TextTextTextText".  The contents is still "Text" in the cell,
though.

I think the magic is this: style:repeat-content="true"


    <style:style style:name="ce63" style:family="table-cell" style:parent-style-name="Default" style:data-style-name="N5000">
      <style:table-cell-properties fo:background-color="#ccffff" style:diagonal-bl-tr="none" style:diagonal-tl-br="none" style:text-align-source="fix" style:repeat-content="true" fo:wrap-option="no-wrap" fo:border="none" style:direction="ltr" style:rotation-angle="0" style:rotation-align="none" style:shrink-to-fit="false" style:vertical-align="bottom" style:vertical-justify="auto"/>
      <style:paragraph-properties fo:text-align="start" css3t:text-justify="auto" fo:margin-left="0in" style:writing-mode="page"/>
      <style:text-properties fo:color="#000000" style:text-outline="false" style:text-line-through-style="none" style:font-name="Sans" fo:font-size="10pt" fo:font-style="normal" fo:text-shadow="none" style:text-underline-style="none" fo:font-weight="normal" style:font-size-asian="10pt" style:font-style-asian="normal" style:font-weight-asian="normal" style:font-name-complex="Sans" style:font-size-complex="10pt" style:font-style-complex="normal" style:font-weight-complex="normal"/>
    </style:style>

Note that alignment-wise (FILL) it should be a reading problem: LO reads our files fine.

I should note that our current xlsx export does not preserve formatting of individual characters in cells, say "axa" with 'x' red and bold.
The interaction between those formats and the 'fill' alignment makes the ODF export a little tricky.

LO seems to have a different issue: In the presence of fill-alignment it does not render character formatting. In the files it saves only a single copy of the content as element content. While this seems to contradict what the ODF standard says we should surely do that too.

The GNM_HALIGN_FILL round trip should now be fixed.

For 'distribute', LO uses:

 <style:paragraph-properties fo:text-align="justify" css3t:text-justify="distribute" fo:margin-left="0cm"/>

with namespace xmlns:css3t="http://www.w3.org/TR/css3-text/"

It seems to me that if we want to also use the xmlns:css3t="http://www.w3.org/TR/css3-text/" we need to have it added it to 
gsf-opendoc-utils.[ch] in libgsf and depend on a new version of libgsf.

We are now exporting DISTRIBUTED alignment so that LO reads it. We don't import LO's version yet since I don't know about changing libgsf.

It appears that super/subscript applied to parts of the cell content works fine. 

Files with super/subscript applied to whole cells don't seem to be interpreted correctly by Gnumeric (or LO), but the cell style contains the specification
style:text-position="super 80%"
So this should be a reading problem.

subscript/superscript issue should be fixed.

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.