Hi Konstantinos,
Konstantinos Poulios wrote: > 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. We should not make use of solution 1) and 3). The 1) problem with one is that user will make use of it to work around other existing bugs, namely the missing kerning when subscripts are used. If we were to allow for 1) and then later on fix the kerning issue as well then the combined effect will be bad. 3) is also not a good solution since it requires to change the parser behavior for white spaces for just a single token combination. And no parser for whatever human readable text (e.g. html, xml, TeX, ...) does something like that. Therefore such unexpected kind of behavior should not be made into a feature. This leaves us with 2). Basically there are two possible choices for a syntax to choose from for implementation - int xy + b nospace { d x } - int xy + b d nospace x the first working like brackets the latter like a binary operator. I'm fine with either one but I think we should not implement both of them. The somewhat easier one to implement will be the last one. Regards, Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@sw.openoffice.org For additional commands, e-mail: dev-h...@sw.openoffice.org
