Issue 972 - Alignment of baselines of formula and text in writer
Summary: Alignment of baselines of formula and text in writer
Status: CLOSED FIXED
Alias: None
Product: Math
Classification: Application
Component: ui (show other issues)
Version: 627
Hardware: All All
: P3 Trivial with 197 votes (vote)
Target Milestone: 3.4.1
Assignee: michael.ruess
QA Contact: issues@sw
URL:
Keywords: oooqa, rfe_eval_ok, usability
: 6868 39264 53674 56261 (view as issue list)
Depends on:
Blocks: 105217
  Show dependency tree
 
Reported: 2001-05-29 10:22 UTC by issues@www
Modified: 2011-03-14 08:07 UTC (History)
19 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
exemple of vertical alignment problem (8.91 KB, application/vnd.sun.xml.writer)
2006-02-16 10:56 UTC, cdeval
no flags Details
Patch, based on DEV300_m83, written by Michal Spiziak, to fix the Baseline alignement issue (20.16 KB, patch)
2010-10-06 21:16 UTC, eric.bachard
no flags Details | Diff
Adding mock-up for new UI option (51.20 KB, image/png)
2010-10-18 12:32 UTC, thomas.lange
no flags Details
Updated UI screen shot as discussed with FL and OD (18.79 KB, image/png)
2010-10-22 11:56 UTC, thomas.lange
no flags Details
Test formula inserted in Writer. (4.80 KB, image/png)
2011-03-13 18:59 UTC, promurilo.math
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description issues@www 2001-05-29 10:22:29 UTC
When a formula is inserted in a writer document (anchored as char) the 
baselines of the formula and the surrounding text are not aligned.
Thus the formulas appear jumping up and down on the textline.

In principle this can be corrected by hand by adjusting the vertical alignment 
of the formula, but it is difficult to do it with sufficient precision - so it 
should happen automatically.

What should happen is: The formula editor should return not only height and 
width but also the position of the baseline (the depth) within the formula to 
the containing application. If this application happens to be writer and the 
alignmenttype happens to be as-char, then writer should adjust the vertical 
alignment accordingly. In other cases nothing special should happen.
Comment 1 stefan.baltzer 2001-05-29 12:37:55 UTC
Reassigned to Falko.
Comment 2 falko.tesch 2001-06-13 11:03:58 UTC
Will get back to this issue later. Thx. for submittance.
Comment 3 burnus 2001-08-17 22:34:54 UTC
This is especially needed for one letter symbols like "vec a" since
you cannot mimic this behaviour using italic and in the middle of a
text this looks rather odd (or you have to change it by hand all the
time).
Comment 4 Unknown 2001-11-08 22:39:57 UTC
changing QA contact from bugs@ to issues@
Comment 5 thomas.lange 2001-11-09 09:21:27 UTC
TL->FT, QA: This corresponds to bug #90053
Comment 6 falko.tesch 2003-10-06 10:58:20 UTC
When a formula is inserted in a writer document (anchored as char) the 
baselines of the formula and the surrounding text are not aligned.
Thus the formulas appear jumping up and down on the textline.

In principle this can be corrected by hand by adjusting the vertical
alignment of the formula, but it is difficult to do it with sufficient
precision - so it should happen automatically.

