Re: Graphics: Title and label properties

[Daniel J Sebald]

Michael Goffioul wrote:
> On Mon, Jul 21, 2008 at 10:39 PM, Maciek Gajewski
> <address@hidden> wrote:
>
> > > Based on that, computing the text extent means parsing the text
> > > representation tree with a fontmetrics provider (here we thought
> > > naturally about using FreeType library).
> >
> > Whoa!
> >
> > I don't get it - why such a features _inside_ octave? Isn't it backend stuff?
> > thought that octave only provides backend with text position (in plot
> > coordinates) and string (be it plain or TeX). Why such a low-level features
> > in core graphics code?
>
>
> For several reasons, but the 3 main ones are:
> - we want any backend to produce more or less the same graphics results
> - we want to avoid duplicate coding effort in backends and provide
> a common framework where possible.
> - grouping coding power instead of spreading it (we already have so
> few people to do the work...)
>
> You could go for a simple "draw_text" method in the backend, but this
> mean that each backend would have to implement its own TeX parser,
> potentially producing different results or different support level (the backend
> A support this symbol, while the backend B does not).

How much of a subset will the "mid-level" parser support?  Just simple TeX 
constructs like subscript ('_'), superscript ('^'), and a few others?  [Those aren't 
emoticons in the previous sentence.]  In some situations, it may be that the syntax 
simply gets passed on.  For example, if the end device is a LaTeX interpreter, the TeX 
commands shouldn't be interpretted.  That way a complete set of commands can be utilized.

Is there a distinction to make here about how "LaTeX sub-commands" are handled?  Is what 
you are referring to actually called "LaTeX command set" in the computer world?  Or is it 
just some loose standard that came about and now everyone uses?

Dan