Graphics: Title and label properties

[Maciej Gajewski]

Hello

I've noticed that current axes code doesn't takes special care for title and
x/y/(z) label items. They are created when appropriate, but I think (and
compatibility suggest) that axes should initialize they properties, and then
update them when needed.

Especially:

- positions of all these labels should be updated whenever xlim/ylim/zlim
changes, so labels and title are painted in proper positions,
- clipping should be set off, so labels can be displayed outside axes plot
box,
- y-label should be rotated 90 degrees
etc.

This could be done in backend, but IMO octave should take care of this. Are
there any plans to do it? If no, I'd like to do it .

BTW I  have another question: why the default font size for axes is 12, when
competition have 10 points (which looks better)?

Maciek Gajewski

[John W. Eaton]

On 20-Jul-2008, Maciek Gajewski wrote:

| I've noticed that current axes code doesn't takes special care for title and
| x/y/(z) label items. They are created when appropriate, but I think (and
| compatibility suggest) that axes should initialize they properties, and then
| update them when needed.
|
| Especially:
|
| - positions of all these labels should be updated whenever xlim/ylim/zlim
| changes, so labels and title are painted in proper positions,
| - clipping should be set off, so labels can be displayed outside axes plot
| box,
| - y-label should be rotated 90 degrees
| etc.
|
| This could be done in backend, but IMO octave should take care of this. Are
| there any plans to do it? If no, I'd like to do it .

Sure, propose a patch.

| BTW I  have another question: why the default font size for axes is 12, when
| competition have 10 points (which looks better)?

I'd say "better" here is subjective.

jwe

[Michael Goffioul-2]

On Sun, Jul 20, 2008 at 10:35 AM, Maciek Gajewski
<maciej.gajewski0@...> wrote:

> Hello
>
> I've noticed that current axes code doesn't takes special care for title and
> x/y/(z) label items. They are created when appropriate, but I think (and
> compatibility suggest) that axes should initialize they properties, and then
> update them when needed.
>
> Especially:
>
> - positions of all these labels should be updated whenever xlim/ylim/zlim
> changes, so labels and title are painted in proper positions,
> - clipping should be set off, so labels can be displayed outside axes plot
> box,
> - y-label should be rotated 90 degrees
> etc.
>
> This could be done in backend, but IMO octave should take care of this. Are
> there any plans to do it? If no, I'd like to do it .

Help is always welcome. These kind of things (let's call it label/title
auto-location) are currently handled in the OpenGL renderer, when the
axes is rendered. This is probably not the best place, but this seemed
convenient (as a first draft), because placing correctly the labels
involves knowledge of rendering information like the font metrics.

