On Monday 10 August 2009 03:28:16 pm Abdelrazak Younes wrote:
> On 10/08/2009 20:27, rgheck wrote:
> > On 08/10/2009 02:03 PM, Manoj Rajagopalan wrote:
> >> Thanks, Richard and Vincent.
> >>
> >> For a long time I've wished for a LaTeX rendering widget in Qt. I do
> >> a lot of
> >> scientific computing and I'd like my GUI's to contain label widgets that
> >> display greek symbols etc. and what better way to do this than to have a
> >> constructor that interprets a subset of latex commands. Eg:
> >>
> >> QLaTeXLabel *label = new QLaTeXLabel(this, QString("\frac{E}
> >> {\hbar\omega}"));
> >
> > I'm not sure, but I'd suspect that nothing like this is terribly
> > likely to come directly out of the LyX code.
>
> Well, Manoj could also simply embed a LyX work area. He just need to
> convert LyX into a library and use that. We have this nice sexy widget
> called EmbeddedWorkArea which is pretty straight forward to use :-)
>
> So Manoj, if you want to cleanup the source code a tiny bit so that we
> could generate a LyX dll instead of the executable, you're basically
> done. And you would be able to have a full blown LyX editor inside your
> app.
>
This is a good idea - I'll keep this on the radar. If this is possible, do you
think a certain amount of code reuse is possible between apps? For example,
in KDE4, KDevelop4 has been split into kdevplatform which provides the editor
part (which can be reused in various apps), and kdevelop which creates the
IDE application and embeds the editor part into its MDI child-buffers which
show a "view" of the files like in LyX. This way, related applications can
share the editor part which provides syntax highlighting etc. for many
supported languages.
Refactoring LyX to do this might be a huge task - I'd like to invite the
developers to simply consider this at this stage. An embedded lyx editor has
HUGE advantages. For example, this 'part' could be reused to implement a
KDevelop documentation plugin where one can embed mathematical formulae as
part of a function's documentation or to create labels in an SVG application.
> > Math insets are complex entities. Each character is, in fact, in its
> > own inset; \frac generates an inset; so does \hbar. So there are
> > several insets buried in LyX's representation of that simple bit of
> > LaTeX. So this will get painted via a long recursion through various
> > things like InsetMathFrac::draw().
> >
> > That said, what about doing something like instant preview? That would
> > give you a little picture.
> >
> >> Someone probably raised this issue a while ago on the LyX list and
> >> one of the
> >> developers replied that separating the lyx code to this would be a huge
> >> amount of work. I've been spending some of my spare time
> >> investigating if I
> >> could do this. For this I need to know how 'commands' (or macros, lyx
> >> parlance) are converted to glyphs which are rendered on the screen.
> >>
> >> My guess is there should be a fontmap somewhere that maps latex
> >> symbols to the
> >> glyphs to be printed and this info should be read sometime after the
> >> call to
> >> Cursor::macroModeClose(). Latex has an elaborate font-map setup for
> >> this.
> >> Does LyX simply read the latex setup to infer this fontmap or does it
> >> come
> >> canned with its own map? Where is all this information initialized?
> >
> > See the lib/symbols file. This maps things like \omega to a font (cmm)
> > and a codepoint, and does other stuff too. It gets read in the
> > initSymbols() routine in MathFactory.cpp.
>
> That being said, if Manoj just want to display greek symbols, he can
> just use unicode and a proper unicode fonts like the stix one. No need
> for a LaTeX renderer...
>
> Abdel.
Not just Greek symbols but fractions, superscripts, square-roots etc., i.e.,
full mathematical formulae short of numbering and cross-references etc. So I
might have to go the Inset way which Richard mentioned.
In achieving this, what should I keep in mind so that cut-and-paste to/from
LyX might work coherently?
-- Manoj
