Education Project/Effort/Math baseline alignment/1stMeeting log

Log :

[10:22] * Now talking on #ooo-math

[10:22] <ericb2> hello :)

[10:23] <tl13> Hi!

[10:24] <tl13> I'm going to check where Mathias is right now. ^_-

[10:24] <tl13> He is in his office and will join in a few minutes.

[10:24] <ericb2> ok

[10:25] * ericb2 was drinking some coffee

[10:25] <tl13> I hoped Frank (FME) would have also some time but he is busy with different matters.

[10:25] <ericb2> no problem

[10:26] <ericb2> I'm rewriting the questions I had ( my battery was empty, and the file was not saved :-/ )

[10:26] * mba (n=chatzill@nat/sun/x-430a0959c5d4bec1) has joined #ooo-math

[10:26] * tl13 gives channel operator status to ericb2 mba

[10:29] <ericb2> hello mba :)

[10:29] <mba> hi eric!

[10:29] <ericb2> thanks to all for joining

[10:29] <ericb2> from my side I have read carefully all the comments on issue 972

[10:29] <ericb2> and things are not clear, thus I'll ask you some simple questions, to progress

[10:30] <ericb2> is it ok ?

[10:30] <mba> Please go on.

[10:30] <ericb2> ok

[10:31] <ericb2> I'm talking about equations anchored as characters, and only in this case

[10:31] <ericb2> am I right ?

[10:31] <ericb2> First question : when everything is correctly aligned, does something go wrong when saving /closing and reopening the document ?

[10:31] <ericb2> Second question: are there differences when you open the same document in both 1.x or 2.x OpenOffice.org version ?

[10:32] <mba> Question zero ;-) : IIRC equations anchored *to* characters could be treated the same way

[10:32] <ericb2> mba: ok :)

[10:32] <ericb2> sorry

[10:33] <mba> First question: if implemented correctly of course nothing should go wrong. ;-)

[10:34] <mba> Second question: the compatibility issue is what caused me to propose something that does not influence the file representation

[10:35] <ericb2> mba: thus thre is one compatibility issue

[10:35] <mba> My proposal to always store positions "from top" (or was it bottom?) but mark this position to become realigned at runtime if necessary will guarantee that the document will at least look the same if loaded in OOo1.x

[10:36] <mba> OOo1.x will just ignore the additional flag and of course can't realign the equation. But it will show the document as it looked in OOo3

[10:36] <ericb2> mba: ok

[10:36] <ericb2> mba: my idea was a bit different, but I can be completely wrong

[10:37] <ericb2> my idea was : align correctly the equation the first time it has been written

[10:38] <ericb2> Here, first time means either after the initial equation writing, or after every modification

[10:38] <ericb2> like some additional treatment done at the end, when quitting the editor

[10:40] <mba> So far I can't see where your idea is different to mine.

[10:40] <ericb2> good :)

[10:41] <ericb2> then, maybe you can expose everything you have in mind

[10:41] <ericb2> your vision is certainly more complete

[10:42] <mba> Basically you have described it. What we also have to decide is how we can tell OOo that a particular formula should be "base line aligned". There are three options: do it always, have a flag per document or have a flag per formula.

[10:42] <mba> Only the latter option would force us to play tricks wrt. file format (means: have a new "alien" attribute).

[10:43] <mba> For the second option we could introduce a new document option.

[10:43] <ericb2> in the GUI ?

[10:43] <mba> The first one of course is trivial. :-)

[10:43] <ericb2> e.g. in Tools -Options ?

[10:43] <tl13> I think we should do this by default for formulas anchored 'as/to' character. Or at most on a per document case.

[10:44] <mba> Depends on the decision. Document option should be in Tools-Option, if we want to do it per formula of course we need something in the positioning dialog.

[10:44] <ericb2> what is the "cost" in runtime ? ( in terms of proc load )

[10:44] <ericb2> mba: indeed, the positioning dialog is the best place

[10:45] <mba> I don't expect runtime problems - recalculations will be needed only if the formula or the font of the text document is changed.

[10:46] <mba> tl13: what's your take wrt. options? Should we have a global option, a document option of a per-formula option?

[10:46] <ericb2> excuse me, phone call

[10:47] <tl13> I think per formula is flexible but not really needed basically as user I just want them to be properly aligned. Thus if optional at all I'd prefer the document wide option.

