From koffice  Thu Jun 13 08:00:10 2002
From: Thomas Zander <zander () planescape ! com>
Date: Thu, 13 Jun 2002 08:00:10 +0000
To: koffice
Subject: Re: What kind of HTML is KWord supposed to be able to import?
X-MARC-Message: https://marc.info/?l=koffice&m=102395557028981
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--LZvS9be/3tNcYl/X"


--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 12, 2002 at 01:52:37PM +0200, David Faure wrote:
> On Friday 07 June 2002 11:18, Thomas Zander wrote:
> > On Thu, Jun 06, 2002 at 09:13:45PM +0200, Frank Dekervel wrote:
> > > Op Thursday 06 June 2002 21:07, schreef Frank Dekervel:
> > > > kword's kwanchor::draw doesn't know about multi-page inline frames =
yet, so
> > > > drawing goes completely wrong. but thats not the only buggy place, =
there
> > > > must be others (i think but i'm not sure at all in drawing of
> > > > kwtextframeset)
> > >=20
> > > sorry. the last one is wrong. its only kwanchor::draw i found to be w=
rong.
> >=20
> > IIRC that code does not even have to be changed (much). The idea was to=
 create
> > a new anchor for the second page.
> >=20
> > So a multipage table has multiple anchors. One per page.
> > The hooks are there, but they are not done at all.
> >     QRect KWTableFrameSet::floatingFrameRect( int frameNum )
> > should use the the framenumber to return the page-specific QRect.
>=20
> Yes that was my initial idea, but Frank's later fixes proved to me
> that it's much easier to have one big inline frame (char) over two (or mo=
re)
> frames, than requiring that the inline framesets handle the "cutting" bet=
ween frames.
>=20
> Ah but then the cutting is done at the pixel level, which isn't what you =
want
> for tables. I start to see the problem ;)

Yes, and for any text frame.

IMO its not that hard; you just move the intelligence somewhere else. And a=
s with
all things, a concentration of logic you have to debug becomes quite hard.
In both cases the frameset has frames that are put on different pages. An i=
nline
text frame that is split accross pages suddenly has 2 text frames. The funn=
y thing
is that that is nothing new. We just want to avoid copying it in the append=
page
(IIRC we don't copy them since the are inline frames anyway) and now we hav=
e=20
two frames where the second is created when the first is full.

I really do think your initial design is good, it takes care of things in a=
 way
that fits with the rest of KWord.

Maybe your response of 'this is hard to do' is brought on by the problem of=
=20
debugging 4 parts of the program that interact with each other by using the
cause and effect. I.e. you press something in the GUI, the data structure c=
hanges
and the GUI shows the effect.  How to find out if the data structure is cha=
nged
correctly, or you have a bug in the displaying code. etc.

My solution has always been to create a little application that initializes=
 the
dataset in a pre-defined way and then emulates the way KWord uses the API (=
of
our componenet) that triggers the events we are coding.
The test application will then test the outcome of the dataset it holds.
Any errors; you are notified and the test-application exits.

Anyway, testing rulez, and this is just a good start to do that :)

--=20
Thomas Zander                                           zander@planescape.c=
om
                                                 We are what we pretend to =
be

--LZvS9be/3tNcYl/X
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9CFEKCojCW6H2z/QRAkB7AJ4tYxA6hV4LJnDxRDelpomwrwpb2ACfVT4y
AWa7blOBRCjzrUiQVuhw8c4=
=bgdq
-----END PGP SIGNATURE-----

--LZvS9be/3tNcYl/X--
____________________________________
koffice mailing list
koffice@mail.kde.org
To unsubscribe please visit:
http://mail.kde.org/mailman/listinfo/koffice