Placing correctly the labels and title means determining the position,
the rotation and the Horz./Vert. alignment. This must take into account
the current axes transformation (2D/3D, azimuth and elevation angles...),
but also the tick marks length and text (both font metric and actual text.
For instance, taking your remark above that the y-label should be
rotated 90 degrees, this is only true for plain-2D (azimuth=0, elevation=90).

AFAIK Shai is working on the text engine, including an interface to
get font metrics. This should help in placing the labels correctly. But
definitely, this auto-location should be taken out of the OpenGL
renderer. So, again, help is always welcome.

Michael.

[Shai Ayal-2]

On Sun, Jul 20, 2008 at 6:29 PM, Michael Goffioul <michael.goffioul@...> wrote:

On Sun, Jul 20, 2008 at 10:35 AM, Maciek Gajewski
<maciej.gajewski0@...> wrote:
> Hello
>
> I've noticed that current axes code doesn't takes special care for title and
> x/y/(z) label items. They are created when appropriate, but I think (and
> compatibility suggest) that axes should initialize they properties, and then
> update them when needed.
>
> Especially:
>
> - positions of all these labels should be updated whenever xlim/ylim/zlim
> changes, so labels and title are painted in proper positions,
> - clipping should be set off, so labels can be displayed outside axes plot
> box,
> - y-label should be rotated 90 degrees
> etc.
>
> This could be done in backend, but IMO octave should take care of this. Are
> there any plans to do it? If no, I'd like to do it .

Help is always welcome. These kind of things (let's call it label/title
auto-location) are currently handled in the OpenGL renderer, when the
axes is rendered. This is probably not the best place, but this seemed
convenient (as a first draft), because placing correctly the labels
involves knowledge of rendering information like the font metrics.

Placing correctly the labels and title means determining the position,
the rotation and the Horz./Vert. alignment. This must take into account
the current axes transformation (2D/3D, azimuth and elevation angles...),
but also the tick marks length and text (both font metric and actual text.
For instance, taking your remark above that the y-label should be
rotated 90 degrees, this is only true for plain-2D (azimuth=0, elevation=90).

AFAIK Shai is working on the text engine, including an interface to
get font metrics. This should help in placing the labels correctly. But
definitely, this auto-location should be taken out of the OpenGL
renderer. So, again, help is always welcome.

Sadly "Working  on it" is highly exaggerated :( . I'm afraid I have been unable to contribute for the last two-three months. So, please proceed w/o me if you want. I'll try to join in later if I can commit the time ...

Shai

[Maciej Gajewski]

Michael Goffioul wrote:
> Placing correctly the labels and title means determining the position,
> the rotation and the Horz./Vert. alignment. This must take into account
> the current axes transformation (2D/3D, azimuth and elevation angles...),
> but also the tick marks length and text (both font metric and actual text.
> For instance, taking your remark above that the y-label should be
> rotated 90 degrees, this is only true for plain-2D (azimuth=0,
> elevation=90).

Yes, taking 3D into account makes problem waaaay more complicated. So maybe
I'll start with auto-positioning for 2D, and then expand it to 3D.

> AFAIK Shai is working on the text engine, including an interface to
> get font metrics. This should help in placing the labels correctly. But
> definitely, this auto-location should be taken out of the OpenGL
> renderer. So, again, help is always welcome.

I've noticed double base_graphics_backend::get_screen_resolution (), which
could be used for simplest font metrics implementation.

To get complete font metrics information from backend, interface could be
extended by calls like these:

rectangle get_text_extend ( string text, double font_size, string face_name );

or

rectangle get_text_extend ( handle h, string text ); - where font size and
face name are taken from properties of object identified by 'h'.

Here I have a question: are there any readily-available types in octave which
can be used to store rectangle, point and other geometrical types?

John W. Eaton wrote:
> | BTW I  have another question: why the default font size for axes is 12,
> | when competition have 10 points (which looks better)?
>
> I'd say "better" here is subjective.

I'm not asking because aesthetics. It's because of title location. Axes title
fits into margin above axes. When default font is too big, margin also needs
to be big enough.

Maciek Gajewski

[Michael Goffioul-2]

On Mon, Jul 21, 2008 at 10:07 AM, Maciek Gajewski
<maciej.gajewski0@...> wrote:
> Yes, taking 3D into account makes problem waaaay more complicated. So maybe
> I'll start with auto-positioning for 2D, and then expand it to 3D.

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.

>> AFAIK Shai is working on the text engine, including an interface to
>> get font metrics. This should help in placing the labels correctly. But
>> definitely, this auto-location should be taken out of the OpenGL
>> renderer. So, again, help is always welcome.
>
> I've noticed double base_graphics_backend::get_screen_resolution (), which
> could be used for simplest font metrics implementation.
>
> To get complete font metrics information from backend, interface could be
> extended by calls like these:
>
> rectangle get_text_extend ( string text, double font_size, string face_name );
>
> or
>
> rectangle get_text_extend ( handle h, string text ); - where font size and
> face name are taken from properties of object identified by 'h'.

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).

> Here I have a question: are there any readily-available types in octave which
> can be used to store rectangle, point and other geometrical types?

No. When I need a rectangle or point, I use a Matrix object. This
is usually enough for my purpose.

>> I'd say "better" here is subjective.
>
> I'm not asking because aesthetics. It's because of title location. Axes title
> fits into margin above axes. When default font is too big, margin also needs
> to be big enough.

Basically, the axes position should be computed taking into account
the fontmetrics information for the title, the labels and the tick text.
This is of course missing, because we still need to get fontmetrics
information. For the time being, the margins around an axes are
just static.

Michael.

[Maciej Gajewski]

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?

Maciek Gajewski

[Daniel J Sebald]

Michael Goffioul wrote:

> On Mon, Jul 21, 2008 at 10:07 AM, Maciek Gajewski
> <maciej.gajewski0@...> wrote:
>
>>Yes, taking 3D into account makes problem waaaay more complicated. So maybe
>>I'll start with auto-positioning for 2D, and then expand it to 3D.
>
>
> 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, I'd suggest working with 3D vectors.  Keep the viewing angle information in some form.  (I suppose azimuth and elevation are one way, but not necessarily unique.)  But then translate that into some form of rotation matrix, call it R.  Then the translated position would be

y = R x

where R is 3 by 3 (or 2 by 3) and x is length 3.

Gnuplot sort of developed with 2D code and 3D code as separate entities.  That caused a bit of a headache.

What is the status of the graphics handles and such?  Has it moved along and will there be a need to build/verify a gnuplot backend any time soon?  Or is the graphics handles still far off?  (I tuned out of the list for a while.)

Dan

[Shai Ayal-3]

On Mon, Jul 21, 2008 at 11:39 PM, Maciek Gajewski <maciej.gajewski0@...> 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

[Michael Goffioul-2]

On Mon, Jul 21, 2008 at 10:39 PM, Maciek Gajewski
<maciej.gajewski0@...> 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). Not having some
font metrics information at octave level makes almost impossible to
implement correct label/title auto-location, as well as other things like
legend positioning or axes margin computation. Again this would have
to be done in the backend, spreading coding effort.

All in all, I think it's wiser to provide a common framework where
possible. Text representation and parsing seems to be a good
candidate. The rendering would still be left to the backend, but at
least the text content is already analyzed and decomposed, which
makes life of the renderer somewhat easier.

Michael.

[Michael Goffioul-2]

On Tue, Jul 22, 2008 at 4:34 AM, Daniel J Sebald <daniel.sebald@...> wrote:
> Yes, I'd suggest working with 3D vectors.  Keep the viewing angle
> information in some form.  (I suppose azimuth and elevation are one way, but
> not necessarily unique.)  But then translate that into some form of rotation
> matrix, call it R.  Then the translated position would be
>
> y = R x
>
> where R is 3 by 3 (or 2 by 3) and x is length 3.

This is handled in a more general way by storing transformation matrices
in the axes object. These matrices can be used by any backend (and they
are used as xform matrices in the OpenGL renderer). These are accessible
through hidden properties in the axes object.

> Gnuplot sort of developed with 2D code and 3D code as separate entities.
>  That caused a bit of a headache.
>
> What is the status of the graphics handles and such?  Has it moved along and
> will there be a need to build/verify a gnuplot backend any time soon?  Or is
> the graphics handles still far off?  (I tuned out of the list for a while.)

The 3.1.50 snapshot contains an experimental OpenGL renderer and
FLTK backend. It's still in embryonic stage, but it can already render
lines, surfaces and patches. The big missing for the moment is text
support.

Michael.

[Daniel J Sebald]

Michael Goffioul wrote:

> On Mon, Jul 21, 2008 at 10:39 PM, Maciek Gajewski
> <maciej.gajewski0@...> 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

[Michael Goffioul-2]

On Tue, Jul 22, 2008 at 3:57 PM, Daniel J Sebald <daniel.sebald@...> wrote:
> How much of a subset will the "mid-level" parser support?  Just simple TeX
> constructs like subscript ('_'), superscript ('^'), and a few others?

Of course, we're talking here about the same set of TeX constructs that are
supported by the competition, which is only a subset of TeX syntax.

>  [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.

Indeed, and nothing prevents a backend from doing it. In a text object,
you can still get access to the text string through the "string" property.

> 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?

The competition supports currently 3 text interpreter: none, tex and latex.
The latex interpreter is a special case as the competition uses an embedded
latex engine, supporting the complete latex commands. The tex interpreter
only supports a limited subset of commands (sub/super-scripts, symbols...),
but is usually enough for common situations.

What I'm talking about here is to address the tex interpreter (the 'none'
interpreter can be viewed as a special case where no interpretation is
made).

Michael.

[John W. Eaton]

On 22-Jul-2008, Michael Goffioul wrote:

| On Tue, Jul 22, 2008 at 3:57 PM, Daniel J Sebald <daniel.sebald@...> wrote:
| > How much of a subset will the "mid-level" parser support?  Just simple TeX
| > constructs like subscript ('_'), superscript ('^'), and a few others?
|
| Of course, we're talking here about the same set of TeX constructs that are
| supported by the competition, which is only a subset of TeX syntax.

I think we should also leave open the possibility of actually passing
the text to TeX (or LaTeX) and getting a (scalable?) graphics object
back so that we can fully support TeX (or LaTeX) markup, not just some
subset.  It is probably not necessary to do this from the beginning,
but we should not make it hard to do later.

jwe

[John W. Eaton]

On 22-Jul-2008, Michael Goffioul wrote:

| On Tue, Jul 22, 2008 at 4:32 PM, John W. Eaton <jwe@...> wrote:
| > I think we should also leave open the possibility of actually passing
| > the text to TeX (or LaTeX) and getting a (scalable?) graphics object
| > back so that we can fully support TeX (or LaTeX) markup, not just some
| > subset.  It is probably not necessary to do this from the beginning,
| > but we should not make it hard to do later.
|
| Indeed. If anobody wants to consider how to interface with
| TeX/LaTeX, please do so. I personally have no idea how this
| could be done and what "information" could be obtained
| from LaTeX.

I think you could have it return a pdf file containing the label.  One
place to look for ideas about how this could work would be the
preview-latex package for Emacs.  See for example the description here
http://www.gnu.org/software/auctex/preview-latex.html and the links to
screenshots, particularly this one:
http://www.gnu.org/software/auctex/img/preview-screenshot.png

jwe

[Daniel J Sebald]

John W. Eaton wrote:

> On 22-Jul-2008, Michael Goffioul wrote:
>
> | On Tue, Jul 22, 2008 at 4:32 PM, John W. Eaton <jwe@...> wrote:
> | > I think we should also leave open the possibility of actually passing
> | > the text to TeX (or LaTeX) and getting a (scalable?) graphics object
> | > back so that we can fully support TeX (or LaTeX) markup, not just some
> | > subset.  It is probably not necessary to do this from the beginning,
> | > but we should not make it hard to do later.
> |
> | Indeed. If anobody wants to consider how to interface with
> | TeX/LaTeX, please do so. I personally have no idea how this
> | could be done and what "information" could be obtained
> | from LaTeX.
>
> I think you could have it return a pdf file containing the label.  One
> place to look for ideas about how this could work would be the
> preview-latex package for Emacs.  See for example the description here
> http://www.gnu.org/software/auctex/preview-latex.html and the links to
> screenshots, particularly this one:
> http://www.gnu.org/software/auctex/img/preview-screenshot.png

Looks good.  One thing to keep in mind is that one of the better uses combines LaTeX typesetting and PostScript graphical elements.  (That's one of the driving factors of using gnuplot and xfig.)  LaTeX's limited graphics capability is often lacking or doesn't look so good...arrows are noticeably bad.  XDVI doesn't handle this combination as well as it could, so one ends up creating a more finished product with dvips and viewing with gv.

The interesting thing about this preview-latex is that it apparently uses a style file

http://mirrors.ibiblio.org/pub/mirrors/CTAN/macros/latex/contrib/preview/preview.dtx

to isolate various sub-elements of a LaTeX document.  There is some mention of dvi and gv, so perhaps all the necessary flexibility is there.

Dan

[John Swensen]

On Jul 22, 2008, at 5:38 PM, Daniel J Sebald wrote:

> John W. Eaton wrote:
>> On 22-Jul-2008, Michael Goffioul wrote:
>> | On Tue, Jul 22, 2008 at 4:32 PM, John W. Eaton <jwe@...
>> > wrote:
>> | > I think we should also leave open the possibility of actually  
>> passing
>> | > the text to TeX (or LaTeX) and getting a (scalable?) graphics  
>> object
>> | > back so that we can fully support TeX (or LaTeX) markup, not  
>> just some
>> | > subset.  It is probably not necessary to do this from the  
>> beginning,
>> | > but we should not make it hard to do later.
>> | | Indeed. If anobody wants to consider how to interface with
>> | TeX/LaTeX, please do so. I personally have no idea how this
>> | could be done and what "information" could be obtained
>> | from LaTeX.
>> I think you could have it return a pdf file containing the label.  
>> One
>> place to look for ideas about how this could work would be the
>> preview-latex package for Emacs.  See for example the description  
>> here
>> http://www.gnu.org/software/auctex/preview-latex.html and the links  
>> to
>> screenshots, particularly this one:
>> http://www.gnu.org/software/auctex/img/preview-screenshot.png
>
> Looks good.  One thing to keep in mind is that one of the better  
> uses combines LaTeX typesetting and PostScript graphical elements.  
> (That's one of the driving factors of using gnuplot and xfig.)  
> LaTeX's limited graphics capability is often lacking or doesn't look  
> so good...arrows are noticeably bad.  XDVI doesn't handle this  
> combination as well as it could, so one ends up creating a more  
> finished product with dvips and viewing with gv.
>
> The interesting thing about this preview-latex is that it apparently  
> uses a style file
>
> http://mirrors.ibiblio.org/pub/mirrors/CTAN/macros/latex/contrib/preview/preview.dtx
>
> to isolate various sub-elements of a LaTeX document.  There is some  
> mention of dvi and gv, so perhaps all the necessary flexibility is  
> there.
>
> Dan

Another place to look might be the python matplotlib.  I know they  
support a large subset of Latex for their axes and titles, and I think  
it can either generate a PDF, PS, or even CAIRO bitmap buffers.

John Swensen