[10:48] <tl13> If we still want to provide manual alignment we could maybe just implement the feature for 'as character' and not 'to character'.

[10:48] <tl13> Don't know if this is a bad idea though...

[10:48] <tl13> Note: We may also need a macro or sth other means to forcibly align all formulas in a document even without editing them (e.g. when the document was written in an older version of OOo)

[10:51] <mba> Good point. It should be enough to activate all formula objects, set them to "modified" and deactivate them. That should trigger the recalculation automatically.

[10:53] * ericb2 back

[10:53] * ericb2 reads up

[10:54] <ericb2> if I read correctly, a macro could be the solution ?

[10:55] <mba> No, the macro was meant as a tool to bring the new feature to old documents

[10:56] <ericb2> ok, but the idea is align formulas without edit them, right ?

[10:56] <mba> yes

[10:56] <tl13> I just checked with User-Ex (FME) and asked if the alignment should be optional and if so should it be per document or per object.

[10:56] <tl13> He clearly likes it to work on a per object base!

[10:57] <tl13> His argument was that later on we may use that setting for other (yet to come) objects as well.

[10:57] <mba> But for new documents you won't need the macro because OOo will automatically align.

[10:57] <mba> tl13: I think you meant FL?!

[10:57] <tl13> err yes!

[10:59] <mba> The per-formula option is fine for me - we just have to add this as an alien attribute to the object. That's not nice but doable. Later we could also use meta data. If we are lucky, "later" is in time for OOo3.0

[11:00] <ericb2> mba: are we going to use the third case you proposed ?

[11:00] <mba> Yes, seems so.

[11:01] <ericb2> ok, then thre is no problem for me

[11:01] <mba> We don't change anything in the way the position of the formula is stored in ODF but we add a flag to it that an application editing the document should maintain base line alignment in case the formula (or the base line of the font of the text embedding the formula) is changed.

[11:02] <mba> If we all agree to that we can move on to planning

[11:02] <ericb2> +1 for me

[11:03] <tl13> +1

[11:03] <ericb2> first thought ... what is the 3.0 deadline  ?

[11:04] <ericb2> http://wiki.services.openoffice.org/wiki/OOoRelease30

[11:04] <ericb2> looking at feature freeze, we have March 6th

[11:05] <ericb2> + specs will have to be written

[11:05] <mba> Yes, that's the current state. It is possible to ask for exceptions, I assume. So let's first try to find out what we think is realistic.

[11:06] <ericb2> if not possible we can just try, and integrate asap. No problem for me if this is 3.1 , eg.

[11:07] <tl13> Well, that sounds more reasonable then. Thus there will be no need to hurry and we have time to let users check it out.

[11:08] <ericb2> tl13: yes, hurry is imho not good: the issue is good, and needs a real fix

[11:08] <ericb2> s/issue is good/issue is old/

[11:08] <tl13> Yes. One of the oldest I know of.

[11:10] <tl13> So where would be a good point to start?

[11:10] <mba> In general I don't have a problem with "start at anytime and integrate when it's done". But in our case it's possible that we won't have a code line for integration between March/April and short before the release, means: for several months. This will force us to keep the CWS open and resync it even if development is done. No show stopper for me, but I wanted to mention it.

[11:10] <ericb2> mba: good remark: cws resync is often painfull

[11:11] <ericb2> mba: well, can we propose a roadmap, and see what we all can do ?

[11:11] <mba> I see the following areas to work on:

[11:11] <mba> Implement base line calculation in Math

[11:12] <mba> Define and implement API to access the base line

[11:12] <mba> "invent" a new alignment in Writer code

[11:12] <mba> implement this alignment in the object positioning code of Writer

[11:12] <tl13> But if we start with implementing the baseline calculation in Math where it is not yet done and only change the function in Writer to arrange the formula the resync troiuble should be very limited.

[11:13] <tl13> Do we need a new API? Will a new property not be sufficient?

[11:13] <mba> implement loading and storing of the new flag

[11:13] <mba> tl13: a property also in an API :-)

[11:13] <tl13> Err sure... But only doumentation. ^^

[11:13] <mba> Starting in Math would be fine, IMHO

[11:13] <tl13> No real API change and rebuild necesary.

[11:14] <mba> It is a well-separated code area, not too complex and the code is rarely changed.