What should happen is: The formula editor should return not only
height and width but also the position of the baseline (the depth)
within the formula to the containing application. If this application
happens to be writer and the alignmenttype happens to be as-char, then
writer should adjust the vertical alignment accordingly. In other
cases nothing special should happen.
Comment 7 falko.tesch 2003-10-06 10:58:55 UTC
.
Comment 8 thomas.lange 2003-10-07 10:15:26 UTC
*** Issue 6868 has been marked as a duplicate of this issue. ***
Comment 9 bettina.haberer 2003-10-17 13:27:40 UTC
*** Issue 6868 has been marked as a duplicate of this issue. ***
Comment 10 Unknown 2003-11-13 22:36:55 UTC
I would like to request this to be changed to a defect, and fixed
sooner than the current time line would seem to indicate.  Creating a
simple equation of a^2+b^2=c^2 and setting the frame as a character
will not line up at all with the rest of the text in a sentance.  I
work for a company that is trying to use OOo, and this is causing
major problems.  We are programatically creating documents, and having
to manually place the equation is unacceptable.  Please consider
fixing this sooner.
Comment 11 thomas.lange 2003-11-14 07:12:24 UTC
Actually this one is a double of an internal bug (#90053#) which has
the correct target 8.0 i.e. OOo 2.0.
Thus I'll change the target of this one accordingly.

Also the other doublette #i6868# has OOo 2.0 as target.
Thus I'll set this one as doublette of the other one.



*** This issue has been marked as a duplicate of 6868 ***
Comment 12 thomas.lange 2003-11-14 07:13:45 UTC
Ooops.... The other one was already closed.
Reopened...
Comment 13 bettina.haberer 2003-11-28 14:36:34 UTC
Hello Andreas, I suppose to implement a solution in the Q. In the
duplicate task 90053 (Bugtracker) FME suggested the implementation of
new alignment option like "Align baseline to baseline" in the "Format
/ Object - Type" dialog for the vertical position. 
Please give approval for this evaluated OO.o 2.0 flagged issue. 
If you confirm with the target OO.o 2.0, then please keep it on your
owner (or the owner of the concerning developer) for implementation.
In case you want this issue for 'OOo Later', then please reset the
target milestone. If you decline the issue finally, please set the
resolution to 'Wontfix' (but do not close). In case of 'OOo Later' or
'Wontfix' please reset it on Bettina's owner. Thank you.
Comment 14 andreas.martens 2003-12-12 14:31:10 UTC
Yes, OOo2.0 is the right target.
Comment 15 thomas.lange 2004-01-15 14:53:00 UTC
TL->FME: I think that means BH has agreed to the "Align baseline to baseline"
option. Please fix this one and after that hand this issue back to me.
Comment 16 thomas.lange 2004-01-15 14:54:59 UTC
.
Comment 17 frank.meies 2004-01-15 15:35:13 UTC
FME->TL: Is the GetBaseline() method already implemented in math?
Comment 18 thomas.lange 2004-02-10 04:46:18 UTC
.
Comment 19 thomas.lange 2004-02-10 04:49:02 UTC
Effort added.
Comment 20 thomas.lange 2004-06-01 09:48:54 UTC
As discussed with MRU retargeted to OOo later because of other issues at hand.
Comment 21 jmgervais 2004-06-10 19:17:47 UTC
I'm so disappointed :-(
I think the success of OOo/StarOffice _in schools for example_ is partly due to
the possibility to write easily (with dmaths.org if necessary) math formulas.

But this problem of baseline alignment create a serious discomfort and worse
quality documents. It's on my opinion the last serious problem for scientifics
users.
I realy hope it will be improved soon, even if I try to be realist. What a
simple user could do to help it?

Anyway, thank you for all developpements,
Regards.
Comment 22 quetschke 2004-06-17 16:34:44 UTC
Following a discussion on IRC, mh (=Ratte_) suggested to ask for the
developers opinion.

* trimmed IRC-log *
Ratte_	DanielC, you should coordinate with developer (tl) directly to get it set
to 2.0
(snip)
vq	Ratte_, DanielC : IMHO it is important, try something simple like x_a as a
formula in normal text. The baseline of the text and the x doesn't match. This
looks unprofessional.
(snip)
Ratte_	vq, but this should be discussed the math developer and qa first.
* trimmed IRC-log *

OOo is starting to spread in the scientific community, but the exact positioning
of formulas in text is a must, you cannot. Try the above simple example with x_a
and you will see that the baselines doesn't match. Positioning every formula by
hand is annoying and error prone.

Can you please reconsider the decision for the target milestone. OOo Later means
most propably OOo 3.0 (Let the marketing decide) and that means at least 18month
after 2.0.

* The following is just a marketing related personal opinion *
P.S.: Don't forget the scientific background of many decision makers, the
quality and usability of OOo now has a strong influence on the future decisions
made by those people when they advance to new position.
Comment 23 pascalc 2004-10-29 11:06:41 UTC
This problem is one of the two problems which prevent mathematic teachers to use
OpenOffice.
Comment 24 lohmaier 2004-12-19 20:14:50 UTC
keywords... Usability because you have to align the formula manually and this is
a tedious job...
Comment 25 jmgervais 2005-01-13 21:00:13 UTC
For the moment, is the position of the baseline of a formula (for example '56%
from bottom') readable with a OOoBasic macro?
Comment 26 thomas.lange 2005-01-14 09:07:22 UTC
Currently not.

First a property (or some other method) to obtaion it must be provided at the
UNO model. And second some formula do not have a baseline internally yet. At
least this is the case for sth like "a over b". There may be other cases
(programmatically speaken node types) where this may happen but currently I'm
only aware of this one, but that needs to be looked into. However internally
there is already a function that knows if there is a baseline or not. If it is
not there yet a 'virtual' value has to be calculated.

If those twp things were done a macro should be possible. 
BTW a macro was the solution planned to provide since having it done
automatically arranged would have required a new option 'Base line' in the
dialog "Format/Objects - Type" in the left listbox for the vertical positioning.
That is for vertical positioning (of objects anchored 'As charcacter'!) 'Base
line' to 'Base line' should have been available.
Even though I would have liked it otherwise, it was decided that adding a new
option that needs to be taken care of in numerous other places was too much
trouble and therefore only a macro should be used since it is less troublesome
in implementation.
Comment 27 jmgervais 2005-01-21 22:38:47 UTC
Sorry to insist, but:

. /tl/ said:"...And second some formula do not have a baseline internally yet. At
least this is the case for sth like "a over b". There may be other cases..."

I don't undestand all details (my english & my programming knowledge are poor)
but internally, in math module, OOo seems knowing where line level is, since it
writes on the right position a formula like "a over b = 1 over { b over a}=lim
from infinity f"? The line position must be calculated somewhere inside...

. And about the too complicated option, il should be possible to use the
existing 'verticaly centered' choice, when object is anchored 'As charcacter'
for this position (align to baseline level), even if the name is unchanged,
because it's more natural and absolutely necessary for scientific community! 

I'm sure, like /pascalc/ said, that an uncorrect resolution of this issue would
prevent using OOo in schools and by scientifics... Please, don't forget us ;-)

Regards
Comment 28 thomas.lange 2005-01-24 09:46:32 UTC
"a over b = 1" has a baseline because of "= 1". 
"a over b" alone currently has none.

About the new option: that it was needed I was told by our layout & formatting
specialist and if he says so I don't doubt him. ^_~
Comment 29 cdeval 2005-07-05 14:15:25 UTC
I'm very sorry with the problem of alignement(The MS WORD equation fields I use
don't have the problem.)
The problem is open since 2001 and seems to be not resolved in the next version 2.0.
But It's a really important problem for us (math teachers) : formulas are always
verically centered and it's not acceptable (at least a formula in 'mode text'
MUST be aligned with text around. That's a 'sine qua non' condition of
openoffice success in educational communauty)
Can you solve that problem in version 2.0 ?
Comment 30 colman 2005-07-08 03:04:06 UTC
Issue Target Milestone should be marked as 00 2.0
Comment 31 lohmaier 2005-08-30 18:53:38 UTC
*** Issue 53674 has been marked as a duplicate of this issue. ***
Comment 32 lohmaier 2005-08-30 18:55:54 UTC
*** Issue 39264 has been marked as a duplicate of this issue. ***
Comment 33 jmgervais 2005-10-14 23:02:37 UTC
. After Dmaths (http://www.dmaths.org), a new tool for helping formulas edition
is born: welcome to cmath for OOo! See http://cdeval.free.fr in french (under
GPL like Dmaths).

Its author says, like many scientifics, that "it is absolutely necessary to
solve that issue": http://cdeval.free.fr/article.php3?id_article=71 (in french)

. An other free tool allows to include vectorial drawing made 'in line' with
mouse: http://tracenpoche.sesamath.net/article.php3?id_article=24
(sorry, french only for the moment)

. Dmaths is translated is several languages and will be soon complayant with
OOoV.2 It's a very efficient tool for formulas, drawing...

=> OOo could be a very powerfull tool for scientifics and those independant
developpements are prooving it is true. 
In fact *it is* a wonderfull program, but #972 issue restains productivity and
quality of documents (manual + approximative alignment), dont forget it, please.
In schools for example, scientific teachers could more easily ask for OOo
installation, and pupils using OOo is one off the best publicity (see Micr.
strategy with education).

Thank you !
Comment 34 lohmaier 2005-11-03 19:23:43 UTC
*** Issue 56261 has been marked as a duplicate of this issue. ***
Comment 35 lohmaier 2005-11-03 19:25:38 UTC
add fl to cc
From issue 56261:

MRU->FL: the vetical-alignment problem of formula objects has been discussed for
a long time... Maybe in formulas we should implement something like a baseline
pointer e.g.
This could refer than  in the surrounding text.
Comment 36 cdeval 2006-02-16 10:50:21 UTC
Hello,

I'm happy to see the status 'started'.
It would be great to see 'Target milestone' set to 2.0.x !
This issue is more than an enhancement.
That's a 'sine qua non' condition of openoffice success in educational
communauty. More and more teachers use OOo to type scientific documents with
Dmaths or CmathOOo. This problem is really embarrasing when you insert a lot of
formulae in a document as we do so easily with dmaths and CmathOOo.
Please don't forget thousands teachers !
We spend a lot of time to offer a free gnu/gpl addon for OOo and this problem
limits the interest of them because we have to position manually all formulae ;
otherwise we get a poor typeset quality document.
thank's for your job.

thank's for your 
Comment 37 cdeval 2006-02-16 10:56:23 UTC
Created attachment 34214 [details]
exemple of vertical alignment problem
Comment 38 Mathias_Bauer 2006-02-22 14:05:48 UTC
I want to describe our findings so that you can see where the problems are that
we have to solve. 

First it should be clear that we only talk about formula objects that are
anchored "as character". I don't think that the feature "base line alignment"
makes sense for other anchoring modes.

Currently the alignment of an object is described by two parameters, one
describing the anchor point in the text, one the way how the formula object is
aligned to that point. While for the first attribute "base line" is possible, it
isn't for the latter, here only "top, bottom, center, from top" are possible
(note: in the GUI "from top" is unfortunately called "from bottom", but this is
for "historical" reasons). "From top" allows you to have a free positioning of
the formula relative to the text.

It is very important that the way how we describe the position of the formula
object is compatible to older versions of OpenOffice.org so that loading
documents using base line alignment into such versions will give the correct
display. Of course what you can't get then is maintaining the baseline alignment
when you change the formula in this old version. 

That said we can't just simply add a new "base line" orientation to the object,
we have to stick to the four orientations we have, at least in the file format.
In the GUI we can have the new "base line" attribute, but it must be treated
explicitly. 

My suggestion is to have the "base line to base line" orientation only at
runtime (when the document is edited). In the file format we translate this to
"free positioning relative to the text" by using "from top" orientation. The
distance will be calculated from the difference between the "top-base line" and
the "base line - base line" alignment.

If you load this document into any version of OpenOffice.org you will always get
perfect base line arrangement of text and formula - until you change either of them.

If either the text base line moves due to changes in the text attributes or if
the formula base line moves due to changes in the formula we simply can
recalculate the position of the formula object and again store it as "from top".
In the first case (change text) Writer must ask the formula for its base line
and then start the calculation, in the latte (change formula) case the formula
must send a notification to Writer that it should do this.

The problem now is that we don't want to have this recalculation for *all*
objects that are aligned "from top", so an additional setting is needed in the
Writer file format that triggers recalculation if necessary. Old versions of OOo
will ignore this setting of course so changing the formula in such a version
will lose the base line alignment.

Such setting is an extension of the file format, so we must talk to the Open
Document TC about it. I don't expect a problem here, because it's a "compatible"
change, but it will take some time.

Selecting the new alignment in the GUI will export this to to "from top" and
switch on the new setting in the XML file format.

What we have to do for this:

- extend file format, implement loading/storing of the new attribute
- add and implement "base line" item in the "Format Frame" dialog of Writer
- implement recalculation of positions as described above 
- implement base line calculation in Math
- implement an API to retrieve and recalculate the base line from a formula object
- implement a listener/broadcaster relationship in Writer that triggers
recalculation of position if the base line of the formula changes

I hope I didn't forget anything. :-)
Currently we are going to hand over the extension of the file format to the
OASIS Open Document TC as the first step.
Comment 39 jdthood 2006-02-22 15:52:04 UTC
Why is it so important to preserve backward compatibility?  Why not simply
rev the file format and treat saving to the old file format as an export,
involving a conversion from base-line orientation to from-top orientation
(with loss of information)?  That would probably be easier.  The base-line
orientation emulation approach just described sounds like a difficult and
fragile affair.
Comment 40 Mathias_Bauer 2006-02-22 22:42:50 UTC
There is nothing like an "old" file format - we only have "the" Open Document
File Format. It would be bad for its reputation if only a few months after its
birth we changed it incompatibly. MS Office was very often bashed for doing
this, we can do better. I'm even afraid that old OOo versions will report an
error on loading documents with a new value for "vertical-pos" (though I'm not
sure). This would be even worse compared to MS Office problems of the past.

I also don't think my proposal is a "fragile affair". The only difference to a
more rigid file format change is that we split up the information in three
instead (vertical-pos, vertical-rel and a new one) of two attributes as it is
now (only vertical-pos and vertical-rel).
Comment 41 cdeval 2006-02-27 21:51:14 UTC
" My suggestion is to have the "base line to base line" orientation only at
runtime (when the document is edited). In the file format we translate this to
"free positioning relative to the text" by using "from top" orientation. The
distance will be calculated from the difference between the "top-base line" and
the "base line - base line" alignment. "

Yes, it seems to be the best issue to get compatibility with older OOo.

" If either the text base line moves due to changes in the text attributes or if
the formula base line moves due to changes in the formula we simply can
recalculate the position of the formula object and again store it as "from top".
In the first case (change text) Writer must ask the formula for its base line
and then start the calculation, in the latte (change formula) case the formula
must send a notification to Writer that it should do this. "

For the first case (change text) I think it's not necessary to recalculate base
line for two reasons :
1) Is there a situation where the change of text attributes move the text base
line ? If you change the size of character, for exemple, the base line doesn't
change, does it ? So the "from top" is still good ? Am I wrong ?
2) Currently, I you change text attribute (font, size, color, ...) of a
paragraph which includes a formula, this one doesn't change because these
parameters are independant of text. So, you get a difference between text and
formula. I think it wouldn't be a defect if alignement wouldn't change. A double
click on formula to open math module will recalculate the right position. And if
there is too much formulae to recalculate position one by one, add-on such as
dmaths or CmathOOo will do the job (currently, it's true with font name and size
for all formulae in a text or a selected text because OOo can't do it automatically)

In the latte case (formula change) I think it's necessary to recalculate base
line alignement. It's probably the easiest to develop, isn't it ?

" The problem now is that we don't want to have this recalculation for *all*
objects that are aligned "from top", so an additional setting is needed in the
Writer file format that triggers recalculation if necessary. Such setting is an
extension of the file format, so we must talk to the Open
Document TC about it. I don't expect a problem here, because it's a "compatible"
change, but it will take some time. "

If you don't recalculate alignment when text change (the first case) you don't
need additional settings anymore... and no modification of file format.
You need only to modify the math module to add a 'base-line' alignment, which is
 converted on exit of the module in a "from top" alignment.

"What we have to do for this:

- extend file format, implement loading/storing of the new attribute"

perhaps not ?

"- add and implement "base line" item in the "Format Frame" dialog of Writer"

yes

"- implement recalculation of positions as described above "

yes for formula changes, but reserved to module math or api.

"- implement base line calculation in Math"

of course !

"- implement an API to retrieve and recalculate the base line from a formula object"

yes, yes, yes : a new FormulaPropertie such as "BaseLineAlignment (boolean)" and
a recalculation when instruction setmodified(True) is executed.

" - implement a listener/broadcaster relationship in Writer that triggers
recalculation of position if the base line of the formula changes"

no need ?

"I hope I didn't forget anything. :-)"

I don't think.
Thank's a lot to consider our request.
I hope I didn't say too much mistakes.
bye
Comment 42 Mathias_Bauer 2007-02-23 13:53:01 UTC
We are currently discussing the baseline alignment in the OASIS ODF TC.
There are some problems regarding the file format.

My suggestion to make "baseline" only a dynamic runtime option seems to be too
strange. OTOH if we made it a real option for positioning as also requested in
comments in this issue we had to calculate the position of the formula each time
when we load the document. This will slow down the loading performance
considerably. 

We also face contradiction in the OASIS TC as this positioning will force any
ODF readers to reimplement the baseline calculation by themselves. 

So for me the "baseline positioning as attribute" solution is not possible. I
still hope we can convince the TC to accept my "strange" idea. But this is still
open.

There is a third option: don't store it at all and make baseline alignments a
pure UI interaction that has to be applied manually. Once the formula is loaded
again we could detect that it is baseline aligned (because its current position
"eventually" matches the one we would get by baseline alignment) and offer to
maintain this alignment by recalculation in case the formula is modified.

It is surely the most inelegant way but will not need any changes in the file
format and so does not need to be discussed in the TC at all. We could start
implementing this right away and see how it works. If we think we might need
file format support we still could ask for it later.

So to all people interested in this issue (and according to the votes there
should be some ;-)): please give me your feedback as a comment in this issue.
Comment 43 Matthias Basler 2007-02-23 22:55:54 UTC
Hi mba,

