>>>>> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> Here's my idea of the inset design at the moment. I hope this
Asger> will settle the discussion between Alejandro and Allan, which
Asger> mostly is a discussion about words.
I mostly agree with what Asger writes. A few remarks:
Asger> We have an inset that can contain a list of paragraphs. This
Asger> inset corresponds to the flow inset: We give it some geometry
Asger> to tell it where to draw itself, and it returns information
Asger> about what screen estate it needs to do the job (i.e. the
Asger> height). Let's call this inset a InsetFlow for the lack of a
Asger> better name (I want to preserve the name InsetText for
Asger> something else. See below.)
Why not us the LaTeX terminology and call it a InsetParbox? A \parbox
is exactly what you describe, if I understood correctly. For example,
does your InsetFlow live in a rectangle?
Asger> This InsetFlow contains a list<Paragraph *>.
Right.
Asger> A paragraph is not necessarily an inset, but it contains a
Asger> vector<Inset *> that holds the text of a paragraph. It also
Asger> contains a pointer to a ParagraphParams structure that keeps
Asger> all the structural information: Which layout it is, the nesting
Asger> depth, whether it's a heading or not, and all the other
Asger> information that we have in the Paragraph * structure
Asger> now. (Notice that this information is enough to solve the
Asger> nesting problem that Allan posed.) By moving these parameters
Asger> to a ParagraphParams structure, we can save a lot of memory,
Asger> because the ParagraphParams structures can be reused.
Do you mean that ParagraphParams will be shared and use reference
couting like LStrings?
Asger> Besides the InsetFlow and the Paragraph, we have the ordinary
Asger> glyph Insets: References, label, math insets, and others. Take
Asger> the footnote inset. This is an inset that contains a
Asger> FlowInset. Next to these "ordinary" insets, we also have the
Asger> InsetText. This insets contains the text of the document, in
Asger> the form of an LString. It also contains a pointer to a
Asger> CharParams structure, that is similar to the ParagraphParams
Asger> structure, and contains the information about the text in the
Asger> inset. This includes Font, Logical Font, language and other
Asger> character level information.
So this InsetText is the one which can have a non-rectangular shape,
right?
Asger> Notice that this implies that we will have no more Inset-codes,
Asger> no more font tables, and no more inset tables.
... and that's good.
Asger> This design is the result I have come to from the discussions
Asger> we have had so far. There are more details about this in my
Asger> head, and this is what I'll try to write down in a proposal
Asger> kernel document when I get the time. However, if you feel that
Asger> this overall approach is flawed, please tell me.
I think I'll wait until you have spent 10+ hours writing the document
before explaining why I know this design is fundamentally flawed ;-P
JMarc