[11:14] <tl13> Sounds reasonable. And the next change woiuld probably be the function that formats the line.

[11:14] <mba> I think a skilled developer should be able to get into that in a reasonable time frame

[11:14] <tl13> Thus we can have things working early though not yet optional.

[11:15] <ericb2> do you have some keywords, or places or class/ methods in mind ?

[11:15] <tl13> SmNode and it's derived classes. Also SmModule for the new property.

[11:16] <ericb2> tl13: ok

[11:16] <tl13> And the base class to SmNode which is SmRect

[11:16] <mba> ericb2: now the interesting part - do you know someone we can charge with implementing the base line alignment in math?

[11:16] <mba> We can talk about the other stuff later.

[11:17] <mba> s/alignment/calculation

[11:17] <ericb2> mba: currently not. But I can start to read the code, and describe/ ask questions. My problem is not code understanding, my problem is I'm not a designer, and I fear to not be efficient

[11:18] <ericb2> mba: e.g. with some information, like do this or that, that way, will help a lot. This is ocean of code

[11:18] <tl13> New classes should not really be necessary thus design changes are unlikely.

[11:18] <ericb2> ok

[11:19] <ericb2> then, just implement some static functions, could fit ?

[11:20] <tl13> Well... likely not static as well since the result depends upon the actual class object (the node and it's subnode).

[11:21] <tl13> Thus it will be a member function or more likely just changing existing member functions.

[11:21] <tl13> Should be the 'Arrange' function of the nodes.

[11:21] <ericb2> understood

[11:21] <tl13> That function does all alignment calculations right now.

[11:22] <ericb2> ok, then the first first thing is to understand how works this part

[11:22] <tl13> Also there should only be a limited number of nodes to look at. Just check by debugging which ones have not yet already calculated the baseline.

[11:23] <tl13> At the very least I would expect "over" "stack" and "matrix" implementations to need changes.

[11:23] <ericb2> tl13: indeed. But let's start little

[11:23] <tl13> A list of all available constructs (commands) can be found in parse.hxx/cxx

[11:24] <tl13> Then I suggest to start with "over" as the sample case.

[11:24] <tl13> This should be the simplest of all missing cases.

[11:24] <ericb2> tl13: thanks a lot, this is extremely informative, and I'll learn the code you mentionned, as starting point

[11:25] <ericb2> I'll have to stop. Can we summarize ?

[11:25] <tl13> look for the token T_OVER in the code to find the respective node.

[11:25] <tl13> Ok

[11:25] <ericb2> tl13: thanks !

[11:26] <ericb2> I'll put the log of the meeting on the wiki. Does it make problem ?

[11:27] <tl13> Fine with me.

[11:28] <ericb2> it is ok to meet us next week, and make a point ? Say, same day, same hour, same channel ?

[11:28] <ericb2> s/it is/is it/

[11:29] <ericb2> I cannot promise, but if I can write something, this is not a problem for me to trace, and show what happens

[11:29] <ericb2> (using gdb )

[11:29] <mba> Not same day, as we will be on a business trip next friday

[11:30] <ericb2> mba: ok. do you have another one in mind or ... ?

[11:31] <tl13> BTW: If you just have questions about Math you can drop me a note anytime. And we cab talk either per mail or via IRC.

[11:32] <ericb2> tl13: good idea. Let's go that way

[11:32] <ericb2> and I'll use the issue 972 + the wiki for traces in the issue resolution

[11:32] <ericb2> sorry, I really must go.

[11:32] <tl13> Then we'll continue without a specific 'next meeting' date?

[11:32] <tl13> No problem!

[11:32] <ericb2> thanks a lot to both for your time, I konw how it is precious !

[11:33] <mba> Yes, I think that I won't be needed anyway as I don't know a lot about math. So please continue with Thomas until you feel that we should meet again

[11:33] <tl13> Ok. FIne.

[11:33] <ericb2> ok, fine for me too

[11:33] <ericb2> bye and thanks again :-)

[11:33] <tl13> bye!

[11:34] <mba> bye

[11:34] * mba has quit ("ChatZilla 0.9.80 [Firefox 2.0.0.11/2007112718]")

[11:35] <tl13> Ok. I#m leaving. Bye!

[11:35] * tl13 (n=chatzill@nat/sun/x-dc19fd15307afa52) has left #ooo-math