I think there is (at least) one good solution:

> OTOH if we made it a real option for positioning as also requested
> in comments in this issue we had to calculate the position of the
> formula each time when we load the document.

Not if you store the information twice in the file format:
- Store the information that the formula is baseline aligned
- Store the current value where it was last positioned.
The latter will allow quick positioning when the document is loaded, the former
will contain the rule for recalculation whenever recalculation becomes necessary.

> We also face contradiction in the OASIS TC as this positioning will force
> any ODF readers to reimplement the baseline calculation by themselves.

Not a good argument imho. Any word processor displaying wanting to display
documents has already to do quite a lot of calculations in oder to correctly
display a document's layout. I cannot believe adding baseline recalculation
makes that much of a difference then. Maybe this issue can be relaxed if the ODF
specification contained a proposed calculation algorithm in programming language
independent form. Converting this into C, Java, whatever should then not be a
big problem. Maybe someone could even write a small utility program that could
be used from different software. (Just thinking loud.)
... Or am I misunderstanding the concerns here?

My opinion is that any solution, whatever it may be, must always store the
information that the formula was aligned by the basemap IN THE DOCUMENT. Quick
hacks, e.g. trying to infer this information from, lets say, any static position
of the formula as suggested above will only cause us grief later - and they are
unreliable. I'd rather have document format change in order to get a CLEAN
solution than a quick hack that works in 90% of all cases only (any maybe in
OOo, but not KOffice or something like that)

