Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Position of rotated xtic labels

1,835 views
Skip to first unread message

Michael Schmarck

unread,
Aug 6, 2008, 3:15:38 AM8/6/08
to
Hello.

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

mer...@chauvet.bmsc.washington.edu

unread,
Aug 6, 2008, 11:59:11 AM8/6/08
to
In article <6ft1csF...@mid.individual.net>,

Michael Schmarck <usenet-...@schmarck.cn> wrote:
>Hello.
>
>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.

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

goo...@catking.net

unread,
Aug 7, 2008, 7:04:00 PM8/7/08
to
On Aug 6, 5:59 pm, merr...@chauvet.bmsc.washington.edu wrote:
> In article <6ft1csFd2v2...@mid.individual.net>,

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.


mer...@chauvet.bmsc.washington.edu

unread,
Aug 7, 2008, 7:35:17 PM8/7/08
to
In article <8482694f-5ffc-4bf6...@m45g2000hsb.googlegroups.com>,

<goo...@catking.net> wrote:
>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.

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

goo...@catking.net

unread,
Aug 8, 2008, 10:55:06 AM8/8/08
to
On Aug 8, 1:35 am, merr...@chauvet.bmsc.washington.edu wrote:
> In article <8482694f-5ffc-4bf6-9729-1b19218fc...@m45g2000hsb.googlegroups.com>,

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.

0 new messages