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

List:       koffice-devel
Subject:    Re: underlining etc.
From:       David Faure <dfaure () klaralvdalens-datakonsult ! se>
Date:       2003-01-17 0:56:53
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 17 January 2003 01:25, Tomasz Grobelny wrote:
> On czw 16. stycznia 2003 20:12, David Faure wrote:
> > On Thursday 16 January 2003 19:57, Tomasz Grobelny wrote:
> > > Would 4 bytes for interger be acceptable?
> >
> > No, sorry. Wasting 4 bytes per char only for the very rare case of
> > different underline widths is not worth it. Do you realize how much memory
> > it eats? You get 33% more memory being used. In the document 1dfre10.txt
> > found by jon-d, with 1600000 characters, you'd get a memory usage - just
> > for the characters - of 32MB instead of 25MB !
> >
> It would be 25% (16->20 bytes) to be precise. 

No, the current size of KoTextStringChar is 12, without the recent addition of a "double".
So it goes from 12 to 16...

> BTW couldn't x be "short int" instead of "int"?

Would still lead to 16 bytes due to compiler alignment, and you'd end up with
precision problems at some zoom levels possibly. And: as I said, this is NOT
character specific anyway.

> > This is exactly why everything else (concerning characters) is in
> > KoTextFormat.
> >
> But this property is a bit diffrent: user can't change it
Doesn't matter.
They can change the font size, which will end up changing the width of the
line, with some code in the textformatter calculating it.

> it can't be saved 
> to/read from file and it is not that dependent on what a user sets. It is all 
> about _calculating_ and drawing.

So? This doesn't mean that KoTextFormat isn't the best place to store it.

> > Ok, I tested in OpenOffice and
> > 1) the width (and distance) of the underline is indeed the same for the a
> > set of underlined characters next to each other (but can be different
> > within a paragraph, of course). 2) it's not averaged, it's max()ed. This
> > means the biggest font size wins, which makes sense.
> >
> Do you mean that underline width depends only on the biggest font? In case of 
> OpenOffice 1.0 that's not true. It is average (of some kind).

Ok, average is fine with me too. That's not the point.
The important point is that it's the SAME value for all characters underlined
together (so what's the point in storing that value in each character??)

> > This is easy to implement, in fact. The width is the _same_ for all the
> > underlined characters. So there's no need to store it in the characters.
> > Simply store it in all the kotextformats that are part of a "set of
> > underlined characters". This means that this property must be added to
> > kotextformat, must be part of its key, and the textformatter must set it,
> > to the biggest width for a given set of underlined characters.
> It is the same for all characters in one group. But can be diffrent for 
> characters of the same formatting that are placed in diffrent lines. And 
> AFAIR KoTextFormat object is shared between characters of the same formatting 
> so we can't separate this easily. 

Of course you can. As soon as you ask for a kotextformat which has a different
ulw value, you'll get a different one. The KoTextFormatCollection takes care of that.
Take another example: you have two underlined words, in different lines (or not), 
and you make the first one bold. This will NOT make the second word bold.
Why? Because we ask for a textformat that's both "bold and underline".
This would work exactly the same if you add ulw to kotextformat. The code will ask
for a textformat that's "underlined, with a ulw of 13". This will return an existing
textformat with ulw=13 if there's one, otherwise it will return a NEW textformat,
setting the right value for its ulw.

> If ulw was a property of KoTextFormat it 
> could force creating KoTextFormat objects on line break, and that's not the 
> right way IMHO.
Not on line break, but for each combination of different values. But it's much
better to have ONE more kotextformat object (for all underlined characters
of fontsize N and ulw=13) than having 4 bytes in EVERY character in the 
document, even those that are not underlined at all.
But this has nothing to do with line breaks: you could have another set of
characters with fontsize N and ulw=13 somewhere else.
Of course you could also have characters of fontsize !=N and ulw 13 (-> 
a different kotextformat) or with fontsize=N and ulw!= 13 (-> another kotextformat). 
But that's still very far from eating the 7 MB of memory of the other solution....

- -- 
David Faure -- faure@kde.org, dfaure@klaralvdalens-datakonsult.se
Klarälvdalens Datakonsult AB, Platform-independent software solutions
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KOffice-1.2.1 is available - http://download.kde.org/stable/koffice-1.2.1/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+J1TV72KcVAmwbhARAjzEAJ9gw2oLJt8bMr8qn5CHCZke2311cgCcDKXp
DNGxWYpnQexVCt2d3KxEjWI=
=47iM
-----END PGP SIGNATURE-----

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]