> It would be bad for its reputation if only a few months after its
> birth we changed it incompatibly. 

We are not talking about "few months after its birth" any more now. Of course,
the number of incompatible file format updates must be kept to a minimum, but
how else will there be significant progress in OpenDocument if not by extending
the standard. Not that this would not impact backward compatibility, so old
documents would not become invalid. ... And you can expect people to update
their software from time to time, especially if it is Open Source software like
OOo or KOffice.

> I'm even afraid that old OOo versions will report an
> error on loading documents with a new value for "vertical-pos" (though I'm not
> sure). This would be even worse compared to MS Office problems of the past.

If so this would be bad indeed, but it would show a general problem that must be
solved both in the ODF specification and the software: Any specification
compliant software should be required to accept (or ignore) formerly unknown
elements in the file format without throwing exceptions!!! It must have a
fallback solution in case it doesn't know the value for a known attribute.

Just my 2 cents.
Comment 44 cdeval 2007-02-24 07:57:50 UTC
Hi everyone,

the ability to align formula vertically already exist :
you clic on a formula and you move it with Alt and up or down arrow.
How this position information is stored ? I don't know but export in pdf is good
and there is no problem for compatibility with OOo old version.

My opinion has not changed since my last message (27-feb-06) :
-implement base line calculation in Math module and converted in position in
writer outside the math module (as if I had changed position manually in current
version of OOo)
-no need to change file format,
-implement base line calculation in Math module
-implement recalculation of positions if for formula changes, but reserved to
module math or api,
-important for me (as developper) : implement an API to retrieve and recalculate
the base line from a formula object.

