Hi,

I have just found a strange behavior (to avoid the more explicit word 
"bug" ;-)) when using rotate font in labels an terminal Postscript 
enhanced (even if no enhanced fonts are actually used). When setting 
multiplot after defining a global label with rotate font and "front", 
the tic labels disappear after the first subframe. With "front" or the 
rotate stuff alone, the behavior is normal, as well if the font 
specification is skipped.

This behaviour must have occurred in one of the CVS versions between 
February 16 and April 5 since it doesn't occur with a version I had 
built on Feb 16. Here is a sample script:


set term postscript eps color enhanced size 16.cm, 20.cm "Helvetica" 36
set output "test.eps"
set xrange [-5:+5]
set yrange [0:10]
unset key
#########################
### The keyword "front" in combination with "rotate font <font>"
### in the label 1 definition triggers the problem

set label 1 'x = 0' at 0,5 front rotate font "Helvetica, 30"
#set label 1 'x = 0' at 0,5 front rotate
#set label 1 'x = 0' at 0,5 rotate font "Helvetica, 30"

### With both rotate font and front the tic labels disappear
### after the first plot.
#########################
set multiplot
set lmargin screen 0.19; set rmargin screen 0.99
set bmargin screen 0.69; set tmargin screen 0.99
plot 2.*x w l
set bmargin screen 0.39; set tmargin screen 0.69
plot 0.4*x**2 w l
set bmargin screen 0.09; set tmargin screen 0.39
plot 5.*sin(x)+5.
unset multiplot


Ingo

I wrote:

> the tic labels disappear after the first subframe. With "front" or the 
> rotate stuff alone, the behavior is normal, as well if the font 
> specification is skipped.

Addition: In a much more complex script where the problem occurred 
first, the bug also occurs without the "front" statement, but disappears 
if the font specification (which is used there for adjusting the font 
size) is removed.

Ingo

Ingo Thies wrote:

> Hi,
> 
> I have just found a strange behavior (to avoid the more explicit word
> "bug" ;-)) when using rotate font in labels an terminal Postscript
> enhanced (even if no enhanced fonts are actually used). When setting
> multiplot after defining a global label with rotate font and "front",
> the tic labels disappear after the first subframe. With "front" or the
> rotate stuff alone, the behavior is normal, as well if the font
> specification is skipped.
> 
> This behaviour must have occurred in one of the CVS versions between
> February 16 and April 5 since it doesn't occur with a version I had
> built on Feb 16. Here is a sample script:

The good news is that by peering at recent code changes I found a typo:
the character spacing unit was multiplied by the fontsize*fontsize
rather than fontsize*fontscale. This clearly can affect character placement
of rotated text, and correcting the typo makes your test case work properly.

The bad news is that I can't see why the typo has any connection at all
to the "front" option, so a separate problem may be hiding somewhere.

	Ethan

> 
> set term postscript eps color enhanced size 16.cm, 20.cm "Helvetica" 36
> set output "test.eps"
> set xrange [-5:+5]
> set yrange [0:10]
> unset key
> #########################
> ### The keyword "front" in combination with "rotate font <font>"
> ### in the label 1 definition triggers the problem
> 
> set label 1 'x = 0' at 0,5 front rotate font "Helvetica, 30"
> #set label 1 'x = 0' at 0,5 front rotate
> #set label 1 'x = 0' at 0,5 rotate font "Helvetica, 30"
> 
> ### With both rotate font and front the tic labels disappear
> ### after the first plot.
> #########################
> set multiplot
> set lmargin screen 0.19; set rmargin screen 0.99
> set bmargin screen 0.69; set tmargin screen 0.99
> plot 2.*x w l
> set bmargin screen 0.39; set tmargin screen 0.69
> plot 0.4*x**2 w l
> set bmargin screen 0.09; set tmargin screen 0.39
> plot 5.*sin(x)+5.
> unset multiplot
> 
> 
> Ingo

sfeam wrote:

> The good news is that by peering at recent code changes I found a typo:
> the character spacing unit was multiplied by the fontsize*fontsize
> rather than fontsize*fontscale. This clearly can affect character placement
> of rotated text, and correcting the typo makes your test case work properly.
> 
> The bad news is that I can't see why the typo has any connection at all
> to the "front" option, so a separate problem may be hiding somewhere.

As I wrote in the second posting, "front" does make an effect sometimes 
and sometimes not. Maybe the typo you've found had triggered some 
propagating error which was then triggered in the sample script by the 
"front" option. We'll have to see whether it works now with more complex 
scripts.

Just tested with the more complex script: No more problems (even with 
"front" which is needed there to keep a label readable in front of 
filled curves used in that script), thanks!

Ingo