GNOME Bugzilla – Bug 779635
Hyperlinks to defined names do not roundtrip
Last modified: 2017-03-10 15:03:41 UTC
../test/t6522-hlink.pl --subtests ods ------------------------------------------------------------------------------- t6522-hlink.pl: Check hyperlink ods roundtrip. --- hlink-tests.xml 2017-03-05 20:31:23.429255580 -0500 +++ hlink-tests-new.xml 2017-03-05 20:31:23.441255580 -0500 @@ -138,7 +138,7 @@ <gnm:StyleRegion startCol="0" startRow="12" endCol="0" endRow="12"> <gnm:Style HAlign="GNM_HALIGN_GENERAL" VAlign="GNM_VALIGN_BOTTOM" WrapText="0" ShrinkToFit="0" Rotation="0" Shade="0" Indent="0" Locked="1" Hidden="0" Fore="0:0:FFFF" Back="FFFF:FFFF:FFFF" PatternColor="0:0:0" Format="General"> <gnm:Font Unit="10" Bold="0" Italic="0" Underline="1" StrikeThrough="0" Script="0">Sans</gnm:Font> - <gnm:HyperLink type="GnmHLinkCurWB" target="NAMEDCELL" tip="NAMEDCELL Left click once to follow this link. Middle click once to select this cell"/> + <gnm:HyperLink type="GnmHLinkCurWB" tip="NAMEDCELL Left click once to follow this link. Middle click once to select this cell"/> </gnm:Style> </gnm:StyleRegion> <gnm:StyleRegion startCol="0" startRow="13" endCol="7" endRow="16"> diff died due to signal 1 What's new here is that setting the link target will now look for the name right there and then -- not simply store a string for later parsing.
Currently we write to ods: <text:a xlink:type="simple" xlink:actuate="onRequest" xlink:href="NAMEDCELL" office:title="NAMEDCELL Left click once to follow this link. Middle click once to select this cell">NAMEDCELL</text:a> If I understand this right then "What's new here is that setting the link target will now look for the name right there and then -- not simply store a string for later parsing" is a problem since in the ods importer we have to store the string and parse later: The definition for named ranges are virtually the very last thing in the content.xml file. But there may be other ways of handling this. We are parsing the file twice anyways... Nevertheless, this export does not seem to work in an import to LO so there may be more wrong.
Writing *ought* not to have changed. We're crazy for actually setting that (default) tip which includes GUI elements. We should probably keep it NULL and generate something on demand. However, that's not an ODS problem.
This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version. We still have to look at the import of these links to LO (to make sure our export is in fact correct).
For what it is worth, Excel is not happy with our generated ods files. It strips both internal links for the sample.
Created attachment 347316 [details] LO generated sample This file was generated from the xlsx file we produce from the hlink sample file. Excel seems happy with the xlsx file, so it's probably good.
<text:a xlink:href="#Sheet1.G12" xlink:type="simple">Sheet1!G12</t <text:a xlink:href="#NAMEDCELL" xlink:type="simple">NAMEDCELL</text:a>
While the round trip test claims to PASS, that is an illusion: saving the test file as ods and open it in Gnumeric yields a broken link.
Confirmed. That's interesting. I'll figure out what that is all about. For reference, this is what we create for a direct save: <text:a xlink:type="simple" xlink:actuate="onRequest" xlink:href="Sheet1!G12" office:title="Sheet1!G12 Left click once to follow this link. Middle click once to select this cell">Sheet1!G12</text:a> <text:a xlink:type="simple" xlink:actuate="onRequest" xlink:href="NAMEDCELL" office:title="NAMEDCELL Left click once to follow this link. Middle click once to select this cell">NAMEDCELL</text:a>
Created attachment 347324 [details] [review] Tentative patch This should fix scoping of names
Review of attachment 347324 [details] [review]: This looks good to me. Please commit.
Comment on attachment 347324 [details] [review] Tentative patch Committed
Interoperability with LO is now achieved. We need to test with Excel.
Sheet1!G12 works, but I note that we use a different syntax than both LO and XL do: "#Sheet1!G12" vs "#Sheet1.G12" NAMEDCELL imports, but does not work. I get a "References is not valid" when clicked. The name is simply not defined as far as Excel is concerned.
Excel writes... <table:named-range table:name="NAMEDCELL" table:cell-range-address="Sheet1.$H$13" table:base-cell-address="Sheet1.$A$1"/> We write... <table:named-range table:name="NAMEDCELL" table:cell-range-address="$'Sheet1'.$H$13" table:base-cell-address="$'Sheet1'.$A$1" table:range-usable-as="print-range filter repeat-row repeat-column"/> The problem is table:range-usable-as="print-range filter repeat-row repeat-column" With it, Excel silently ignores the name. Without, it works.
https://msdn.microsoft.com/en-us/library/jj671567(v=office.12).aspx says that XL supports none of the tokens, not even "none". LO doesn't write any table:range-usable-as attribute for this sheet. Suggestion: consider this a botched part of the ODS spec and drop it.
Since the table:range-usable-as attribute is optional and defaults to "none" we can leave it out. It's purpose is to indicate that this range can also be used for the named purposes. We can just leave it off. ODF does not really give any specific format for the local portion of the xlink:href value. Writing "#Sheet1.G12" would likely be a better idea then "#Sheet1!G12" since the former is based on the usual cell address.
range-usable-as has been dropped. Excel is happy with the resulting ods file.
We now write #Sheet1.A4 to ods files. That reveals that we don't actually read that syntax...
Read fixed. This problem has been fixed in our software repository. The fix will go into the next software release. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution.