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

List:       koffice-devel
Subject:    Re: KWord WYSIWYG, KWord FrameClasses(?) and Re: WordPerfect filters
From:       David Faure <david () mandrakesoft ! com>
Date:       2002-02-20 14:24:44
[Download RAW message or body]

On Saturday 16 February 2002 20:53, Lucijan Busch wrote:
> Hi!
> 
> seem totaly tired after that subject ;).
> To come to the first part of my message. I've downloaded a snapshot yesterday 
> and installed a kdesnapshot yesterday.
> If i want to write on a frame with a backgroundcolor. The backgroundcolor is 
> only visible under the text. or in totaly text free part of frame. In the 
> documentview it self it looks ok. But this bug appears at printing and 
> printingpreview. Is this problem only known by me or does it exists for you 
> to? If yes is anyone working on it (i need a bit of time to come throu the 
> codingstyle and header/implementation locations).

Didn't realize this bug existed.
I think the code that's guilty is easy to spot.
You see, KoTextDocument::drawWYSIWYG  (lib/kotext/kotextdocument.cc)
calls either drawWithoutDoubleBuffer when printing or goes on and draws itself
when displaying on screen. So the bug is probably in drawWithoutDoubleBuffer.
Indeed drawWYSIWYG does much more stuff concerning background colors.
A tentative patch is below, but it doesn't work (color is wrong, and the right of the
paragraphs is still white...)

Index: kotextdocument.cc
===================================================================
RCS file: /home/kde/koffice/lib/kotext/kotextdocument.cc,v
retrieving revision 1.24
diff -u -p -r1.24 kotextdocument.cc
--- kotextdocument.cc   2002/02/17 10:31:06     1.24
+++ kotextdocument.cc   2002/02/20 14:21:58
@@ -163,6 +163,9 @@ void KoTextDocument::drawWithoutDoubleBu
            continue;
        }
        p->translate( 0, pr.y() );
+        QBrush brush = parag->backgroundColor() ? *parag->backgroundColor() : \
cg.brush( QColorGroup::Base ); +        if ( brush != Qt::NoBrush )
+           p->fillRect( QRect( 0, 0, pr.width(), pr.height() ), brush );
         //p->setBrushOrigin( p->brushOrigin() + QPoint( 0, pr.y() ) );
        parag->paint( *p, cg, 0, FALSE );
        p->translate( 0, -pr.y() );

Hmm, actually..... the parag backgroundColor isn't what's used here,
we're talking about the global background color for the document, which should
be in cg.brush. Looks like something in KWTextFrameSet forgets to set the
background color of the colorgroup..... Needs investigating.

> 2. (User)FrameClasses(?)
> Thoams Z. adviced me to make userdefinible Frame sheets were things like 
> background, lines, text streams and so on are stored and can be applied to 
> other very quickly.

Sounds good.
In a way this is very similar to the QTextFormat stuff for chars and to the
KoParagLayout stuff for paragraphs: a set of setting that can apply to
an object of a given type.
A collection that shares settings isn't probably worth it for frames, the
number is usually quite small. But the design of those classes can give
some hints.
I would suggest calling FrameFormat, btw, I think it makes it easier
to understand what it's about (well, just my personal preference).

> There are some questions wich should be asked before starting the 
> implementation.
> 
> -	Should the FrameClassTemplate be stored in the document
> (DEFAULT=yes ;) Problem->if the user wants to have the same StyleSheet on more 
> than one document he cant get it
By saving those into the template, as is the only solution for styles at the moment \
too. To be developed one day, is a dialog that allows exchanging styles (and \
frameformat styles) between documents (including templates).

> -	Should each frame remeber after aplying which FrameStyleCalss (thats the 
> best name by now) it belongs to
> Good: if you change one Frame he could ask: "do you want to apply this changes 
> to all Frame of this Frame Style Class?"
> Bad: problem how to store

Yes, it should work that way if we want it to work like styles.
But of course it must be possible that a frame has no known frameformat style,
since is the case already - and avoid enforcing that styles are used.
(for paragraphs it's a bit different, they all have a style in kword).

I'm glad to see someone tackling this job. Feel free to ask for more info if needed!

> od and now the last one:
> Herman:
> this tool is only avaible for windows?
Hmm ? Which tool ?

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://people.mandrakesoft.com/~david, http://www.konqueror.org
KDE 3.0: Konquering the Desktops

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