On Mon, Jan 02, 2006 at 10:42:58AM +0100, Juergen Spitzmueller wrote: > Martin Vermeer wrote: > > > I think bug 2019 deserves your special attendance. > > > > Hmmm... perhaps the remark in insetcharstyle.C:draw: > > > > // I don't understand why the above .reduce and .realize aren't > > //needed, or even wanted, here. It just works. -- MV 10.04.2005 > > > > isn't quite true... could you have a look? I'm short on time right now. > > I have already tried to implement those, but that didn't change anything. I > have also tried other things to no avail, so I finally gave up. > I fear I just understand the whole fonts framework to less to fix this bug. > E.g. I just do not understand why, apparently, the color that is used to draw > the charstyle text on screen is also used in output, as is the case in the > bug in question. Aren't on-screen font colors and output font colors clearly > separated? > > Jürgen
Actually I don't dare to touch this stuff. The whole font architecture needs an overhaul/simplification. E.g., there are two different getFonts, one in lyxtext (for display) and one in paragraph (for latexing). There should be a clear concept of "underlying font", to which a font is reduced (or not) before drawing/latexing, be it the current layout default font, the "outer font" in nested lists, or the "outer font" outside the current inset. As of now, the concept exists but is sort-of implemented all over the place. Would it be an idea to open a bug targeting 1.5 for this? - Martin
pgpIivWBEP7hm.pgp
Description: PGP signature