Andre Poenitz wrote: > > My last patch gives us an almost working 'real' \mbox inset for > mathed I.e. creation and editing works, but nothing I/O related. > > The reason for this is that mathed and texted still use different > I/O schemes (I don't mean the format here, but mainly the signatures > of I/O functions). > > In mathed we have > > virtual void write(WriteStream & os) const; > virtual void normalize(NormalStream &) const; > virtual void maple(MapleStream &) const; > virtual void maxima(MaximaStream &) const; > virtual void mathematica(MathematicaStream &) const; > virtual void mathmlize(MathMLStream &) const; > virtual void octave(OctaveStream &) const;
Question: why do you call the functions by different names if they take different stream types? Why not call them all 'write'? Question 2. Does mathed not need the 'Buffer const &' and 'OutputParams const &' data passed to the texted output functions, or are these accessed from the streams? (Ie, os.buffer() etc.) > > Needless to say that both schemes do not fit together too well, and > neither scheme is perfect. The mathed implementation does not > reflect the High Art of Streams (i.e. a decent streambuf based > implementation), Is this important to mathed or is this an implementation detail that can be sorted out in the 1.5.x series? > and 'latex' calls 'write' instead the other way round Why is that important? > and the texted implementation is less flexible when it comes > to format specific parameters and it is more verbose on the user > side. You mean we interrogate OutputParams to ascertain the 'flavour' of the latex desired rather than differentiate at compile time with different streams? > I'd like to consolidate this at least for the write/latex part as > this would allow me to drop quite a bit of code from > math-text-lookalike insets as MathBoxInset. I don't have any objections. This is just code shuffling isn't it? No real redesign at all, at least for now. -- Angus