Re: [Gnuplot-developers] [ gnuplot-Bugs-1194516 ] [postscript] default font override

[Hans-Bernhard B. <br...@ph...>]

Juergen Wieferink wrote:

> I looked into the postscript output file and played with the
> switches.  The problem only occurs if "Blacktext" is false.  

I think that's a red herring.

With Juergen's example modified to use

	set format x "{Symbol /p} %P"
	set xtics pi/4

I get the following PostScript output regarding strings:

--
0 setgray
newpath
(Helvetica) findfont 140 scalefont setfont
1.000 UL
LTb
--
574 280 M
Blacktext { gsave 0 setgray } if
[ [(Helvetica) 140.0 0.0 true true 0 ( 0.1)]
] -46.7 MRshow
Blacktext { grestore } if

[...]

574 4872 M
Blacktext { gsave 0 setgray } if
[ [(Helvetica) 140.0 0.0 true true 0 ( 1000)]
] -46.7 MRshow
Blacktext { grestore } if
--
658 140 M
Blacktext { gsave 0 setgray } if
[ [(Symbol) 140.0 0.0 true true 0 (p)]
[(Helvetica) 140.0 0.0 true true 0 ( 0.000000)]
] -46.7 MCshow
Blacktext { grestore } if
--

[...]

6962 140 M
Blacktext { gsave 0 setgray } if
[ [(Symbol) 140.0 0.0 true true 0 (p)]
[(Helvetica) 140.0 0.0 true true 0 ( 1.000000)]
] -46.7 MCshow
Blacktext { grestore } if
--
6311 4739 M
Blacktext { gsave 0 setgray } if
(1./sin\(x/2.\)**4) Rshow
Blacktext { grestore } if
LT0

The "Blacktext" option will indeed put gsave/grestore() pairs around
each string --- but that's just a side effect.  The real problem is that
Rshow relies on the original font (the "(Helvetica) ... findfont" in the
beginning) to still be in effect, but MFshow doesn't seem to save it
across its own invocation, nor does it re-issue a set_font to the
terminal default.

> It seems the gsave-grestore pair is missing in this case.  And
> ENHPS_put_text does not explicitly set the font.  

It shouldn't.  That's for the core to do.  It's the core that should
call term->set_font at the appropriate places.  Apparently, it doesn't
do that.

Apparently current terminal font selection tracking got broken when
enhanced text processing was ripped out of post.trm.