On Sun, Jun 17, 2007 at 06:02:19PM +0200, Stefan Schimanski wrote: > >On Fri, Jun 15, 2007 at 08:39:14AM +0200, Stefan Schimanski wrote: > >>Here is a patch for http://bugzilla.lyx.org/show_bug.cgi?id=3705. It > >>adds the kerning method to a macro to inherit the kerning from the > >>expanded form. Moreover the marker metrics calls are remove as they > >>are not drawn anyway. > >> > >>Stefan > >> > >>Index: src/mathed/MathMacro.h > >>=================================================================== > >>--- src/mathed/MathMacro.h (Revision 18774) > >>+++ src/mathed/MathMacro.h (Arbeitskopie) > >>@@ -54,6 +54,8 @@ > >> /// > >> docstring name() const; > >> /// > >>+ int kerning() const { return kerning_; } > > > >Could that be > > > > int kerning() const { return expanded_.kerning(); } > > > >or is expanded_ smashed before we access its kerning? > > The expanded_ only makes sense if not edited. Even if the value of it > might sense in edit mode as well I wouldn't depend on it. Those > implicit assumptions pay back if you change the code months later and > you don't remember about it. Here a few pixels have no consequences > of course... But also inlining has no effect here with a virtual method.
It's not about inlining, it's about that extra kerning_ member that needs to be kept in sync with expanded_.kerning() Andre'