From: Daniel Ortmann <daniel.ortmann@oracle.com>
To: emacs-orgmode@gnu.org
Subject: Re: [External] : Re: export org table to other formats (gnumeric or scalc or xlsx)
Date: Sun, 4 Jul 2021 18:22:39 -0500 [thread overview]
Message-ID: <0f79edb0-0825-9643-8d44-013e1eedfe4a@oracle.com> (raw)
In-Reply-To: <87fswtn1ei.fsf@gmail.com>
I highly recommend a recent LibreOffice. Nearly everything I do is
through LibreOffice and CSV files. MS Excel has problems when using
inter-field-separators such as semicolons.
When I receive Excel (or other) spreadsheets from people, I must first
convert them into CSV files to clear out the crazy manual formatting in
order to process them content.
Often a flow such as this helps:
*.xlsx => *.csv => Emacs (to cleanup text, newlines, whitespace) =>
LibreOffice (to sort, reorder, analyze with better use of graphical
realestate) =>
*.org tables with Emacs macros to process further =>
*.csv => LibreOffice to generate fresh *.xlsx
Sometimes cleanup with *nix 'cut' and 'paste' tools helps greatly:
- *.csv => cut -d\; -f1-3 >file1
- *.csv => cut -d\; -f4- >file2
- Edit content or add a new set of data
- paste -d';' file1 file2
etc.
Very powerful.
On 7/4/21 5:00 PM, Tim Cross wrote:
> Uwe Brauer <oub@mat.ucm.es> writes:
>
>> Hi
>>
>> A couple of days ago I asked about importing excel formula into org
>> tables, and they only ways seems to do it manually.
>>
>> I just realised that I need it also the other way around, exporting to
>> some spreadsheet format, like gnumerica or scalc or xlsx.
>>
>> But that look equally difficult, isn't.
>>
>> Some hints would be welcome.
>>
> The big problem here is that there is no single format understood by all
> these different programs which you can use. While CSV works OK for data,
> it does not support formulas and other meta data. In particular,
> translating formulas is a real challenge.
>
> I went down this rabbit hole some years back i.e. having a workflow
> which allowed me to interact with others who used Excel and allowing me
> to use org mode.
>
> It took hours and hours of additional work and never worked reliably
> because
>
> - I never found a way of 'exporting' to a format which could be imported
> by Excel and included formulas
>
> - None of the Excel export formats support full export of Excel -
> especially at the meta data level i.e. Visual Basic macros and other
> 'objects'. Workbooks were a real pain.
>
> - Constantly having to do 'hand tweaking' to fix formulas and other
> 'meta' information (both directions). When exporting to Excel, I would
> have to open the spreadsheet in another program to 'clean it up'
> before sending it to colleagues.
>
> - Too many different Excel versions. This issue may not be as bad now,
> but back then, there were multiple xlsx versions and you would get
> different results depending on the version.
>
> In the end, I gave up and either just used LibreOffice (Linux) or an OSX
> program (I think it was called numerics, but too long ago to recall
> accurately - it was not an Apple program). In the end, my decision was
> to only use org if either I only needed the data (possibly adding
> formulas manually), would not need to export back to Excel (no
> collaboration) and only need export to org once. Otherwise, use
> LibreOffice or another program able to understand xlsx natively.
>
> One thing which we did use for a time was to connect the excel
> spreadsheets with a database. The excel spreadsheet would pull the data
> from the database and apply formulas/macros to that data. I was then
> able to pull data from the database into org and then export it back
> into the database. It took a bit to setup - used Visual Basic to manage
> data import/export into database and needed an Excel based UI to do some
> CRUD operations and then some scripts on the Linux side to
> extract/update the data from org. This sort of worked, but had issues
> with synchronisation of data. It really needed a much more sophisticated
> database API to make it work well which could handle versioning or
> resolve data conflicts and dependencies etc.
>
> To some extent, I guess Excel is a good example of what RMS was
> concerned about and the problem with closed proprietary standards. While
> someone can reverse engineer the formats and spend the time to develop
> converters, they remain at the mercy of MS who can simply change the
> formatting at their whim. Most efforts I've seen seem to run out of
> puff because of the efforts needed to maintain things.
>
> Of course, life would probably be better if so many project managers
> stopped using Excel for EVERYTHING! I've noticed over the last 10+ years
> a growing use of Excel in the 'enterprise' as the default 'tool' to
> collect and manage information. To many, it seems like a simple
> solution, but in reality, you end up with all sorts of valuable
> information floating around in multiple spreadsheets and spend far too
> much time entering/updating data using a crappy interface and tweaking
> format commands. I've seen more than one project almost hit the rocks
> because someone was working off an old excel spreadsheet with the wrong
> data. If you raise this concern, the likely outcome is a decision to use
> MS Project, then your really stuffed!
>
>
>
next prev parent reply other threads:[~2021-07-04 23:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-04 12:40 export org table to other formats (gnumeric or scalc or xlsx) Uwe Brauer
2021-07-04 22:00 ` Tim Cross
2021-07-04 23:22 ` Daniel Ortmann [this message]
2021-07-05 14:48 ` [External] : " Uwe Brauer
2021-07-05 14:56 ` Eric S Fraga
2021-07-06 4:01 ` Greg Minshall
2021-07-07 7:01 ` [R example for org-table with ifs] (was: [External] : Re: export org table to other formats (gnumeric or scalc or xlsx)) Uwe Brauer
2021-07-07 11:59 ` [R example for org-table with ifs] Eric S Fraga
2021-07-08 5:13 ` [R example for org-table with ifs] (was: [External] : Re: export org table to other formats (gnumeric or scalc or xlsx)) Greg Minshall
2021-07-08 6:26 ` [R example for org-table with ifs] Uwe Brauer
2021-07-08 7:33 ` Greg Minshall
2021-07-05 6:28 ` export org table to other formats (gnumeric or scalc or xlsx) Uwe Brauer
2021-07-05 14:51 ` Uwe Brauer
2021-07-05 22:29 ` Tim Cross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0f79edb0-0825-9643-8d44-013e1eedfe4a@oracle.com \
--to=daniel.ortmann@oracle.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).