On Wed, Aug 20, 2003 at 11:17:32AM +0200, Andre Poenitz spake thusly:
>
> On Wed, Aug 20, 2003 at 12:06:35PM +0300, Martin Vermeer wrote:
> > Here is a patch doing the following things:
> >
> > 1) calculates a realistic width for insets containing a single short
> > line ("row") of text, puts it into the LyXText metrics and displays
> > the inset at this width;
> >
> > 2) experimentally for branch insets, displays such insets (if
> > uncollapsed) as inlines embedded in the surrounding text.
> >
> > My question is, is this the right way to approach this? It appears
> > this capability has been there all the time (for ERT at least), but
> > was broken and switched off (disappeared spontaneously?) during
> > André's paragraph overhaul.
>
> I don't think I broke something in this area - at least not on
> purpose...I don't think 'during' implies causation ;-) > > Or am I too early with this? > > No, time is fine now. > > > (ideally we should have multi-line inlined insets. But they would be > > non-rectangular, which seems outside the current paradigm (?)) > > I think there is consensus to switch to Asger's "three box model" for > paragraphs (i.e. first and third box possibly less than full width, > second box full width, additional special case if the whole thing is > less than one line all together. Yes, I remember discussion on this. That requires 1) the ability to draw a more general outline / paint a more general background than a rectangle. Almost trivial. 2) A more general metrics model than the asc/desc/width (i.e., treating insets as super-big quasi-characters, or 'TeX boxes') model we have now. I must admit to seeing only vaguely how it would be done. Somehow the first box should receive the current x position of the text (for redoParagraph to work out how much text it should contain), and the third box should hand out that x position to the text following it (OK, that would be trivial; the third box is just output from the left edge with its dim.wid). The middle box would just go as a LyXText on a line of its own using the needFullRow mechanism. Do you really envisage these three boxes to behave as three quasi-characters each with its own metrics? That would work, I think. In that case the first box would know its width in advance (from the current x position) and should "clip off" a suitable amount of paragraph using redoParagraph/rowBreakPoint. OK. Is that your thought too? > With the per-paragraph row lists we are actually in pretty good shape > now to tackle this problem. > > Having non-rectangular paragraphs/insets would not only mean nicer > insets in paragraphs but opens also the door for neater label handling. Agreed. > Andre' - Martin
pgp00000.pgp
Description: PGP signature
