Hi,
I am currently working on a fix for spacing issues, like for example:
http://www.openoffice.org/issues/show_bug.cgi?id=56746
My motivation is that I haven't found a way to write dX, where only X is bold.
The expression:
"d bold X"
will leave an extra unwanted space between d and X. There are many
similar cases where the user has no choice but live with the extra
space in his variables.
Before I invest more time to this I would like some comments on my
ideas for fixing this issue:
1. The first concept is to add a negative space symbol like the
symbols "`" and "~" for small and normal space. For example the symbol
"´" could define a blank node which would correspond to a negative
small space.
2. The second concept is to implement a "nospace operator" which would
simply eliminate all spaces in the expression contained in its {}. For
example:
nospace {a b}
would eliminate the extra spaces added on drawing the SmExpressionNode
containing a and b.
3. The third one is to change the behavior of Math so that it would
differentiate between the expression a{b} and the expression a {b}, so
that:
a{b} -> ab
while
a{b} -> a b
which means that no space will be preceded before an expression inside
a TLGROUP, if there is no space before this TLGROUP, in the parsed
text.
Pros/Contras
----------------------
- Method 1, Contras:
1: Handling of negative space in SmBlankNode::Arrange cannot be
implemented the same way as the existing (positive) spaces
2: The user will have to manually tweak his expression by adding
extra negative spaces, until he reaches the desired result.
3: The symbol "´" could possibly be contained in some existing
formulas. After the implementation of this method, it will have to be
escaped. Any proposals for another symbol?
+ Method 1, Pros:
1. There is practically no restriction on the amount of negative
spaces added by the user, thus he can even overlap two expressions. If
it really works, I considered this as an advantage.
- Method 2, Contras:
1: The construction "identifier { expression }", where the
identifier does not represent an SmNode itself but just acts on the
expression contained in {} is a new syntax. As far as I have
understood, none of the existing operators works this way.
2: There is no possibility of fine-tunning of the horizontal
position of the following node.
+ Method 2, Pros:
1: Quite easy to use in a variety of cases where the user just wants
turn of the extra spaces added on drawing of an expression.
2: I have almost implemented this method. (It works but I have
problems with parsing it correctly).
- Method 3, Contras:
1. Takes whitespace in the parsed text into account, while currently
whitespace is ignored (AFAIK).
2. It is probably that the template a{b} exists already in many
formulas created with the previous versions of OOo Math. This formulas
will be affected if this method is implemented.
+ Method 3, Pros:
1: No need for new symbols or identifiers
I consider the lack of flexibility in horizontal spacing in OOo Math
as a very important drawback for the adoption of OOo in educational
institutes, that's why I am willing to invest as time as needed to
improve it. I hope for some constructive feedback, suggestions and
hints.
Thanks in advance
Kostas
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
