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

List:       koffice-devel
Subject:    Re: Bidi
From:       Stefan Nikolaus <stefan.nikolaus () kdemail ! net>
Date:       2007-07-03 11:42:44
Message-ID: 200707031342.47564.stefan.nikolaus () kdemail ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 03 July 2007 13:01:36 Thomas Zander wrote:
> On Tuesday 03 July 2007 12:08:04 Stefan Nikolaus wrote:
> > Hi Thomas,
> >
> > On Tuesday 03 July 2007 11:20:04 Thomas Zander wrote:
> > > The point here is;  I placed the key in the KoText namespace (as
> > > KoText::BidiDocument) and I want to know if there is a broader
> > > interrest in this concept of Bidi-ness, for example in kspread, which
> > > would be cause to move that key up to the KoResourceProvider
> > > namespace itself.
> > >
> > > Let me know!
> >
> > sure, there's interest. Not only for the Bidi text functionality, but
> > for KoText integration. One of KSpread's long time TODOs. ;-)
>
> Well, thats not quite what I asked, I was only asking if you have
> interrest in the boolean.  But, hey, if you want to use KoText, then the
> question is irrelevant ;)

The BiDi determination is done in the text shape/tool, isn't it? If it's not 
in KoText or KoText is not used it wouldn't be determined. Sounds like a very 
text shape or KoText specific feature to me.

> > Before I (or someone else) could start with the integration, some help
> > or advice would be tremendously useful. Now, that you've mentioned it
> > ...
> >
> > What exactly IS KoText?
>
> I just typed an introduction for the API docs.
>
> The short version;
>   "You can use KoText at all places where you would normally use a
> QTextDocument as the main text layout class in scribe can be replaced on
> any QTextDocument instance using QTextDocument::setDocumentLayout().
> This means you can use the Qt API as normal, but you will be able to use
> extra features like the plugins, the variables and the ODF loading and
> saving for all the ODF text-layout features."
>
> > I would very much appreciate, if all those layouting and
> > drawing could be done by calling a single method, that takes the text
> > and the rectangle the text should be painted in (like
> > QTextDocument::drawContents).
>
> I'm curious how much text-features each cell should have.
> I ask this because I can imagine that having a shape for each cell can
> consume too much memory. The tradeoff being that you can't use the
> textTool unless each cell is a text-shape.

Ideally, all what OpenDocument supports for paragraphs.

> The kotext library really is a library full of API code, not a lot of
> implementation code.  That all lives in the shapes/text plugin.
> So you can't use it without the full shape, its just not designed to do
> that.

Without the shape it's not usable? Why does it exist then? With API code you 
mean it provides just interfaces? How many methods do I have to implement to 
let it work?

> > You see, these are most of the question I had regarding the KoText
> > integration. Wether I am able to implement it is another story, but I
> > think some answers to these questions could also help others to do the
> > job. ;-)
>
> I think we should have a good look at what kspread needs, I think that a
> 100 lines of code in kspread will do everything you want on top of the
> QTextDocument already. Well, thats my first guestimate. And if its
> correct then I doubt using KoText is a smart thing to do.
>
> In KOffice1.x it made sense, but all the nice stuff will be available in
> plain Qt now.

Aha. OpenDocument support is not, for example. I hoped, KoText would have 
provided that, as it's common for all occurences of text paragraphs.

> Which brings me back to the original question of this thread ;)

See above. No interest in having the boolean now.

Regards,
Stefan

["signature.asc" (application/pgp-signature)]

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