Difference between revisions of "Education Project/Effort/Math baseline alignment/Mails"

Revision as of 08:48, 6 December 2008

Hello Thomas,

I had been debugging starmath module. Using some test cases and checking the flow.

There are some very basic doubts:

1. In my view centre(0,0) of co-ordinate system from which all calculations are made (e.g calculation of Point, Alignment etc) is at top left corner. The +ve side of Y axis goes down the left corner towards bottom and +ve side of X axis goes horizontal towards top right corned. May you confirm this ?

2. Now as per discussion which has happened so far, every Node needs to have baseline calculated. To start with, I think I am ready to write code for simple cases like "over". My strategy for over is recursive calculation of baseline. After moving numerator to top and denominator to bottom we will find the average of both and assign this to baseline of whole fraction and all this will go on recursively automatically. Does it sound good ?

something like(just a pseudo code ) :

     if (pNum->HasBaseline() && pDenom->HasBaseline())
     {
              SetHasBaseline(TRUE);
              SetBaseline((pNum->GetBaseline() + pDenom->GetBaseline()) / 2L);
      }

That needs fraction to be a node. And is it really a node ? I think yes.

These calculations are in SmBinVerNode::Arrange method.

3. There are many messages and comments in French, and I would like to start converting important ones as and when they come into English. Would that be fine ? And can I do it in same CWS ?

4. Should I reassign issue to myself and create a CWS? It hasn't been created yet.

5. Can baseline be negative ? I don't think so, but there are test cases where baseline has value -<number>

Thanks

-- Cheers, rakesh

Hello Rakesh,

> Hello Thomas,
>
> I had been debugging starmath module. Using some test cases and
> checking the flow.
>
> There are some very basic doubts:
>
> 1. In my view centre(0,0) of co-ordinate system from which all
> calculations are made (e.g calculation of Point, Alignment etc) is at
> top left corner. The +ve side of Y axis goes down the left corner
> towards bottom and +ve side of X axis goes horizontal towards top
> right corned. May you confirm this ?
>

Yes. That is not what one might expect, but for all window based coordinates in most UI API's it is the same.

> 2. Now as per discussion which has happened so far, every Node needs
> to have baseline calculated. To start with, I think I am ready to
> write code for simple cases like "over". My strategy for over is
> recursive calculation of baseline. After moving numerator to top and
> denominator to bottom we will find the average of both and assign this
> to baseline of whole fraction and all this will go on recursively
> automatically. Does it sound good ?
>
> something like(just a pseudo code ) : > > if (pNum->HasBaseline() && pDenom->HasBaseline()) > { > SetHasBaseline(TRUE); > SetBaseline((pNum->GetBaseline() + > pDenom->GetBaseline()) / 2L); > } > > That needs fraction to be a node. And is it really a node ? I think yes.
>
> These calculations are in SmBinVerNode::Arrange method.
>

The basic idea is not quite right. If formulas are layouted it is not
about finding the overall height and setting the mid as baseline.
Layout of fractions should be done in away that the horizontal line is
exactly on the same y position as a "-" in "a-b" would be if there were
further formula parts.

See for example: a - {a over b} over {y+z} or a - {H^{2^3}} over {H+H}
And compare with any book about physics or math.

> 3. There are many messages and comments in French, and I would like to
> start converting important ones as and when they come into English.
> Would that be fine ? And can I do it in same CWS ?
>

Err... Where are messages and comments in French?
And do you want to put them into a CWS once you have them translated
into English?

> 4. Should I reassign issue to myself and create a CWS? It hasn't been
> created yet.
>

If you feel like it you can do so. That would be a good idea if you want to share the code with otehrs e.g. Eric or me while developing. If you want that just drop me a note and I will setup a CWS. That is because in the end our QA will have a look at it and it is easier to get a build done/installed from here if the CWS is on our servers...

> 5. Can baseline be negative ? I don't think so, but there are test
> cases where baseline has value -<number>
>

Yes it can become negative. The actual baseline of the very outer line (or to put it different: of the first char in a line) should not be negative. But it wouldn't matter.

The reason for baselines to become negative is because of aligning different nodes vertically. If you take the following two formulas for example

  x - x

