Updates about Enhanced Database Ranges.
erack at redhat.com
Wed Jul 17 14:12:58 PDT 2013
I'm jumping in here, Markus is on vacation and I'll try to take over.
On Sunday, 2013-07-14 00:37:28 +0530, Akash Shetye wrote:
> I have many issues to look at concerning export of formatting information.
> 1. The ScStyleSheet(s) are not exported by LO Calc when xlsx->LO Calc ->new
> xslx doc is done.
I can't help you much there, I'm not too familiar with the xlsx export
other than having a general idea how it is triggered. Probably it needs
some if(xml) condition to be implemented for styles, similar to other
> this is because through sc/source/filter/excel takes care about importing
> the style information and creating ScStyleSheet(s) from it; there is no
> code to export the style sheet data. So I am looking at coding in that so
> that style information can be saved to excel as well. Currently I am
> writing skeleton code and just SAL_DEBUGing around to figure things out in
> the filter/excel area.
Also take a look at files in sc/source/filter/oox/ where the import is
implemented, and parts where designed to also handle export but aren't
used for export other than the formula expressions.
> I am looking at writing <dxf> data into style.xml of the created xlsx
> first. Seems no <dxf> style information is ever written by current code.
Might be. The OOXML export was added last.
> 2. The database ranges created by excel (successfully imported into LO
> Calc) are not exported to xlsx! Seems there is no code to export the
> ScDBData objects to xlsx.
Excel does not have the same concept of database ranges. Specifically
the general distinction between "normal" named expressions (ranges) and
our database ranges is unknown to Excel. AFAIR in the binary export our
ScDBData are exported as named expressions, but I'm not sure right now.
To export the new Table ranges this probably needs to be implemented
from scratch to handle only the Table ranges.
> I would like to achieve this after the style
> export is done with. This is because the styles thing is more interrelated
> to different tiny parts of code and will take a lot of time.
I'd rather ask you to postpone that and instead take the opportunity and
focus on the formula expression import, as the expression compiler and
stuff is my area of expertise. Being able to import the formula
expressions of such Tables from OOXML would be a huge step forward
interoperability-wise and if we preserved the context we could also
display and rewrite them to OOXML as expected by Excel while at the same
time translate them to ODFF valid expressions, and even restore them to
the special syntax when reading from ODF. This will probably the hardest
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key ID: 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
For key transition see http://erack.de/key-transition-2013-01-10.txt.asc
Support the FSFE, care about Free Software! https://fsfe.org/support/?erack
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: not available
More information about the LibreOffice