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

List:       koffice-devel
Subject:    Re: Bidi
From:       Thomas Zander <zander () kde ! org>
Date:       2007-07-03 12:34:43
Message-ID: 200707031434.43479.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 03 July 2007 13:42:44 Stefan Nikolaus wrote:
> 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.

Well, its just a boolean that indeed kotext is one to set and use.
Like the color palette sets and uses the color.  But that doesn't mean 
someone else won't be using or setting it :)
That was the question; does someone else want to use and / or set the 
boolean.

Sorry for being unclear.

> > 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? 

The ODF loading / saving will still work, but features that are not 
supported by QText will not be rendered properly.

> With API 
> code you mean it provides just interfaces? How many methods do I have
> to implement to let it work?

With API I mean its meant to be used together with the plugin where the 
layouting is done and where gui stuff lives.
You doing your own implementation might be possible, the major class to 
implement is the KoTextDocumentLayout::LayoutState class.
But I'm not sure if thats useful.

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

Ah, yes, ODF loading / saving is available for any QTextDocument user.
Its just that if you want to see things that are not supported by QText 
you need the plugin.
Hmm, I have not designed the ODF loading API myself, so I might be wrong 
that its possible.  But technically its possible, so while the API might 
need some tweaking, you should count on being able to use the loading / 
saving.

So I suggest you use loading / saving of ODF.
Next, if the normal QTextDocument API doesn't work for you for cell 
painting, then we can take another look at better solutions.
But my guess is that using the setPageSize and the postscriptPaintdevice 
you should be able to get most stuff working.

-- 
Thomas Zander

[Attachment #5 (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]