and

  stack{a#b#c#d#e#f#g}

each on it's own none of the baselines should be negative. But if they are on the same line like

  x - x stack{a#b#c#d#e#f#g}

things may become different. The reason for this is that the alignment of the whole formula starts with the aligned node. And here that is 'x'. If, just for the example, we assume a lines height will be 100 then the rectangle for 'a' might be at pos 0,0 with size 60x100. And the stack if placed at (0,0) would have a size of about 160x700. If the latter one is to be vertically aligned to the first it is done by moving it up until in order for the baseline of the stack{...} command to match the one from "x-y". By doing that we surely will have the baselines of a, b and c be moved into the negative y axis as can be seen in the layouted formula.

But that doesn't really matter when the formula is displayed since it will work with any logically position calculated. At most one needs to move all the formula nodes in order to have the whole formula start at pos (0,0) if needs be...

Thomas

2008/9/29 Thomas Lange - Sun Germany - ham02 - Hamburg <Thomas.Lange@sun.com>:
[..]
- Show quoted text -
>> There are some very basic doubts:
>>
>> 1. In my view centre(0,0) of co-ordinate system from which all
>> calculations are made (e.g calculation of Point, Alignment etc) is at
>> top left corner. The +ve side of Y axis goes down the left corner
>> towards bottom and +ve side of X axis goes horizontal towards top
>> right corned. May you confirm this ?
>>
> Yes. That is not what one might expect, but for all window based
> coordinates in most UI API's it is the same.
>
>> 2. Now as per discussion which has happened so far, every Node needs
>> to have baseline calculated. To start with, I think I am ready to
>> write code for simple cases like "over". My strategy for over is
>> recursive calculation of baseline. After moving numerator to top and
>> denominator to bottom we will find the average of both and assign this
>> to baseline of whole fraction and all this will go on recursively
>> automatically. Does it sound good ?
>>
>> something like(just a pseudo code ) :
>>
>> if (pNum->HasBaseline() && pDenom->HasBaseline())
>> {
>> SetHasBaseline(TRUE);
>> SetBaseline((pNum->GetBaseline() +
>> pDenom->GetBaseline()) / 2L);
>> }
>>
>> That needs fraction to be a node. And is it really a node ? I think yes.
>>
>> These calculations are in SmBinVerNode::Arrange method.
>>
>
> The basic idea is not quite right. If formulas are layouted it is not
> about finding the overall height and setting the mid as baseline.
> Layout of fractions should be done in away that the horizontal line is
> exactly on the same y position as a "-" in "a-b" would be if there were
> further formula parts.
>
> See for example: a - {a over b} over {y+z} or a - {H^{2^3}} over {H+H}
> And compare with any book about physics or math.
>

So, for simple cases like "<X> over <Y>" baseline would simply be baseline of "over", if I am getting it right.

>> 3. There are many messages and comments in French, and I would like to
>> start converting important ones as and when they come into English.
>> Would that be fine ? And can I do it in same CWS ?
>>
> Err... Where are messages and comments in French?
> And do you want to put them into a CWS once you have them translated
> into English?
>

Actually they where German and few where in French (I am not sure though, don't know either of them :( . I plan to start a page in wiki and make a table with two columns. First one will contain messages in non-English and other side will contain translated messges. For critical comments related to this issue I will like to commit them in this CWS.

>> 4. Should I reassign issue to myself and create a CWS? It hasn't been >> created yet.
>>
> If you feel like it you can do so.
> That would be a good idea if you want to share the code with otehrs e.g.
> Eric or me while developing.
> If you want that just drop me a note and I will setup a CWS. That is
> because in the end our QA will have a look at it and it is easier to get
> a build done/installed from here if the CWS is on our servers...
>

Okay. I will do it, thanks - Show quoted text -

>> 5. Can baseline be negative ? I don't think so, but there are test
>> cases where baseline has value -<number>
>>
> Yes it can become negative.
> The actual baseline of the very outer line (or to put it different: of
> the first char in a line) should not be negative. But it wouldn't matter.
>
> The reason for baselines to become negative is because of aligning
> different nodes vertically. If you take the following two formulas for
> example
> x - x
> and
> stack{a#b#c#d#e#f#g}
> each on it's own none of the baselines should be negative.
> But if they are on the same line like
> x - x stack{a#b#c#d#e#f#g}
> things may become different.
> The reason for this is that the alignment of the whole formula starts
> with the aligned node. And here that is 'x'. If, just for the example,
> we assume a lines height will be 100 then the rectangle for 'a' might be
> at pos 0,0 with size 60x100.
> And the stack if placed at (0,0) would have a size of about 160x700.
> If the latter one is to be vertically aligned to the first it is done by
> moving it up until in order for the baseline of the stack{...} command
> to match the one from "x-y". By doing that we surely will have the
> baselines of a, b and c be moved into the negative y axis as can be seen
> in the layouted formula.
>
> But that doesn't really matter when the formula is displayed since it
> will work with any logically position calculated.
> At most one needs to move all the formula nodes in order to have the
> whole formula start at pos (0,0) if needs be...
>
[..]

Thanks Thomas for your very important notes. For archiving reasons (& in case other folks around can help with ideas) I have taken whole of reply into this mail and have cc to dev@openoffice and dev@education

Cheers!

-- rakesh

Hello Rakesh,

... > >> 2. Now as per discussion which has happened so far, every Node needs
> >> to have baseline calculated. To start with, I think I am ready to
> >> write code for simple cases like "over". My strategy for over is
> >> recursive calculation of baseline. After moving numerator to top and
> >> denominator to bottom we will find the average of both and assign this
> >> to baseline of whole fraction and all this will go on recursively
> >> automatically. Does it sound good ?
> >>
> >> something like(just a pseudo code ) :
> >>
> >> if (pNum->HasBaseline() && pDenom->HasBaseline())
> >> {
> >> SetHasBaseline(TRUE);
> >> SetBaseline((pNum->GetBaseline() +
> >> pDenom->GetBaseline()) / 2L);
> >> }
> >>
> >> That needs fraction to be a node. And is it really a node ? I think yes.
> >>
> >> These calculations are in SmBinVerNode::Arrange method.
> >>
> >
> > The basic idea is not quite right. If formulas are layouted it is not
> > about finding the overall height and setting the mid as baseline.
> > Layout of fractions should be done in away that the horizontal line is
> > exactly on the same y position as a "-" in "a-b" would be if there were
> > further formula parts.
> >
> > See for example: a - {a over b} over {y+z} or a - {H^{2^3}} over {H+H}
> > And compare with any book about physics or math.
> >
>
> So, for simple cases like "<X> over <Y>" baseline would simply be
> baseline of "over", if I am getting it right.
>
That's not correct either. If the overline would have been drawn by using the character that might have been right (exact result depending on the font used, maybe). But in Math the underscore is drawn as rectangle and thus is no character from any font. That means you have to 'invent' a calculation for a pseudo baseline of that SmRect that fits the requirement of aligning with the '-' character.

On the other hand you are free to re-implement that Node by making use of the '-' character. You will need to call a separate function though to stretch it to the desired width. And the layout may change somewhat because of this. However that will bring up other issue you need to take care of. For example - Even if you stretch the '-' to the required width you need to make sure that

the bounding rectangle does not include excessively large borders to

the left

and right.

- Also you need to clip the bounding rectangle at top and bottom to about the

actual space the '-' will take because you must not have too much space
between it and the nominator and denominator.

- The advantage however would be that of course the baseline of '-' is always

in line with another '-' as in "a - {x over y}". That is in that case the
baseline of the '-' should be the baseline of that node.

Note: if you want to go with the stretched '-' make sure to use the one from the StarSymbol font. Not all fonts are arbitrarily scalable.

> >> 3. There are many messages and comments in French, and I would like to
> >> start converting important ones as and when they come into English.
> >> Would that be fine ? And can I do it in same CWS ?
> >>
> > Err... Where are messages and comments in French?
> > And do you want to put them into a CWS once you have them translated
> > into English?
> >
>
> Actually they where German and few where in French (I am not sure
> though, don't know either of them :( . I plan to start a page in wiki
> and make a table with two columns. First one will contain messages in
> non-English and other side will contain translated messges. For
> critical comments related to this issue I will like to commit them in
> this CWS.
>
Sure. Do it that way. Critical comment should best be in the source as well.

> Thanks Thomas for your very important notes. For archiving reasons (&
> in case other folks around can help with ideas) I have taken whole of
> reply into this mail and have cc to dev@openoffice and dev@education
>
>
That's fine with me. :-) Thanks for taking on that issue!

Thomas