[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: formula in kword are buggy
From:       Ulrich Kuettler <ulrich.kuettler () mailbox ! tu-dresden ! de>
Date:       2001-06-20 19:48:56
[Download RAW message or body]

On Tuesday 19 June 2001 23:38, David Faure wrote:
> On Monday 18 June 2001 21:51, Ulrich Kuettler wrote:
> > Hi,
> >
> > there are three things that need to be fixed to make formulas in kword
> > working. I'm going to do the kformula side of this but will need help
> > when it comes to kword.
> >
> > 1. Text and formula need to be on a common base line.
>
> Interesting problem ;-)
>
> This requires an extension, not only in KWord but even in QRichText.
> Currently QTextStringChar::ascent() returns customItem()->height() for a
> custom item.... So this needs a new virtual method in QTextCustomItem
> instead. Easily done. Actually... done :)
> Now we must fix KWAnchor to return the proper ascent. Well, it could ask it
> from KWFrameSet. If you implement KWFormulaFrameset::ascent (or baseline,
> whatever you prefer to call it), I'll call it from there.

Great. But there are a lot of problems.

- It doesn't work if there are more formulas with different height in one 
line.

- After a formulas height changed the text doesn't get updated. Or it gets 
updated but with the old size.

- If you open a file that contains some formulas you get a real mess. It 
helps to scroll up and down then.

- It's possible to change a formula frames size. This leads to a movement of 
the formula if you choose to change the left side.

- Changing the zoom factor causes some formulas to be on a wrong place.

I'm sure it's my code (at least partly) that causes this mess. But I don't 
see what to do about it.

>
> > 2. A formula needs to use the surrounding text's font size as base for
> > its calculations.
>
> Any inline item, including formulas, actually have a QTextFormat of their
> own. This includes a font name, size, whether bold/italic/underlined,
> colour etc. This is what we use for variables, which are inline items too
> (aka custom items). Obviously you don't want to 'obey' all of that, but the
> font size could be taken from there.
> Technically, here's how to do this from kwformulaframeset :
>
> if ( isFloating() )
> {
>     // we need to look for the anchor every time, don't cache this value.
> undo/redo creates/deletes anchors KWAnchor * anchor = findAnchor( 0 );
>     if ( anchor )
>     {
>         QTextFormat * format = anchor->format();      // just moved
> format() to kwtextcustomitem for this // from here you can find out the
> font size etc.

Where to place this code? I put it in KWFormulaFrameSet::drawFrame to test 
before each draw. But isn't there a better place?

> Actually you can even find the baseline from there, and return it in the
> above-mentionned virtual method. We just can't do that automatically for
> all customitems (an image does not have the baseline of the format() that a
> character in its place would have ;-)
>
> > 3. It must be able to enter and leave a formula by ordinary cursor
> > movement.
>
> Yes... that's a little bit harder.... Hmm, although....
> It's all about testing for a custom item that supports this, in
> KWTextFrameSetEdit::keyPressEvent I'll take care of this. But what should I
> do once I know I want to enter a formula ? I can start an edit object on it
> (hmm, and terminate the current one, so some of this code has to be in
> kwcanvas to avoid a "delete this"...),
> but how to place its cursor at the right position inside the formula ?

There are now the two methods 'moveHome' and 'moveEnd' in 
KWFormulaFrameSetEdit that should do the trick. But how to move out of a 
formula? I've prepared KWFormulaFrameSetEdit::keyPressEvent but this probably 
won't do.

Uli

_______________________________________________
Koffice-devel mailing list
Koffice-devel@master.kde.org
http://master.kde.org/mailman/listinfo/koffice-devel

[prev in list] [next in list] [prev in thread] [next in thread]