Unwanted x-y-offset in Postscript landscape

  • Follow


Hi all,

I want to adjust the margins in a landscape-type postscript plot. 
However, wenn setting e.g.

set term postscript landscape size 29.7cm,21cm

(for A4 paper) and

set lmargin screen 0.05;set rmargin screen 0.95
set bmargin screen 0.05;set tmargin screen 0.95

or adjusting the canvas via the "size" variable in the terminal 
definition, there is always a nasty offset of about 2-3 cm in both right 
and downwards (i.e. part of the plot may be off-screen!). Re-adjustment 
by "set origin" does not yield the wanted result but also sometimes 
downscales the whole plot.

I remember vaguely that there is sometimes a 1-inch x-y offset in 
Postscript, but for some reason I do not find anything about this via 
Google.

Is there a way to circumvent the offset, so that the above margin 
settings will give *exactly* a 5% margin between the paper rim and the 
plot? Or will I have to use LaTeX (since it provides easy scaling with 
its \includegraphics command) or play around manually with the BB to do 
this?

BTW fixbb doesn't work here since it is not an EPS (and, 
non-surprisingly, there is no change after using fixbb).

Ingo
0
Reply ingo.thies (51) 4/17/2010 4:48:04 PM

Ingo Thies wrote:

> set term postscript landscape size 29.7cm,21cm
> (for A4 paper) and 
> set lmargin screen 0.05;set rmargin screen 0.95
> set bmargin screen 0.05;set tmargin screen 0.95
> 
> there is always a nasty offset of about 2-3 cm in both right 
> and downwards (i.e. part of the plot may be off-screen!). 

When I use these commands in gnuplot 4.4.0 I get a PostScript 
file containing

%%BoundingBox: 50 50 645 891
%%Orientation: Landscape

This specifies an offset of 50pts (1.76 cm) from the corner
of the paper.  Does your output file contain something else?
Is it possible that the extra margin is being added by your printer?

0
Reply sfeam 4/17/2010 5:41:53 PM


Am 2010-04-17 19:41, schrieb sfeam:

> When I use these commands in gnuplot 4.4.0 I get a PostScript
> file containing
>
> %%BoundingBox: 50 50 645 891
> %%Orientation: Landscape

Mine too. However, even if I change the BB, this does not have any 
visible effect (maybe since it is not an EPS). Especially, the upper and 
left border seem to be an ultra-hard limit that can neither be shifted 
by setting the BB, nor by specifying the margins or the origin inside 
the gnuplot script. In particular, if I shift the origin to the left, 
then only the right margin is moved, but the left is frozen, resulting 
in a sqeezed plot.

Currently, I feel forced to circumvent the problem by using EPS instead 
and loading them into a dummy.tex.

My purpose is simply to print a plot as large as reasonably possible to 
use it as a look-up graph (rather than just for illustration where large 
margins may be more typographically correct).

> This specifies an offset of 50pts (1.76 cm) from the corner
> of the paper.  Does your output file contain something else?
> Is it possible that the extra margin is being added by your printer?

I didn't print yet, I am just viewing it in gv.

Again, I do vaguely remember that there is a 1-inch offset in standard 
Postscript that comes into effect sometimes and sometimes not. But I do 
not remember in which cases it comes into effect and why it had been 
introduced by the creators of the Postscript language. I guess there was 
some technical reason for this, but none that would be solved by this in 
my case, but instead the problem is introduced by it.

Please try this dummy script to illustrate the problem. Here, the border 
of the plot (after the tic labels have been removed) should just fit 
into the canvas of an A4 paper. But instead the plot is shifted down and 
to the right if viewed with gv. The offset remains after converting to 
PDF via ps2pdf.

set term postscript landscape size 29.7cm,21cm
set output 'test.ps'
set lmargin screen 0;set rmargin screen 1
set bmargin screen 0;set tmargin screen 1
set format x "";set format y ""
plot sin(x) w l


Ingo
0
Reply Ingo 4/17/2010 9:33:25 PM

Hi!

Ingo Thies wrote:

> Please try this dummy script to illustrate the problem. Here, the border
> of the plot (after the tic labels have been removed) should just fit
> into the canvas of an A4 paper. But instead the plot is shifted down and
> to the right if viewed with gv. The offset remains after converting to
> PDF via ps2pdf.
> 
> set term postscript landscape size 29.7cm,21cm
> set output 'test.ps'
> set lmargin screen 0;set rmargin screen 1
> set bmargin screen 0;set tmargin screen 1
> set format x "";set format y ""
> plot sin(x) w l


Strange... I tried with gnuplot 4.2 patchlevel 6, however, added "set
output" after the plot command.

When I view the ps file with Okular, everything seems to be fine, the
borders are on the outline of the canvas, where you'd expect them.
However, if I convert it with ps2pdf, I get the shifted version which
you are describing...


Stefan
0
Reply Stefan 4/17/2010 11:39:29 PM

Ingo Thies wrote:

