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

List:       koffice-devel
Subject:    Re: underlining etc.
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2003-01-17 14:08:02
[Download RAW message or body]

I think too that adding many bytes to KoTextStringChar is not good, especially 
as we need the same procedure for strikeout too.

I like David's idea of the indirect storage of the ulw value in KoTextFormat, 
as it seems to be useful.

In a normal a text, there is typically at most one or two styles that are 
underlined (even if the user does it manually and not with styles.) So 
David's idea would just add two KoTextFormat objects, not bloating the 
document, even in a very long document.

The opposite, a fancy text where the user as chosen a diffrent font for each 
character, is not a problem either, as these font changes would all need a 
KoTextFormat each. So we have no excessive memory use compared to the current 
situation.

Have a nice day/evening/night!

On Friday 17 January 2003 01:56, David Faure wrote:
> -----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

_______________________________________________
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]