On Tue, Oct 19, 2004 at 12:52:52PM +0200, Peter Ljungl�f wrote:
> In my current work I tend to get quite wide math equations; i.e. they  
> are wide LaTeX-wise (and also in LyX), but they will be printed on one  
> line in the end. I guess one reason is that I use some LaTeX commands  
> which I have defined in the preamble and not in the LyX file. An  
> equation might look like this (in LyX):
> 
>     \Rule{\Item{o}{i-j;f:A.r->s0 X1 s1 ... sn-1 Xn  
> sn}____\Item{o}{jd-kd;Xd}}{\Item{x}{A->f[B];r=j...k; 
> G}}\When{Gi=(r'=j'...k'|Xd=Bi.r')}
> 
> The commands \Rule, \Item, \When are defined in the preamble, since  
> they are quite complicated.

Note that you can use the secnd argument of math maro definitions to
give any macro any visual appearance that's 'fakeable' by other math
constructs.

> In the dvi file, the equation looks nice,  
> but in LyX the equation is too wide and does not fit in the window. The  
> problem is that it gets difficult to edit, since I don't see what I  
> write at the end of the equation...
> 
> Either I would like a way of manually line breaking an equation, only  
> in LyX, not in the dvi/pdf/ps file.

I have recently changed my mind about the difficulties to implement such
a thing and even know of a working implementation *cough*. However, I am
not sure how this approach translates from toy sized formulas to the
amount of formulas that may show up on a LyX screen. Idea is to have a
'line break inset' and extend the MathArray dim_ cache to a
vector<Dimension> linedims_, and handle 'line jumps' when 'drawing' such
a 'line break inset'. Conceptually not very hard, but costs at least 12
bytes for the vector 'wrapper' and around 12 + n x lines  for the
dynamic part, i.e at least 28 more byte for _every_ math 'blue box', even for
those not using the feature. Of course, situation would improve if the
size cache were moved off the insets, which is also possible an
intented. But not today...... 

> Or I'd request that the equation view follows the cursor so that I can  
> see what I write even at the end.

Probably more effort to implement as this requires support from the
frontend. The other solution is a 'pure core solution'.

Andre'

Reply via email to