Apache OpenOffice (AOO) Bugzilla – Issue 972
Alignment of baselines of formula and text in writer
Last modified: 2011-03-14 08:07:46 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.
Reassigned to Falko.
Will get back to this issue later. Thx. for submittance.
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).
changing QA contact from bugs@ to issues@
TL->FT, QA: This corresponds to bug #90053
.
*** Issue 6868 has been marked as a duplicate of this issue. ***
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.
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 ***
Ooops.... The other one was already closed. Reopened...
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.
Yes, OOo2.0 is the right target.
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.
FME->TL: Is the GetBaseline() method already implemented in math?
Effort added.
As discussed with MRU retargeted to OOo later because of other issues at hand.
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.
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.
This problem is one of the two problems which prevent mathematic teachers to use OpenOffice.
keywords... Usability because you have to align the formula manually and this is a tedious job...
For the moment, is the position of the baseline of a formula (for example '56% from bottom') readable with a OOoBasic macro?
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.
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
"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. ^_~
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 ?
Issue Target Milestone should be marked as 00 2.0
*** Issue 53674 has been marked as a duplicate of this issue. ***
*** Issue 39264 has been marked as a duplicate of this issue. ***
. 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 !
*** Issue 56261 has been marked as a duplicate of this issue. ***
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.
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
Created attachment 34214 [details] exemple of vertical alignment problem
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.
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.
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).
" 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
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.
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.
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
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 !
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 !
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.
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.
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.
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.
added me on CC
ericb@tl Is it possible to discuss that issue on IRC ? I'll propose you a rendez-vous by email. Thanks :-)
Some news on this topic (thank you Eric Bachard!): http://ooo-education.blogspot.com/2008/02/math-baseline-alignment.html
Issue 88409 is the same issue, but will be treated separately: first simple cases, then more complicated cases, including matrix
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)
Je vais rester avec mes macros gdmath sous word où je n'ai pas ce problème.
What?
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.
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.
This defect is prohibitive for science teachers and student. I hope it will be resolved soon.
This bug makes it extremly difficult to encourage pupils to use OO with mathematical texts.
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.
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.
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.
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.
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.
giving a meaningful target
Created attachment 71985 [details] Patch, based on DEV300_m83, written by Michal Spiziak, to fix the Baseline alignement issue
@tl : please, confirm the patch applies, and work as expected. I'm on CC, and I'll keep an eye on the issue. Thanks :)
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 !
Changing issue type to "Patch".
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 :-)
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 :-)
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.
Created attachment 72090 [details] Adding mock-up for new UI option
Current state: reviewing the layout specific changes in Writer with OD. Issue expected to be fixed by next week.
Created attachment 72146 [details] Updated UI screen shot as discussed with FL and OD
As decided by FL: The FixedLine 'Layout' is now renamed to 'Layout assistance'.
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
Verified in CWS tlmath01.
The CWS just got integrated, thus the feature should become available in the next dev build meaning in DEV300_m94.
Checked integration in DEV0m95.
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.
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.
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!