Thank's


Comment 45 lleroux 2007-02-24 20:53:19 UTC
Good evening,

I'm not aware of subtilities in OOo code or ODT specifications, but I wish
emphasis in the first hand that this pb is quite boring when editing
mathematical texts and in the other hand that cdeval proposition seems to be
interesting.

Thanks a lot for all your work !
Comment 46 jmgervais 2007-02-25 10:56:59 UTC
I agree with lleroux : cdeval's proposition sounds nice for users and
developpers, and clear.

(I don't understand all subtilities about ODT's format, so I won't discuss about
it.)

About times requiered to calculate position of formulas: don't forget it will be
better in any case than manual positionning... 

Good luck, OOo developpers, in your ODT's format discussions (& developpements
about #972) ;-) and thank you for this so important job !
Comment 47 Matthias Basler 2007-02-25 19:27:09 UTC
I agree that cdeval's solution is relatively easy to implement, but I don't
understand one thing:
If the information that a formula is baseline aligned with the surrounding text
is not stored in the file, how is the OOo Math module supposed to know after
reloading such a document that the user wanted the formula to be aligned in such
way? OOo would never know THAT it has to check and (if necessary) recalculate
the vertical alignment, as far as I understand this approach.

cdeval also wrote:
> 2) Currently, I you change text attribute (font, size, color, ...) of a
> paragraph which includes a formula, this one doesn't change because these
> parameters are independant of text. So, you get a difference between text and
> formula. I think it wouldn't be a defect if alignement wouldn't change. A
> double click on formula to open math module will recalculate the right
> position. And if there is too much formulae to recalculate position one by
> one, add-on such as dmaths or CmathOOo will do the job

