Please have a look at the following graph:
45° -> http://mypic.thmdesign.at/show.php?pic=06082008090800.png
As you can see on the screenshot, the xtics are not well readable. Eg.
the 1st xtic "17.07.08" - it's not quite clear, that it corresponds to the first
major tic line. It would be better, if the "08" from "17.07.08" would be right
at that line.
If the xtic label is "simply" rotated (ie. by 90 degrees), the alignment
is very well: http://mypic.thmdesign.at/show.php?pic=06082008090907.png
But please also have a look at what happens at "rotate by 89" or "rotate
by 91":
89° -> http://mypic.thmdesign.at/show.php?pic=06082008090910.png
91° -> http://mypic.thmdesign.at/show.php?pic=06082008090914.png
That doesn't look right to me - or is it right? As you can see, the label
goes into the graph and thus only "17.0" is readable - "7.08" is not
readable.
There are two questions:
1) How do I align the xtic labels in the 45° image so, that the end of the
text is at the tic mark?
2) 89° & 91°: Is that wanted, or is it a bug I should report?
Here are the gnuplot commands I used to generate the graph:
set xdata time
set format x "%d.%m.%y"
set datafile separator ","
set yrange [0:*]
set y2range [0:*]
set xlabel "Date"
set y2tics
set ytics nomirror
set timefmt "%d.%m.%Y %H:%M"
set xrange [ "16.07.2008 00:00" : * ]
set ylabel "Average\nms"
set y2label "# Peaks"
set grid
set yrange [100:12500]
set logscale y
set key autotitle columnheader enhanced
set xtics nomirror out rotate by 45 offset 0,graph -0.05 scale 2
set term svg size 620,400 dynamic enhanced
set output 'gnuplot, text rotated 45deg.svg'
plot "06.08.08_08:10:00.csv" using 1:($17 > 10000 ? 1/0 : $17) axes x1y1 with linespoints lw 2, \
"" using 1:18 axes x1y2 with lines lw 1, \
"" using 1:19 axes x1y2 with lines lw 1, \
"" using 1:20 axes x1y2 with lines lw 1, \
"" using 1:21 axes x1y2 with lines lw 1
unset output
I thus created a SVG file and converted it for the upload with
ImageMagick to PNG.
Thanks,
Michael
By default all text is left-justified.
Text rotation ( "text label" rotate by <degrees> ) is done about
the justification point.
So it appears that you either want to specify right justification
set xtics right rotate by 45
Or else use the default left-justification but rotate in the other direction
set xtics rotate by -45
--
Ethan A Merritt
Hi Ethan,
that does not seem to address the apparent discontinuity between 89,
90 and 91.
from the plots he links to, it seems that there is an exception in
handling 90 so that either it is right justified or does not use the
justification point for alignment.
Is that a correct interpretation?
Thanks.
This is the curse of gnuplot's "backward compatibility is supreme" policy.
Prior to gnuplot 3.8j (I think) you could not do general rotation of text
strings. There was a keyword "rotate" for the axis tics that had the
affect of setting the text orientation to vertical, rather than horizontal,
on a small number of terminals that supported such a thing. It was up
to the terminal hardware exactly what that looked like on the page.
In 3.8j (or whatever) general text rotation of the form
"rotate by <degrees>"
was added. The rotation convention was the usual mathematical one of
counter-clockwise rotation from 0=positive-x-axis. However, for backwards
compatibility, the bare string "rotate" was special-cased to mean
"rotate by 270" with right-justified text. This matched what the PostScript
terminal was doing at the time.
But I don't recall if it was intentional that "rotate by 90" would trigger that
same special case. Arguably this makes some sense, and what normal use-case
is there for writing the labels at 89 or 91 degrees?
>Is that a correct interpretation?
It seems I am wrong about being able to explicitly ask for left- or right-
justification of axis tic labels. The underlying code could handle it, but
I don't see any way of making the request from the command line.
--
Ethan A Merritt
Thanks , that was pretty much what I guessed to be the case but there
seemed little point in speculating.
Clearly 89 and 91 were only used to clarify the nature of the effect
but since per degree setting is a feature the issue is quite real,
prefer 45 or 60, the glitch is still there.
Accepting `rotate` command is retained "as is" for backwards compat ,
it seems that there is a bug in `rotate by`. I would expect this to
work mathematically , without jumping around for special cases.
It seems you have pinpointed a short-coming in that text justification
cannot be specified. If it is to be argued that the 'rotate by' bug is
to be retained for similar reasons maybe this could be fixed by a new
specifier to specifically determine the justification and which would
be exempt from the implicit flipping over.
Indeed it would seem that any rotation from 45 to 135 would be
difficult to use controllably without such a feature since pre-
calculating text size of an automatic label in order to fix an offset
seems difficult if not impossible. It could only be done by trail and
error on specific data.
In addition , my experience with rotated labels (-45) gave less than
optimum results because of the point about which the rotated text is
aligned. It was unclear to which tick mark the label was supposed to
be attached.
It seems everthing is referenced to the lower left corner of the
including rectangle , which gives less than ideal positioning for a
range of negative rotations. What would be preferable (rather than
more special case coding exceptions ) is something like:
rotate by 60 justify right
rotate by -45 attach TL
Do those enhancements make sense to you?
regards.