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

List:       koffice-devel
Subject:    Re: ODF Lists
From:       Sebastian Sauer <mail () dipe ! org>
Date:       2008-07-30 22:46:39
Message-ID: 200807310046.40210.mail () dipe ! org
[Download RAW message or body]

On Wednesday 30 July 2008, Roopesh Chander wrote:
> On Wednesday 30 July 2008 02:54 AM, Sebastian Sauer wrote:
> > On Monday 28 July 2008, Pierre wrote:
> >>> In fact, this implies that headers are really a lot like paragraphs
> >>> (the only difference being they need to be included in the TOC) and not
> >>> at all like lists.
> >>
> >> That's what I was saying one or two weeks ago, and that's why there is
> >> something in KoTextBlockData now for headings.
> >> But I stopped discussing and agreed putting it in a list because it
> >> seemed to be simpler...
> >
> > It is. Just imagine the additional overhead to keep such headers in sync
> > with each other. We need a "global registry" for headers to be able to
> > access them rather fast anyway and that's what a list/tree does provide
> > us already direct within the document...
> > E.g. the toc atm needs to iterate though ALL blocks the document has just
> > to determinate the headers and that sucks ages. So, we would need a easy
> > way to remember+access+iterate through them anyway.
>
> I dont understand how adding all headers to their corresponding lists is
> going to help solve that problem.

What problem?

> We would still have to iterate through 
> all blocks,

y, for the case it's not an outline-toc (also non-headers aka styles that are 
used to build the toc what is NOT default btw). Anyway, headers are a way to 
provide a structure to documents and to don't use them internal for that and 
just handle them as paragraphs just sounds illogical^n for me.
Beside the toc-sample, which really may not the best one, there is also the 
outline-view sample even e.g. okular does provide cause it's a damn useful 
way to structure a big blog of content and to allow to navigate though those 
content.

> I think, because we need to know the relative position of 
> blocks across different qtextlists (of different outline levels).

for the pagenumber or for what? anyway, content is able to register itself 
already and to be informed if something changes... Well, probably a QTextList 
isn't really the best way either and just some "outlinehelper"/"headerhelper" 
(list, inline-objects, muh) that provides such functionality would match more 
or maybe there is even a much more easy way. In any case to just handle them 
as paragraphs/lists/with or without outline-style/etc. to turn them into pure 
paragraphs just doesn't sound like a good idea.

> Let's say all headings were added to that level's KoListStyle, what
> would be your algo then to generate the toc?

foreach(headerblock, headers) {
	[do something with the headerblock]
}

though I guess you don't asked for pseudo-code and something more explicit 
or? ;) hmm...

what we did in KWord 1.6;
iterate over all paragraphs and each KWTextParag had a partOfTableOfContents 
bool and if set, it got included in the toc.

what oo.org does;
and here it starts to get confusing++ cause oo.org duplicates code and logic 
quit a lot. the most interesting parts seem to be in sw/source/core/* and 
there
* each kind of textnode, what includes e.g. paragraphs, can have a 
outlineLevel, Level, numbering, etc.
* SwNodes saves does provide a "mutable SwOutlineNodes* pOutlineNds;" which 
does allow fast access to the outline-nodes
* that means, that oo.org *always* does provide a internal kind of toc where 
outlines are special cased
_______________________________________________
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]