This sounds like a bad hack to me. In every software professional for
professional use (and I assume OOo is such software), the user must be able to
RELY on the software to follow a decision the user has once done. If the user
tells OOo that a certain formula must be aligned correctly with the text, then
the user will simply expect OOo to maintain this state, no matter if the
document is closed/reopened, text size is changed, the formula is changed or
whatever! Any solution that requires the user to remember to update the formula
or all formulae explicitly should only be short term solution.
Comment 48 Mathias_Bauer 2007-02-28 07:50:06 UTC
Thanks for all your comments.

@matthiasbasler:

> Not if you store the information twice in the file format:
> - Store the information that the formula is baseline aligned
> - Store the current value where it was last positioned.
> The latter will allow quick positioning when the document is loaded, the former
> will contain the rule for recalculation whenever recalculation becomes
> necessary.

Fine, exactly that was my proposal! Store the position "as usual" (means: e.g.
as "relative to bottom") so that you don't need to parse and calculate the
formula to position it (e.g. by using the provided replacement image) correctly.
Additionally have a "flag" that tells the application to recalculate this
position base on baseline alignment in case the formula is changed again.
In all cases where the formula is not changed afterwards you can safely ignore
the flag completely.

What is not very popular in the TC is to create a new alignment attribute and
store only this one in the file format. I also disliked that idea for
compatibility reasons but as some people asked for it we brought it to the TC.

So as several people like you and cdeval had the same idea now or at least
agreed to it I'm confident that moving forward with it is the right choice. The
"flag" could be even declared as "application specific", means: it is not
necessary to change ODF for it. ODF allows for application specific extensions
and as this flag is not necessary to load and display the document correctly I
think it is OK to ignore it. So I will suggest it to the TC and in case it won't
be accepted make it an application specific attribute for OOo.

> If the information that a formula is baseline aligned with the surrounding text
> is not stored in the file, how is the OOo Math module supposed to know after
> reloading such a document that the user wanted the formula to be aligned in 
> such way? OOo would never know THAT it has to check and (if necessary) 
> recalculate the vertical alignment, as far as I understand this approach.

I think you misunderstood the proposal and for me it seems that we have the same
understanding. I hope that I could make this clear.
Comment 49 quetschke 2007-03-07 15:04:58 UTC
I hope I'm not beating a dead horse here, but it really is annoying to "align"
formulas in OOo texts.

MBA's proposal actually includes solutions to get it done now and to get it done
correctly. This:

> There is a third option: don't store it at all and make baseline alignments a
> pure UI interaction that has to be applied manually. Once the formula is
> loaded again we could detect that it is baseline aligned (because its current
> position "eventually" matches the one we would get by baseline alignment) and
> offer to maintain this alignment by recalculation in case the formula is
> modified.

could probably implemented immediately and would solve the problem for OOo
without creating any problems for non-OOo ODF users. (Except if you manually
align (move) a formula you loose your ability to get it aligned automatically
if you only change it's content. An UI option to baseline align a formula
could help here.)

Any solution that has to involve the OASIS ODF TC will most probably be "done
correctly" but will also most probably be only available on timescales of
OOo 3.x or so.

So, please, implement the third option now plus a new UI option to baseline
align a formula (again) and implement the solution of the OASIS ODF TC once
there is one.
Comment 50 cdeval 2007-03-14 14:26:47 UTC
matthiasbasler said :
> I agree that cdeval's solution is relatively easy to implement, but I don't
> understand one thing:
> If the information that a formula is baseline aligned with the surrounding
> text is not stored in the file, how is the OOo Math module supposed to know
> after reloading such a document that the user wanted the formula to be aligned
> in such way? OOo would never know THAT it has to check and (if necessary)
> recalculate the vertical alignment, as far as I understand this approach.

The solution is simple : I need nothing else baseline alignment. I never used a
vertical alignment for my equation ! So this alignment will replace the current
vertical alignment. And if someone needs another alignment, it's possible to
manually change vertical position with Alt-Arrow keys as now ! LaTeX (and even
Word) has this default position and I never changed it.

cdeval also wrote:
> 2) Currently, I you change text attribute (font, size, color, ...) of a
> paragraph which includes a formula, this one doesn't change because these
> parameters are independant of text. So, you get a difference between text and
> formula. I think it wouldn't be a defect if alignement wouldn't change. A
> double click on formula to open math module will recalculate the right
> position. And if there is too much formulae to recalculate position one by
> one, add-on such as dmaths or CmathOOo will do the job

matthiasbasler answered :

> This sounds like a bad hack to me. In every software professional for
> professional use (and I assume OOo is such software), the user must be able to
> RELY on the software to follow a decision the user has once done. If the user
> tells OOo that a certain formula must be aligned correctly with the text, then
> the user will simply expect OOo to maintain this state, no matter if the
> document is closed/reopened, text size is changed, the formula is changed or
> whatever! Any solution that requires the user to remember to update the
> formula or all formulae explicitly should only be short term solution.

yes it's a bad hack but it's currently like that : if I change font or size, I
must remember to edit ALL formula because OOo doesn't change them. That's why
Damths and CmathOOo have macros to do that. If you want OOo to change attributes
of formula when font, size, color, etc... change, it would be great.
But for the alignment, if the baseline becomes the default : no need to add
change, only refresh position (and size, font, ...) if document changes. It
would be a nice new feature !

Thank's.
Comment 51 eric.bachard 2007-12-20 22:55:19 UTC
added me on CC 
Comment 52 eric.bachard 2007-12-20 23:03:58 UTC
ericb@tl

Is it possible to discuss that issue on IRC  ? 

I'll propose you a rendez-vous by email.

