Apache OpenOffice (AOO) Bugzilla – Issue 87337
sub/sup: do not force operators as non-objects
Last modified: 2013-08-07 14:54:45 UTC
This for example will not work: sub 0 despite it makes sense. And I need to use it all the time in expressions like this one: P(AB mline sub 0) (again it does not work). Workaround -- insert empty object: P(AB mline "" sub 0) but it would be really useful to simply write what you mean. In latex you just type: P(AB|_2) and that's it -- no fake objects to make parser happy. Bottom line -- if user needs to use sup/sub tags, just let him/her do it, do not check if there is an reference object for it.
Confirming with 2.4. I think the easier fix for this is to consider mline as a valid reference object. Please note that expressions like a divides^c_d b a nsupset^c_d b a equiv^c_d b a parallel^c_d b a divides^c_d b are allowed and so should be a mline^c_d b.
CC for me
MRU->TL: could be a useful change for the future. I think it should be allowed to use the "sub x" expression anywhere the user wants. There are some more situations than just using as index.
The problem with this is that the parser needs to decide where the subscript is placed on way or the other. The two choice that immediately come two mind are left ( a over b _ 2 right ) newline left ( a over b "" _ 2 right ) newline And it becomes worse if the same idea is applied to left subscripts as (and it should be for sake of common overall behavior) left ( a over b _ lsub right ) newline left ( a over b "" _ lsub right ) newline There is no way a mere parser can decide what the users intend was when writing it. Also such a change will be incompatible with existing documents that might have such constructs in use. You can't just have the formula left ( a over b right ) _2 newline look differently from one version to another. Currently the "2" is rendered at the bottom of the right brace where according to your proposal it should be rendered like left ( a over b right ) {}_2 newline Thus there would be import and export filter required as well. Maybe(!) it is possible to introduce some special rules to handle the case better but a simple rule with no exception is usually preferable to more more complex rules that have exception. Overall: No, this is not going to be changed. Especially not since there is a good concept that makes it clear to the parser and reader(!) which way the user wants the formula to be rendered. It is the very same construct that can also be used in TeX. And that is already almost what you did. The expected way to do this is using empty groups. E.g: P(AB |{}_0)
> It is the very same construct that can also be used in TeX. Ooo: P(AB mline {} _0) Latex: P(AB|_0) The problem is -- you can make OOo as the latex competitor, or you can make every piece a bit more complex than latex (for reason unknown), but then latex will easily beat OOo. In this case it "just" 7 keystrokes less in favor of latex. And think about people with RSI or handicapped, for them it is not "just" 7 keystrokes, less or more. And this is just _one_ _simply_ equation. Latex parser can decide what object is on the left, so I guess it is technically possible. I am reopening this issue for reconsideration -- it is all if you want good theory of parsing, or great Ooo. I rephrase the wish maybe a bit -- do not insist that operators are not objects (case of sub and sup).
PS. Sorry, missed the counting -- it is _8_ keystrokes difference. And the equation in latex takes 11 keystrokes (on my layout 9). So Ooo makes almost the double of it.