On Tue, Oct 21, 2003 at 11:41:41AM +0100, Angus Leeming wrote: > > What problem are you trying to solve that's not solvable by locally > > factoring out some common code from metrics() and draw() in a few > > fat insets? > > Have I answered this question with the above?
Sort of. > I _really_ would like the ability to mark-up text handled by the > frontends and think that a fully-fledged widget embedding one of our > Painters would be excessive in many instances... Think to the end: This amounts to implementing a "stream language" which is capable to carry all "interesting" information. Not just font stuff, but a \hat accent and maybe a \sqrt drawing. So this languange is more or less as powerful as the .lyx file format. The core would encode data in this language and the frontends would "interpret" them. So the relation between frontend and streamlanguage is about the same as the between web browsers and HTML. It might be an interesting idea, but in my opinion any step in this direction is a complete waste of resources of developers and users. Neither your nor we will finish creating the equivalent of two web browsers and the whole encoding/decoding idea smells like bloat. If you have the feeling that the current drawing primitives by the frontends are not sufficient, try to point to a real problem. Maybe this could be overcome by a new "primitive" operation. I really don't see a point in encoding font changes in a string to be drawn. The mechanism is the same for all frontends, so this work could as well be done in the core once. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
