Graphics: Title and label properties

[Shai Ayal]

On Mon, Jul 21, 2008 at 11:39 PM, Maciek Gajewski <
maciej.gajewski0 at gmail.com> wrote:

> Michael Goffioul wrote:
> > I would have done the opposite and consider 2D as a special case,
> > so you have a complete view of the problem from the beginning.
> > But I guess it's a matter of taste.
>
> Yes, yes, you're right. I've already avoided implementing 3D in Qt backend
> for
> too long. I should pospone work on in-octave features unitl my primary
> testbed (Qt-backend) is functional enough.
>
> > Well, I think it's a little bit more complicated than that. For instance,
> > TeX-like formatting (like subscripts or superscripts) will have an
> > influence on the text extent. We had some discussions with Shai about how
> > to tackle all of this and we end up with the following design ideas
> > (this is largely inspired by what I did in JHandles):
> > - separate font rendering, font metrics and text representation
> > (with TeX formatting info...)
> > - use a recursive container pattern to represent text content
> > (Shai already came with a set of classes, maybe you could post
> > it on the mailing list)
> > - use a visitor pattern to process the text and perform various
> > operations; among possible operations are: computing bounding
> > box, rendering...
> >
> > 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?
>

In order for octave to provide the position of, say, tick marks, it needs to
know the font metrics -- that will determine how many tics can be placed
(i.e. in a small window you can fit less ticks than in a large window). So
all the font metrics stuff needs to be reported from the backend to octave
through a yet unspecified API. I think the main thing that octave needs to
know is the bounding box for a text object.

Shai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.cae.wisc.edu/pipermail/octave-maintainers/attachments/20080722/3716e18e/attachment-0001.html