Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | sub/sup: do not force operators as non-objects | ||
---|---|---|---|
Product: | Math | Reporter: | macias <bluedzins> |
Component: | code | Assignee: | AOO issues mailing list <issues> |
Status: | REOPENED --- | QA Contact: | |
Severity: | Trivial | ||
Priority: | P3 | CC: | don.troodon, eric.bachard, issues |
Version: | OOo 2.3.1 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
macias
2008-03-22 16:21:30 UTC
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. |