> I understand when you use wrongly the word "inset" as a
> structure that holds font info, etc. I disagree with this usage but
> we won't stop the much more interesting discussion on the internal
> structure for this. (I just read that Allan will forget about font
> insets anyway, so let's all do it as well.)
I'll stick to my terminology right now, in order to avoid further confusion.
Later, when we agree on the structure, we can decide on the best terminology.
> > We have an inset that can contain a list of paragraphs. [...]
>
> With this description it's clear that the Paragraps don't have to be
> insets, they are already contained by an inset that would manage the
> geometry.
Agreed. (However, for other reasons, it might be an advantage that Paragraphs
are insets. But we are not ready to decide this yet, IMO.)
> So you suggest the InsetText to be a very basic text inset without no
> information about font changes nor other insets allowed in its
> contents. Some sort of atomic text inset with an LString as basic
> container. And are the other text inset derived from this one or are
> they independent?
I imagine the InsetText to have this structure:
class InsetText : public Inset {
...
private:
CharParams parameters;
LString text;
}
The CharParams contains a LyXFont. So an InsetText has a string, and a set of
parameters that describe the (logical) font, the language and other character
level properties. These properties apply to all characters in the string, and
this is the fundamental property of the InsetText's: We collect all possible
characters with the same character parameters into one InsetText.
So the shape of the InsetText is NOT rectangular. Rather, it's three
rectangles on top of each other.
The size of these rectangles rely on the context, and the Paragraph object is
the one that tells an InsetText the width of the first two rectangles, and the
height of the first. The InsetText will then tell the Paragraph how high the
second rectangle is, and how high and wide the third rectangle is.
This way, the InsetText and the Paragraph will collaborate to flow the text in
the parargraph.
So the shape of an InsetText corresponds exactly to how we flow a string of
fixed size glyphs.
> At first sight I see this model impractical and unnecessarily
> complex. Imagine you have a very large phrase without font changes
> that have to be broken in several lines to fit on the screen.
> Immediately becomes impractical to have it all inside a rectangular
> inset. I guess your answer would be: let's break it in three insets,
> as your example of the three boxes for a footnote inset. Or better,
> never allow a basic text inset to have more than one line. If it goes
> beyond the box boundaries, break it!
No, this is not my answer. My answer is: An inset does not have to
rectangular!
That's the basic premise of my proposal. This is the core of the
simplification in the data structure.
In particular, the InsetText has the shape of three rectangles on top of each
other. So, we do not have to split the insets to flow the text. On the other
hand, we can ensure that the InsetTexts are as big as possible, and therefore
that the data structure is as simple as possible.
> We all agree in that it's necessary to get ride of that stuff, what
> is not clear is how to do it. Your model doesn't automatically
> eliminates the need of the inset codes. You have to check how and
> where are they used. It does with font and inset tables, but still is
> not IMO a very ellegant solution (the low levet font info
> structures).
All we need is a flag that signals what of the two kinds of insets, a given
inset is. We have the ordinary rectangular insets, and we have the
three-rectangles-on-top type. The Paragraph inset has to manage these
differently, but it does not have to do this based on inset-codes
All it needs to know is how the inset can draw itself, and for this, it's
enough to know the overall type.
> At least it is not complete. How are InsetText and InsetFlow related in
> your model and can an insetflow be contained inside an insettext (I guess
> the insets that are contained in a paragraph are insettexts).
No, not necessarily.
The paragraph contains a vector<Inset *>, not a vector<InsetText *>. So, in a
paragraph, we can have a footnote Inset, or any other inset.
> The solution is to adopt a recursive way. Please give me some
> credit, this is the way the nested math insets are designed! An equation
> on the screen is as inset as the most deeper sqrt inset inside it. I
> don't see why this model can't be applied to the more general text case.
I want to apply this model! The Paragraph structure contains a vector<Inset
*>, and therefore we have the recursion. We have nested structures.
> 3- About the font info stuff.
I think my proposal is better: We have the exact span of a font change encoded
in the data structure.
> 4- With all this in mind, the remaining structure to discuss is the
> "atom" container (which btw has never been an LString and it
> doesn't have to be it). Imagine it as a vector<Inset*>. Even a single
> character would be an inset. How to save from the memory bloating?
I considered this myself, but I have concluded that it is much more efficient
to use a string inset, like the InsetText. The "only" thing we have to change
in order to support this, is the premise that an Inset can have a more complex
shape.
And since it's clear who will manage this extra complexity in the shape (the
Paragraph object), we can easily handle this.
Notice that I imagine that we *will* have a glyph atom container: The
InsetUnicode. This inset will contain exactly one unicode glyph, but this is
only meant to be a generalization of the current InsetAccents.
> In both approaches we would take full advantage of STL iterators
> and basic operations like copy, cut, paste, search, replace, etc
> would be made almost as easy as applying directly STL algorithms!
I agree that this is a major design goal.
> However this solution is not yet perfect. Your turn! :)
Now that it might be more clear what I intent to do, please consider my
approach again.
The main advantage is effeciency, ortogonality and simplicity. Allan
summarized our
entire datastructure in maybe 20 lines, and it's clear that the structure is
both memory and speed efficient.
Greets,
Asger