Thanks :-)

Comment 53 troodon 2008-02-01 13:58:35 UTC
Some news on this topic (thank you Eric Bachard!):
http://ooo-education.blogspot.com/2008/02/math-baseline-alignment.html
Comment 54 eric.bachard 2008-04-18 07:40:43 UTC
Issue 88409 is the same issue, but will be treated separately: first simple cases, then more complicated 
cases, including matrix

Comment 55 etx90 2009-08-13 14:12:16 UTC
This feature is really very important for sciences and maths teachers. 
When corrected, there won't be any reasons for my colleagues not to use it.
Teachers are a key vector for spreading the use of OOo.
(sorry for my english, I'm french)
Comment 56 yannickbaud 2010-05-16 12:04:44 UTC
Je vais rester avec mes macros gdmath sous word où je n'ai pas ce problème.
Comment 57 diemsi 2010-05-16 13:14:49 UTC
What?
Comment 58 etx90 2010-05-16 18:55:35 UTC
He said "While this is not fixed, I will use M$ Word with Gdmath tools which
works fine" This not the exact translation, but I'm pretty sure that's what he
means.
Comment 59 cdeval 2010-05-16 20:39:56 UTC
Good translation.
He said that the M$ Word "equation field" used by Gdmath (or cmath) works fine
and have not this problem of alignment. This defect is prohibitive for many
science teachers. I hope it will be resolved soon because there is no possible
workaround by programming in OOoBasic.
Comment 60 becchio 2010-05-28 16:20:02 UTC
This defect is prohibitive for science teachers and student. I hope it will be 
resolved soon.
Comment 61 stbartelslg 2010-06-01 16:01:02 UTC
This bug makes it extremly difficult to encourage pupils to use OO with 
mathematical texts.
Comment 62 slavikdobro 2010-06-14 11:25:09 UTC
Nine years have already passed but nothing changes. And we still have to tune 
manually each formula in the document. For an instance, there are about 400 
various formulas in my current document and about 2/3 of them I have to align 
manually. I even tried to make this process easier by using styles, but the value 
of "From bottom" disappears after document save and load.
So now there are two better choices for us: MS Office or LaTeX.
Comment 63 eric.bachard 2010-06-14 12:06:01 UTC
Hi,

To avoid counterproductive comments, please note that there is currently a work in progress with math 
baseline alignment. For further information, see :
http://wiki.ooo4kids.org/index.php/ImproveMathEquationEditor/Baseline_AlignmentEquations

More generic : http://wiki.ooo4kids.org/index.php/ImproveMathEquationEditor

Thanks to Mathias Bauer and Thomas Lange for their help too.



Comment 64 diaz_frederic 2010-08-27 16:39:43 UTC
Issue Solved by Education Project Team, lead by Eric Bachard.
I tested it and it works perfectly in OOo4Kids1.0 even with stacked fractions
formulas containing exponents.

dmaths Team seems to have tested it too.

Code portions ready for backport in OpenOffice.org
Concerned devs just have to contact Eric Bachard on educ or dev-educ lists.

REM : Others ergonomic functionnalities have been created in OOoMath in
OOo4Kids1.0. Their codes will be soon ready for backport.
Comment 65 eric.bachard 2010-08-27 18:14:41 UTC
Thank you Fred :)

I'll add more information : most of the code fxing the issue was written by Michal Spisiak, and it will 
initialy be ported in ooo-build.  

Last but not least, an OpenOffice.org backport is in progress, of course.

@tl : I'd suggest an IRC meeting with mba in this purpose.
Comment 66 cdeval 2010-08-27 21:08:37 UTC
Many thanks to Eric's team !
I've tested the OOo4Kids pre-release and I confirm : alignment is perfect, even
for complex formulas. Great job !
I hope it will be incuded in OOo as soon as possible because this "defect" is
(was !) very penalizing for the scientists.
Comment 67 Olaf Felka 2010-09-14 14:43:15 UTC
giving  a meaningful target
Comment 68 eric.bachard 2010-10-06 21:16:45 UTC
Created attachment 71985 [details]
Patch, based on DEV300_m83, written by Michal Spiziak, to fix the Baseline alignement issue
Comment 69 eric.bachard 2010-10-06 21:18:26 UTC
@tl : please, confirm the patch applies, and work as expected.

I'm on CC, and I'll keep an eye on the issue.

Thanks :)
Comment 70 cdeval 2010-10-06 21:58:28 UTC
The request for resolution of this issue of alignment was strong in the
educational and scientific community. The long-awaited code was written by
Michal Spisiak through a Google Summer of Code and mentored by Eric Bachard and
Fridrich Strba for Novell and Go-OO OpenOffice.org Education projects
(EducOOo.org in France). 
This improvement is a big step for OOo and is already available in OOo4Kids.
Many many thanks to them !
Comment 71 michael.ruess 2010-10-07 09:26:18 UTC
Changing issue type to "Patch".
Comment 72 piotrmajdak 2010-10-12 08:24:42 UTC
It the baseline alignment also already integrated in the 3.3beta? 
(It seems like some of the workspaces of the DEV300m83 and DEV300m84 are in the
OOo 3.3 beta.)

If not, do you have an idea how can I use the patch before 3.4?

