On 11/03/14 12:29, Miklos Vajna wrote:
Hi Matteo,
On Sun, Mar 09, 2014 at 01:21:37AM -0500, Matteo Campanelli <matteo.campanelli@gmail.com> wrote:
I'm writing to start a discussion and ask some questions on the idea
project in the subject of this email
([1<https://wiki.documentfoundation.org/Development/GSoC/Ideas#ODF_Formulas_in_Writer>
]).
Also - most important question (!!) - would there be anyone interested in
mentoring this project?
AFAIK the project idea is from Cédric, but he's not mentoring Writer
projects this year. This doesn't mean you can't propose to work on this
project, but it's not the best Writer project you could pick up. ;-)
right, and i dont' know much anything about formulas either.
- The goal of the project would be to enable users to write formulas in the
ODF Format [2]<http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part2.html>
and use this same format for the internal computations.
Correct, what's currently written is like this:
<table:table-cell table:style-name="Table1.B1" table:formula="ooow:<A1>+<A2>"
office:value-type="float" office:value="3">
The "ooow" part clearly indicates that it's something LO inherited from
OOo.
it also indicates it's not standard ODF.
- As far as I have understood, we may use the ixion library
[3]<https://gitorious.org/ixion> to
interpret ODF-style formulas. This library is already used by Writer for
interpreting formulas in doc/docx files (which, I suppose, are first
converted to the actual ODF format). [is this point of my interpretation
correct? Could anyone provide code pointers for the computation of formula
for .doc files?]
The ixion library is currently not part of LibreOffice in any way.
Regarding, .doc files, this is not handled in the filter (AFACS), just
the result of the formula is written to the file as a plain string.
that is the part of the idea proposal that i'm not sure about currently:
just using this "ixion" library for Writer formulas would put us in a
similar situation like what we currently are with text edition
components, where Writer has its own core and everything else uses
EditEngine instead; this duplication creates additional maintenance burden.
of course there are a lot of formulas (ODF part 2 is hundreds of pages),
and to me it appears quite sub-optimal to have multiple implementations
of all that.
there is already a "formula" module which Eike claims is not just used
by Calc but also by some Report(Builder/Designer/whatever) application,
which means it would probably be possible to use this from Writer too.
the problem is that apparently "formula" only contains the code to parse
and tokenize formulas; the actual evaluation is still in Calc's core and
tied to Calc's internals.
so i would welcome some input on what the architecture should look like
here:
1) is it possible to somehow abstract the formula evaluation
implementations from Calc internals (suppose it's mostly about
addressing/accessing the cells?) such that it could be used from
Writer too?
2) would it be a good long-term plan to migrate Calc to ixion too so we
eventually end up with just one formula evaluation engine?
3) or is it unrealistic to ever share the formula evaluation part?
- Part of the project will have to deal with import/export filters and
backward compatibility: first, files with formulas in the old-syntax should
still be parsed correctly; second, users should have the option of saving
in the old syntax or in the default new ODF syntax.
We have a general mechanism for that, in ODF 1.2 extended, probably you
could just write the new syntax, and you only need to make sure that the
old syntax can be read.
yep, that is just a simple matter of programming.
Also, I have two additional questions:
- the project idea page mentions changes in the code for the formula input
bar. What should these changes to the UI consist of specifically? Are they
mostly related to the strings produced by using the "Formula" dropdown menu
in the bar?
i think we shouldn't even start thinking about any UI changes until the
core work is mostly done, since the amount of time required there is
very difficult to predict.
However, for now, I would suggest focusing getting your easy hack ready
& accepted; that's required even in case at the end you're interested in
some other LibreOffice idea.
absolutely - here are usually more GSoC applicants than available
mentors, and the most important thing to get accepted is to show that
you can get useful work done. if we find that this one won't work out,
it's always possible to choose a different GSoC project.
regards,
michael
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.