From: Tim Cross <email@example.com>
Subject: Re: export org table to other formats (gnumeric or scalc or xlsx)
Date: Mon, 05 Jul 2021 08:00:56 +1000 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
Uwe Brauer <email@example.com> writes:
> 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
- 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 22:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-04 12:40 Uwe Brauer
2021-07-04 22:00 ` Tim Cross [this message]
2021-07-04 23:22 ` [External] : " Daniel Ortmann
2021-07-05 14:48 ` 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
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:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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
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).