I also could simple wait for 3.4 but I have now a document with over 100
formulas which I have to submit in few days. So any help is appreciate :-)
Comment 73 piotrmajdak 2010-10-12 08:24:49 UTC
Is the baseline alignment also already integrated in the 3.3beta? 
(It seems like some of the workspaces of the DEV300m83 and DEV300m84 are in the
OOo 3.3 beta.)

If not, do you have an idea how can I use the patch before 3.4?

I also could simple wait for 3.4 but I have now a document with over 100
formulas which I have to submit in few days. So any help is appreciate :-)
Comment 74 thomas.lange 2010-10-12 08:31:09 UTC
tl->piotrmajdak: the fix will be available in OOo 3.4 once the UI is implemented
and minor changes are applied. As someone stated before: it is already available
in OOO 4 kids. Thus that would be the easiest way to make use of it meanwhile.
Comment 75 thomas.lange 2010-10-18 12:32:25 UTC
Created attachment 72090 [details]
Adding mock-up for new UI option
Comment 76 thomas.lange 2010-10-22 09:03:10 UTC
Current state: reviewing the layout specific changes in Writer with OD.
Issue expected to be fixed by next week.
Comment 77 thomas.lange 2010-10-22 11:56:04 UTC
Created attachment 72146 [details]
Updated UI screen shot as discussed with FL and OD
Comment 78 thomas.lange 2010-10-22 12:24:02 UTC
As decided by FL: The FixedLine 'Layout' is now renamed to 'Layout assistance'.
Comment 79 thomas.lange 2010-11-03 15:54:44 UTC
Fixed in CWS tlmath01.
Files changed:

M offapi\com\sun\star\formula\FormulaProperties.idl
M offapi\com\sun\star\text\DocumentSettings.idl
M offapi\com\sun\star\text\TextMarkupType.idl
M starmath\inc\node.hxx
M starmath\source\document.cxx
M starmath\source\node.cxx
M sw\inc\IDocumentSettingAccess.hxx
M sw\inc\cmdid.h
M sw\inc\doc.hxx
M sw\inc\fesh.hxx
M sw\inc\frmfmt.hxx
M sw\inc\ndole.hxx
M sw\inc\swabstdlg.hxx
M sw\source\core\doc\doc.cxx
M sw\source\core\doc\docnew.cxx
M sw\source\core\draw\dview.cxx
M sw\source\core\frmedt\fefly1.cxx
M sw\source\core\frmedt\feshview.cxx
M sw\source\core\inc\flyfrm.hxx
M sw\source\core\inc\flyfrms.hxx
M sw\source\core\inc\layfrm.hxx
M sw\source\core\layout\fly.cxx
M sw\source\core\layout\flyincnt.cxx
M sw\source\core\layout\ssfrm.cxx
M sw\source\core\objectpositioning\ascharanchoredobjectposition.cxx
M sw\source\core\ole\ndole.cxx
M sw\source\ui\app\appopt.cxx
M sw\source\ui\app\docshini.cxx
M sw\source\ui\config\cfgitems.cxx
M sw\source\ui\config\makefile.mk
M sw\source\ui\config\optdlg.hrc
M sw\source\ui\config\optdlg.src
M sw\source\ui\config\optpage.cxx
M sw\source\ui\config\usrpref.cxx
M sw\source\ui\dialog\swdlgfact.hxx
M sw\source\ui\frmdlg\frmdlg.cxx
M sw\source\ui\frmdlg\frmpage.cxx
M sw\source\ui\inc\frmdlg.hxx
M sw\source\ui\inc\frmpage.hxx
M sw\source\ui\inc\optpage.hxx
M sw\source\ui\shells\frmsh.cxx
M sw\source\ui\uiview\swcli.cxx
M sw\source\ui\uno\SwXDocumentSettings.cxx
M sw\source\ui\wrtsh\wrtsh1.cxx
Comment 80 thomas.lange 2010-11-08 13:52:48 UTC
.
Comment 81 michael.ruess 2010-11-16 11:50:44 UTC
Verified in CWS tlmath01.
Comment 82 thomas.lange 2010-11-16 13:02:49 UTC
The CWS just got integrated, thus the feature should become available in the
next dev build meaning in DEV300_m94.
Comment 83 michael.ruess 2010-12-10 09:03:02 UTC
Checked integration in DEV0m95.
Comment 84 promurilo.math 2011-03-13 18:59:59 UTC
Created attachment 76093 [details]
Test formula inserted in Writer.

The attached file is a PNG image, showing a screenshot of a Writer document with a formula of Math. The left and right side of the formula, there are characters of text. Note that the formula is a little below the base of the characters. To better visualize the vertical alignment, I removed the horizontal spacing of the formula internally and externally.
Comment 85 promurilo.math 2011-03-13 19:12:12 UTC
Hello

This correction represents an important step towards the integration of Math and Writer. However, there is a need for an adjustment.

Using the test version of OpenOffice (DEV300m101) for Linux (Debian package 64-bit) and Windows, I noted that the alignment is perfect, but only when the formula is in edit mode. When we left the edit mode, the formula undergoes a vertical offset of approximately 1 mm relative to the base line.

I added a picture to illustrate the problem. It occurs on both Windows and Linux. The gap is very small, it is true, but you must make the adjustment, because in a document with many formulas inline, this difference is very visible.
Comment 86 michael.ruess 2011-03-14 08:07:46 UTC
mru->mneto: I would suggest, that you file a new issue regarding this problem. Re-opening issues for fine tuning or additional fixes is not good on issues already having such a long history and description. Thanks a lot!