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

List:       koffice-devel
Subject:    Re: Bidi
From:       Sebastian Sauer <mail () dipe ! org>
Date:       2007-07-09 17:35:08
Message-ID: 200707091935.08185.mail () dipe ! org
[Download RAW message or body]

On Monday 09 July 2007, Stefan Nikolaus wrote:
> On Monday 09 July 2007 09:05:05 Thomas Zander wrote:
> > On Saturday 07 July 2007 18:20:38 Stefan Nikolaus wrote:
> > > > Only paragraphs or also images, lists, tables, ... so, full or
> > > > fragments of odt documents? Only paragraphs include formatting would
> > > > be easy and as Thomas pointed out, that's already possible with
> > > > kotext.
> > >
> > > I'd be pleased with per-character styles, alignment, (visualization of)
> > > spell-checking, rotated text in a non-rotated rect.
> >
> > I think this is not too hard to do, and you can do that without the
> > plugin. Styles you can reuse from KoText.
> >
> > A general approach I would probably take is this;
> > * Store either a QString and style, or a QTextDocument per cell.
> > This choice should be tested as the QString is obviously going to cost
> > less memory, but the painting may take quite a bit longer as you end up
> > doing a full text-layout (including line breaking) at every repaint.
>
> The first option should work at an acceptable speed, as we can cache a
> QTextDocument in CellView. Currently, that's already done with the layouted
> (truncated) QString. On value and style changes the complete CellView,
> including this string, is recreated.
>
> > * Use the KoText style manager and styles to format your text. The end
> > result is a plain normal QTextDocument instance as the KoText/styles work
> > on the normal Qt structures.
> >
> > * Write a custom layouter. This can be pretty short; take a look at the
> >    doc/html/qt4-scribe.html#plain-text-layout
> > in your local Qt copy. I'm willing to help you write one, if you like.
>
> Okay, looks easy enough. ;)
>
> > * Write a painting method that will do any rotation or scaling and then
> > will draw 1 cell using a normal QTextDocument::drawContents()
> > Based on the decision made in the first point (store a doc or a string)
> > you can either move all these steps into 1 method, but do extra work
> > every time you paint. Or you can separate those steps and let the
> > QTextDocument do some caching of layout.
>
> The text rotation should already be considered in the layout process.
> Rotation and scaling of the complete cells is the job of QPainter. So, yes,
> a method, that combines both rotations the right way, is necessary.
>
> > In the text shape I separate these items which makes repainting of text
> > very responsive, but a little heavier on memory use.
> >
> > Hope that helps.
>
> Yes, except, that my motivation for this task is not very high. But that's
> not your fault. :)
>
> Any volunteer? Sebastian? :)

So, we have Thomas who would help with the layout and me who would help with 
kotext. Guess to get a start we now just need some basic code within KSpread 
that shows how this should be integrated (since while I know KSpread a bit I 
have no clue what would be the best way here).

re layout; and I still guess we should move the layout-code or at least parts 
of it to kotext since to have n different layouters that are doing the same 
just does not sound wise for me.
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]