[GSoC] On "ODF Formulas in Writer"

[Michael Stahl]

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