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


https://bugs.documentfoundation.org/show_bug.cgi?id=74580

--- Comment #30 from Gareth <gareth.adamson@gmail.com> ---
In reply to Comment #29 (from V Stuart Foote)

re. whether a parallel task is needed for the HTML import.

Importing sheet data from HTML is very much a corner case, in fact a user given a preference 
shuold be picking TSV or CSV to assure data quality compared to a table pulled from HTML.

Importing a table is one possibility, but you can simply save or generate a
spreadsheet as HTML. It has some advantages over CSV, especially in formatting.

Anyway, it doesn't really matter whether it's a corner case, or what some
developer or discussion participant magisterially thinks users 'should' do. The
fact is that it is an existing use case, in regular use in businesses I have
come across. Calc currently handles it in the same way as importing a CSV
(simplified, since importing HTML is simpler) and I merely point out that it
would be good practice for it to continue to do so, if the way of importing
CSVs changes.

TSV may also be a corner case. I had to look it up. But if Calc currently
handles it in the same way as CSV, yes, it would be good to continue to do so.

Having the minimally intrusive textimportoptions.ui dialog [1][2][3] appear when opening a 
non-CSV document, including HTML, into Calc is not the issue here. Rather improving work flows 
for parsing complex CSV

The dialog is as intrusive as the CSV dialog, in the sense that it appears
every time.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Context


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.