Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index

Thank you, Piet. 

So do I need to install LO in order to correct this? Or, should I implement the following 
twelve steps?

1) use my eMail client to copy these frequent reports to my computer from Gmail

2) run a script or program to:

2.1) open that file

2.2) strip out everything before <html and after /html>

2.3) unpack the Quoted-Printable encoding (preserving the character set specification somehow)

2.4) save the file

3) switch to Calc

3.1) insert a temporary sheet from the file

3.2) select all data from that sheet

3.3) switch to the sheet where the data belongs

3.4) paste in the appropriate location

3.5) delete the temporary sheet

I think all those steps are doable. Per your suggestions, step 3.1 could be "open the HTML file in 
LO," step 3.3 would be "switch to the main document," and step 3.5 would be "close the source 
(temporary) spreadsheet without saving it. As I see it step 2.3 is the most complex.


-----Original Message-----
From: Piet van Oostrum <>
To: "James E. Lang" <>
Sent: Fri, 05 Feb 2016 2:39
Subject: Re: [libreoffice-users] Pasting Tabular Data Into Calc From An HTML Source

James E. Lang wrote:


I receive reports a regular basis from a pizza delivery driver who
sends them from his iPad. A raw data dump of the HTML part of a
sample report with customer identifying information replaced by
"Address 1" and "Address 2" will be pasted below my signature.

Receiving this report via Pegasus Mail I have two potentially
useful ways to paste the content of these reports into LO Calc
(HTML and RTF). Each of these has a issue though I can work with
the RTF method far more easily than the HTML method.

My problem with the HTML method (which, by the way, also exists
with tables of data copied directly from my power company's web
site) is that the header row (<th>) contains a colspan attribute
that is misapplied by LO. In this <th> row the first (and only)
field is not merged across any columns to its right but it should
be merged across 14 additional columns. In the first row below that
the first field is not (nor should it be) merged at all but in the
next four rows the first field is erroneously merged progressively
over 15, 29, 43, and 57 columns. The first (and again only) field
in the second table's <th> row is merged across 71 columns instead
of 11. The first field of next row is merged across the same 71
columns though it should not be merged at all and on the remaining
two rows the first field is erroneously merged across 81 and then
91 columns.

Has anyone else experienced this anomaly?
This is a known bug:
It seems this bug is more or less forgotten, as it is a regression, it has been identified when the 
bug was introduced, but there has been no activity for more than one year.

By the way, I noticed some anomalies in your HTML code. When I opened it in Firefox, two fields of 
the tables had moved out of the tables. It appears there are some Non-Breaking-Spaces in it which 
cause this. After replacing these with normal spaces, the tables appear as they should.

Secondly, when I open the HTML file with LibreOffice (version  5.1 RC 3) it opens as a spreadsheet 
with the correct layout, except the background colors. Also possible with Sheet > Insert Sheet From 
So this might be a workaround for you.
Piet van Oostrum <>
PGP key: [8DAE142BE17999C4]

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.