set key spacing ...
jan schween
a big font size for all the numbers and labels and a smaller font for
the key. Because i rescale the font in the plot command i have to change
the spacing in the key - but the position of the lines relativ to the
text in the key doesnt fit exactly. And the box is to small.
# I start with a font size in the set term command:
set terminal postscript eps enhanced "Helvetica" 24
set output 'some.eps'
# set the key spacing
# since i scale down the font by 0.5 in the title part of the plot
command
# i have to scale down the default spacing by 0.5*1.25 = 0.625
set key spacing 0.625 box
# scale down the fontsize in the key by 0.5
plot x t '{/*0.5 this is x}' ,\
x**2 t '{/*0.5 this is sqr(x)}'
# finally: close output file
set output
Hans-Bernhard Broeker
> i am using the postscript enhanced option and want to have a plot with
> a big font size for all the numbers and labels and a smaller font for
> the key. Because i rescale the font in the plot command i have to change
> the spacing in the key - but the position of the lines relativ to the
> text in the key doesnt fit exactly. And the box is to small.
Well --- there has to be _some_ point where gnuplot can no longer
manage to generate picture-perfect PostScript output without becoming
almost a full PostScript Interpreter itself. You're close to, or even
beyond that point, I think.
--
Hans-Bernhard Broeker (bro...@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
jan schween
Hans-Bernhard Broeker wrote:
> ...
> Well --- there has to be _some_ point where gnuplot can no longer
> manage to generate picture-perfect PostScript output without becoming
> almost a full PostScript Interpreter itself. You're close to, or even
> beyond that point, I think.
... ehmmmm - i am beyond :) - or not: i can suggest a solution ...
i did some further checks and found out what the problem is:
the sample lines are plotted at y = - 0.5*FS
with y the postion relative to the baseline of the text and FS the
fontsize.
that is ok if i dont change the font size.
there are two possibilities for a solution:
1: the ps-terminal driver recognises the font change while building the
key ...
or 2: the user gets an additonal variable for the key command which
adjustes FS ...
- Jan -
Hans-Bernhard Broeker
> i did some further checks and found out what the problem is:
> the sample lines are plotted at y = - 0.5*FS
> with y the postion relative to the baseline of the text and FS the
> fontsize.
Yes, and the problem is that as soon as you start modify 'set key
spacing', the key sample drawing code has absolutely no way of knowing
*why* you did that. You could be drawing 3 lines of text at half the
default font size, or one line with some exponents or indices, or
something entirely different.
The key sample could be moved to the vertical center of the space
allocated for the key entry it's assigned to.
> or 2: the user gets an additonal variable for the key command which
> adjustes FS ...
Not FS, I'd say, but directly the y position of the sample line/point
relative to the lower edge of the key text area. This could default
to 0.5 * v_font, then.
jan schween
> Not FS, I'd say, but directly the y position of the sample line/point
> relative to the lower edge of the key text area. This could default
> to 0.5 * v_font, then.
hmmm - imagine a sophisticated user who makes something like:
plot .... title '{/*0.5 Blabla_{/*0.4 subsub}}'
because he dont like the subscript size the ps-driver uses -
what ist v_font then ?
I agree it is a very complex problem -
I once wrote a simple tex-parser and realized soon that if i want
to make e.g. a fraction (\fract) i have to caclulate in advance the
width of the denominator and the nominator to determine the length of
the fraction bar - but both could also contain fractions ... so I
ended up with a recursive 'calclength' call - and the problem became
much more complex than i thought in the beginning.
- Jan -
Hans-Bernhard Broeker
> hmmm - imagine a sophisticated user who makes something like:
> plot .... title '{/*0.5 Blabla_{/*0.4 subsub}}'
> because he dont like the subscript size the ps-driver uses -
> what ist v_font then ?
Exactly. Whatever it is, it probably won't be usable for good
positioning of the key sample --- a clear example where you would have
to override that default position.
It's well-known that "do what I mean" hardly ever works in computing.
For now, you can always work around the problem: don't output the key entry
directly, but rather as a 'label', which you can position wherever you want:
set label '{/*0.5 Blabla_{/*0.4 subsub}}' at graph 0.8, 0.15
plot sin(x) title '' with lines
Adjust the position of the label to your heart's content.
jan schween
> Exactly. Whatever it is, it probably won't be usable for good
> positioning of the key sample --- a clear example where you would have
> to override that default position.
that pessimistic ?
it is possible - but hard work:
when producing the label the driver must determine the height of every
single plot-title and adjust the position of the line/point-sample
accordingly - that is difficult - but feasible.
> It's well-known that "do what I mean" hardly ever works in computing.
sometimes i sit in front of my machine, looking somewhere on the screen
and it doesn react ;)
> For now, you can always work around the problem: don't output the key entry
> directly, but rather as a 'label', which you can position wherever you want:
but then is missing the line or point sample ...
of course i can also include some arrows to point to my lines or to
produce the samples ... there is always a solution.
I just tried some size adjustment with the pslatex-driver:
reset
set terminal pslatex 12
set output 'some.tex'
set key box
set key spacing 2
plot x t 'this is x' ,\
x**2 t '{\tiny sqr(x)$=x^2$}' ,\
100./(1+(x/3.)**2) t 'and this is $\frac{100}{1+(x/3)^2}$'
set output
an include it in a Latex-file ...
there seems to be an error with the positioning of the title - try
\Large instead of \tiny ...
- Jan -
Hans-Bernhard Broeker
> it is possible - but hard work:
Harder work than anybody in the development team can afford to invest,
I think.
> when producing the label the driver must determine the height of every
> single plot-title and adjust the position of the line/point-sample
> accordingly - that is difficult - but feasible.
It's not feasible because it really is too difficult. To start with,
the gnuplot core doesn't know what the actual font height is for any
font other than the default one (for which the terminal driver is
supposed to report it). It doesn't know where in that height the
actual character baseline is (i.e. it doesn't know anything about
undershoots). It has no idea at all whether use of the '^' in
extended PS syntax changes the fontsize or not. Etc., etc.
gnuplot is not TeX, and definitely not going to become TeX.
>> For now, you can always work around the problem: don't output the key entry
>> directly, but rather as a 'label', which you can position wherever you want:
>
> but then is missing the line or point sample ...
Not if you use "title ''" instead of "notitle" as the option in the
"plot" command, IIIRC. Or maybe you have to use "title ' '" (note the
blank, to avoid having an empty string, which turns off the key
sample).
[...]
> an include it in a Latex-file ...
> there seems to be an error with the positioning of the title - try
> \Large instead of \tiny ...
For LaTeX text output, it's even more impossible than for Postscript
to second-guess where that text will actually end up, and where the
reference height should be.
jan schween
> ...
> Harder work than anybody in the development team can afford to invest,
thats the reason why i pointed out that it is hard -
we allways have to find the right way between effort and result.
And of course my problem is an exotic one - no question. It is
the question wether it is really worth to be solved from the
program-side.
> ...
> the gnuplot core doesn't know what the actual font height is for any
> font other than the default one (for which the terminal driver is
> supposed to report it). It doesn't know where in that height the
> actual character baseline is (i.e. it doesn't know anything about
> undershoots). It has no idea at all whether use of the '^' in
> extended PS syntax changes the fontsize or not. Etc., etc.
i see, i only have a vague picture about how gnuplot and the terminal
driver interact ... in my suggestion i just tried to develop an idea
how it could be done - it was just an idea.
> ...
> Not if you use "title ''" instead of "notitle" as the option in the
> "plot" command, IIIRC. Or maybe you have to use "title ' '" (note the
> blank, to avoid having an empty string, which turns off the key
> sample).
yes that works: title ' ' *with blank*
---- great that solves my original problem ;-)
> ...
> gnuplot is not TeX, and definitely not going to become TeX.
why not ... i mean gnuplot is a great program and it does a really
good job - it can plot nearly every funtion in every form i can imagine
- but if i want to write the formula for that function into the plot i
have to use the pslatex driver - sometimes it is possible with the
ps-enhanced
driver ... maybe with others. But gnuplot is a graphical Program: it can
put characters everywhere in the graph independent of the driver, well
more or less independend (i mean, i think it is able to do this) ...
I mentioned before that i once wrote a simple Tex-parser. It produced
graphical
output independent of the Metafont system by using just some few
graph-system-
calls i.e.: select font, scale font, get char width, line, and of
course:
put char at x,y
- if you are interested we could discuss the concept.
.. sorry, what means 'IIIRC' ?
- Jan -
Hans-Bernhard Broeker
>> gnuplot is not TeX, and definitely not going to become TeX.
> why not ... i mean gnuplot is a great program and it does a really
> good job - it can plot nearly every funtion in every form i can
> imagine
Yes. That's what it's good at. It's not anywhere near as good at
dealing with text, though. We're still improving things, but there's
nobody even remotely as resourceful as D.E. Knuth among us ;-)
[...]
> graphical Program: it can put characters everywhere in the graph
> independent of the driver, well more or less independend (i mean, i
> think it is able to do this) ...
Yes, but it doesn't really know what the output looks like, because it
has only a very rough idea of font metrics, which is a crucial thing
to know if you're going to do any kind of sophisticated word
processing. As soon as you use any proportionally spaced font,
gnuplot knows essentially nothing about the actual amount of space
taken up by a string you draw any more. It just positions it where it
believes the right place is, and hopes for the best.
You quite certainly could go and fake just about everything you want
to using dozens or more of 'set label' statements each giving only a
tiny fragment of the string you're trying to display. But all the
carefully chosen positions will be garbage again as soon as you change
the font or overall size of that string.
> .. sorry, what means 'IIIRC' ?
It's "IIRC", and it means "if I remember correctly" --- see the Jargon
File.
jan schween
discussion about a concept - something for a discussion group.
Hans-Bernhard Broeker wrote:
> ...
> but it doesn't really know what the output looks like, because it
> has only a very rough idea of font metrics, which is a crucial thing
> ...
> As soon as you use any proportionally spaced font, gnuplot knows
> essentially nothing about the actual amount of space taken up by a
> string you draw any more. It just positions it where it believes
> the right place is, and hopes for the best.
... that is bad.
lets try:
set key box
plot x t 'iii' , x**2 t 'xxx' , x**3 'mmm'
with the postscript driver and the Helvetica font it looks good
- but not with e.g. windows and the Arial-font, or with
the png-driver although the font is not proportional.
So if i want to include a perfect tex-parser into gnuplot i would
have to introduce a whole package with fontmetrics. I.e. a definition
how gnuplot stores fontmetrics, how the drivers transfer their
information to gnuplot and of course how the drivers know about
fontmetrics ...
Ok - that is too much !
But i dont want to give up:
A suggestion for at least an improvement would be to include a
single width list - i mean all the (ASCII)-characters in the
different proportional fonts have about the same relative width.
The width of 'M' compared to the width of e.g. 'i' is similar in
every proportional font. What is additional needed is an aspect
ratio to relate these width-table to the font size.
(i remember in LaTeX is a variable for horizontal space called
\quad like quadrat - it is the width of an 'x' which has usually
the same height as width)
The maximal height above the baseline and the maximal
extension below the baseline can be approximated as certain
fractions of the font size (font size ist the sum of both and
- as i remember - an additonal vertical space).
I still believe that a tex-parser is feasibel.
- Jan -
Hans-Bernhard Broeker
> tell me if i am going too far - this becomes more and more a
> discussion about a concept - something for a discussion group.
It might inded be time to move this over to the developers' mailing
list or private email.
[...]
> A suggestion for at least an improvement would be to include a
> single width list - i mean all the (ASCII)-characters in the
> different proportional fonts have about the same relative width.
Even then, output processors that know about kerning and ligatures
could still wreak havoc to the results. The only fully correct method
would be to strictly require that any driver supporting proportional
fonts has to implement a new terminal API function get_string_size()
that returns the exact output size of a given string in terminal
pixels, using the current font and size. OTOH, implementing this
query for PostScript or TeX driver would be quite impossible without
re-inventing most of GhostScript and TeX (and distributing font metric
files for all allowed fonts with gnuplot --- bah!).
Ethan Merritt
jan schween <_jan.s...@lrz.uni-muenchen.de_> wrote:
>tell me if i am going too far - this becomes more and more a
>discussion about a concept - something for a discussion group.
>
>
>Hans-Bernhard Broeker wrote:
>> ...
>> but it doesn't really know what the output looks like, because it
>> has only a very rough idea of font metrics, which is a crucial thing
>> ...
>> As soon as you use any proportionally spaced font, gnuplot knows
>> essentially nothing about the actual amount of space taken up by a
>> string you draw any more. It just positions it where it believes
>> the right place is, and hopes for the best.
>
>... that is bad.
>
>lets try:
>
>set key box
>plot x t 'iii' , x**2 t 'xxx' , x**3 'mmm'
>
>with the postscript driver and the Helvetica font it looks good
>- but not with e.g. windows and the Arial-font, or with
>the png-driver although the font is not proportional.
The new png driver knows about font metrics (which is to say
that it is built on top of libgd and freetype, which know about
font metrics). Centering and left/right justification should
work fine. I have toyed with the idea of adding either the
"enhanced postscript" text processing options or a subset of
latex character processing. The main headache is that the
gnuplot terminal driver text processing routines would have
to become recursive.
>So if i want to include a perfect tex-parser into gnuplot i would
>have to introduce a whole package with fontmetrics. I.e. a definition
>how gnuplot stores fontmetrics, how the drivers transfer their
>information to gnuplot and of course how the drivers know about
>fontmetrics ...
It's called libfreetype :-)
--
Ethan A Merritt
Hans-Bernhard Broeker
> that it is built on top of libgd and freetype, which know about
> font metrics). Centering and left/right justification should
> work fine.
Right. But due to design limitations of the terminal driver interface
used by gnuplot, that's about as far as you can go. No correct
perfect alignment of multi-line texts, no correct clipping by the
gnuplot kernel, because it can only ask the driver about the average
size of a character, but not the exact size of a given string.
Some drivers add their own 'hard' clipping, i.e. they refuse to draw
even a single character of a long line of text if any part of it would
be outside the viewport. IIRC, the libgd driver shows this behaviour.
jan schween
Hans-Bernhard Broeker wrote:
> ... no correct clipping by the
> gnuplot kernel, because it can only ask the driver about the average
> size of a character, but not the exact size of a given string.
so that is where one could start an improvement:
the simpler way:
the relative character widths do not change more than 20% from font to
font. So one could compile an proportional-font-average-withtable.
gnuplot must know whether the current font is proportional or not and
'ask' for the average char width, caluclate the char widths and sum them
up to the stringwidth.
or the more sophisitcated way:
define two new interfacial functions between the driver and gnuplot wich
give textwidth and textheight ... and let the drivers do the work.
Ethan Merritt wrote:
> ...
> I have toyed with the idea of adding either the
> "enhanced postscript" text processing options or a subset of
> latex character processing. The main headache is that the
> gnuplot terminal driver text processing routines would have
> to become recursive.
why make recursive routines a headache ?-)
- Jan -