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


Hi Akash,

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
record types.

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
part.

  Eike

-- 
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

Attachment: pgpkMHDDd_DJq.pgp
Description: PGP signature


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.