> Am 2010-04-17 19:41, schrieb sfeam:
> 
>> When I use these commands in gnuplot 4.4.0 I get a PostScript
>> file containing
>>
>> %%BoundingBox: 50 50 645 891
>> %%Orientation: Landscape
> 
> Mine too. However, even if I change the BB, this does not have any
> visible effect (maybe since it is not an EPS). Especially, the upper
> and left border seem to be an ultra-hard limit that can neither be
> shifted by setting the BB, nor by specifying the margins or the origin
> inside the gnuplot script. In particular, if I shift the origin to the
> left, then only the right margin is moved, but the left is frozen,
> resulting in a sqeezed plot.
> 
> Currently, I feel forced to circumvent the problem by using EPS
> instead and loading them into a dummy.tex.
> 
> My purpose is simply to print a plot as large as reasonably possible
> to use it as a look-up graph (rather than just for illustration where
> large margins may be more typographically correct).
> 
>> This specifies an offset of 50pts (1.76 cm) from the corner
>> of the paper.  Does your output file contain something else?
>> Is it possible that the extra margin is being added by your printer?
> 
> I didn't print yet, I am just viewing it in gv.

I can't explain it, but I can provide a work-around.
No promises how it may interact with a specific printer, though.

In the file that is installed by default in 
/usr/local/share/gnuplot/${VERSION}/PostScript/prologue.ps 
the last bit of the file reads:

 /Symbol-Oblique /Symbol findfont [1 0 .167 1 0 0] makefont
 dup length dict begin {1 index /FID eq {pop pop} {def} ifelse} forall
 currentdict end definefont pop

Add one additional line at the end of this file to locally customize it:
 -50 -50 translate

The locally-customized version will be included as part of the output
files produced by gnuplot. You do not have to recompile or reinstall
gnuplot for this to take effect.

> Please try this dummy script to illustrate the problem. Here, the
> border of the plot (after the tic labels have been removed) should
> just fit into the canvas of an A4 paper. But instead the plot is
> shifted down and to the right if viewed with gv.

I do see that in gv, but only if I force it to the A4 paper setting.
By default it uses the BoundingBox setting and displays correctly.
Conversely, the local customization I show above makes the A4 setting
correct but breaks the BoundingBox.

	Ethan
0
Reply sfeam 4/17/2010 11:52:07 PM

Am 2010-04-18 01:52, schrieb sfeam:

> I can't explain it, but I can provide a work-around.
> No promises how it may interact with a specific printer, though.
>
> In the file that is installed by default in
> /usr/local/share/gnuplot/${VERSION}/PostScript/prologue.ps
> the last bit of the file reads:
>
>   /Symbol-Oblique /Symbol findfont [1 0 .167 1 0 0] makefont
>   dup length dict begin {1 index /FID eq {pop pop} {def} ifelse} forall
>   currentdict end definefont pop
>
> Add one additional line at the end of this file to locally customize it:
>   -50 -50 translate

Ah, thanks, it seems to work for gv as well as for ps2pdf.

> I do see that in gv, but only if I force it to the A4 paper setting.
> By default it uses the BoundingBox setting and displays correctly.
> Conversely, the local customization I show above makes the A4 setting
> correct but breaks the BoundingBox.

Hmm, maybe the default BB leaves enough space to this "postscript event 
horizon" so that the problem does not appear. This would explain why 
even the set origin command fails as if the whole plot is squeezed by 
forcing it against this invisible wall.

I vaguely remember that there is an extra LaTeX command to remove this 
offset, but it's long ago I encountered the problem there. Furthermore, 
in Gnuplot there is no such problem with EPS (but EPS requires 
postprocessing by e.g. TeX to fit well into the paper area).

Ingo
0
Reply Ingo 4/18/2010 11:45:20 AM

Am 2010-04-18 01:52, schrieb sfeam:

> Add one additional line at the end of this file to locally customize it:
>   -50 -50 translate

Additional info: Better put this in the according PS file only since it 
otherwise alters the output of all Postscript plots (including EPS), 
since, as you have mentioned, the BB is somewhat broken. Maybe I should 
write an awk script to insert this line in at the appropriate position.

Ingo
0
Reply Ingo 4/18/2010 11:52:48 AM

> > Add one additional line at the end of this file to locally customize it:
> >   -50 -50 translate
> 
> Additional info: Better put this in the according PS file only since it
> otherwise alters the output of all Postscript plots (including EPS), since, as
> you have mentioned, the BB is somewhat broken. Maybe I should write an awk
> script to insert this line in at the appropriate position.

First, Bounding Box is a description of the postscript file contents, i.e. 
it does not move or change anything.

You can change the offset on-fly in gnuplot by means of:
  set output '|sed "s/^50 50 translate$/0 0 translate/" >out.ps'

Or, you can use the program
	pstops
which allows to arbitrarily shift, scale, rotate, ... pages in postscript 
files.

---
Petr Mikulik
0
Reply Petr 4/19/2010 10:49:16 AM

7 Replies
500 Views

(page loaded in 0.242 seconds)

Similiar Articles:





7/30/2012 10:37:03 AM


Reply: