Re: [External] : Re: export org table to other formats (gnumeric or scalc or xlsx)

[Daniel Ortmann <daniel.ortmann@oracle.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!
>
>
>