Apache OpenOffice (AOO) Bugzilla – Issue 127105
paste to AOO reads SDVAL or SDNUM instead of <td> value </td>
Last modified: 2016-11-13 18:28:39 UTC
Created attachment 85668 [details] Calc doc showing results of two paste types Only tested this on Windows 7 PC. I copied a table from one of my web pages (http://www.stivescameraclub.co.uk/bs3/programme.html) and pasted into Calc and the dates were changed. Using the context menu and choosing Paste Special / Unformatted Text pasted in the correct dates. Writer pastes the SAME wrong dates as well. Again Paste Special / Unformatted Text works. Have attached a Calc spreadsheet showing the changes.
I could replicate this bug using above link. System Information: Mac OS X Sierra (Version: 10.12.1) OpenOffice version: 4.1.3 AOO413m1(Build:9783) - Rev. 176138 Steps to reproduce: 1. Open http://www.stivescameraclub.co.uk/bs3/programme.html on your web browser. 2. Copy table on which is present on the webpage. 3. Open Spreadsheet (Calc). 4. Perform paste operation on any of the cell. Expected Output: 1. Numeric values change. Output I got: 1. Numeric values change. Further Testing: Try pasting with 'paste special' function, Everything works fine. I tried same thing with different tables which are available on web. Paste function works perfectly.
<TR> <TD WIDTH="35" HEIGHT="17" ALIGN="center">SEP</TD> <TD WIDTH="19" ALIGN="center" SDVAL="2" SDNUM="2057;">05</TD> <TD WIDTH="47" ALIGN="center" SDVAL="7.30" SDNUM="2057;">7.30</TD> <TD id="myTableCells" WIDTH="229">WCPF Members Disc</TD> <TD id="myTableCells" WIDTH="211"> </TD> </TR> AOO uses the values from the SDVAL fields instead of between the <TD> and </TD> tags that web browsers show.
See https://help.libreoffice.org/Writer/Special_Tags Does AOO do this too or is it a LO enhancement? I am not sure why AOO reacts on SDVAL. It should not do this from a requirements point of view. HTML does not specify such a Value for TD as far as I know.
Okay this behaviour is realy old. Related bugs: https://bz.apache.org/ooo/show_bug.cgi?id=11684 (about OO exporting this rubbish) https://bz.apache.org/ooo/show_bug.cgi?id=29733 (about dublicate output, maybe even a dublicate)
*** Issue 88071 has been marked as a duplicate of this issue. ***
changeing title to something more technical terms.
I think this issue /isn't/ a duplicate of issue 127105. 88071 describes problems with the /export/ of numbers resp. the number format. SDVAL and SDNUM are special tags that are written from StarOffice/OpenOffice/LibreOffice. As stated in comment 2 these tags are reimported correctly! So this behaviour is wanted and not an issue. We don't know why these tags are written into the named web page. Maybe there is also an export problem but this can only be stated by the producer of the web page. So in my opinion: 88071 is CONFIRMED, but 127107 should be RESOLVED: NOT AN ISSUE.
Expectation is to import HTML specification. It says so on the Paste button Popup. Since SDVAL is something OO Family specific, we should ignore it. If we want to support such a behaviour we should add an own Filter for this. my 2 cent.
As per a similar LibreOffice bug: https://bugs.documentfoundation.org/show_bug.cgi?id=60071 The SDVAL and SDNUM carry numeric and formatting information, "not only when saving/loading as HTML but also when copying via clipboard and paste special in HTML format. For example it is possible to transport the assigned number formats of a copied Calc cell range pasted as HTML to Writer." (comment 4 by Eike Rathke) What I think we should be doing, is checking whether the value between <TD> and </TD> matches the SDVAL value when formatted by SDNUM, and letting the <TD> value win if not.
I dont agree. From HTML perspective it is still a messay solution. However in an OOHTML approach, yea we should do this.
(In reply to Peter from comment #8) > Since SDVAL is something OO Family specific, we should ignore it. This is a contradiction in itself!