Curious behaviour of gap between ylabel and ytitle

[Eric de Souza]

I see no choice but to attach the data file which I have reduced to the minimum necessary. The description below of the problem will show why.
When I create a -graph twoway line- with the data, the inclusion of certain observations results in a huge gap between the y labels and the y title when I add -angle(horiz)-

use lqrt.dta
graph twoway line lqrt date if tin(1963q1, 1974q2), ylabel(, angle(horiz))
graph twoway line lqrt date if tin(1963q1, 1974q3), ylabel(, angle(horiz))
* problem - ytitlegap too wide
graph twoway line lqrt date if tin(1963q1, 1974q3), ylabel(, angle(horiz)) yscale(titlegap(*-40))
* yscale(titlegap(*-40)) eliminates the excessive gap
graph twoway line lqrt date if tin(1963q2, 1974q4), ylabel(, angle(horiz))
graph twoway line lqrt date if tin(1963q2, 1989q2), ylabel(, angle(horiz))

lqrt.dta

[Eric de Souza]

I should have added that the difference in the commands for each of the graphs is the time span. When I include the first observation (1963q1) AND 1974q3, AND use -angle(horiz)- the gap appears.

[Friedrich Huebler]

I can reproduce the problem and it is not limited to the observations that you mentioned. This may be a case for Stata tech support.

use lqrt.dta, clear
graph twoway line lqrt date if tin(1963q1, 1974q3), ylabel(, angle(horiz)) name(g1, replace)
set obs 109
replace date = quarterly("1962q4","YQ") in 109
replace lqrt = -.12 in 109
sort date
graph twoway line lqrt date if tin(1962q4, 1974q3), ylabel(, angle(horiz)) name(g2, replace)

[Eric de Souza]

Thanks, Friedrich, for confirmation. I will formulate the problem taking into account your comment, and then send it to tech support. Unless they see it here first.

[Daniel Gross]

I just ran into this problem as well, it's really a weird one. After toying with twoway options, and then diving into the code for Stata's base functions, I've figured out a few things that might be helpful to anyone who runs into this or other problems with graph formatting in the future.

The problem that Eric hit (the giant gap between ytitle and ylabels) seems to require two conditions: that you request horizontal ylabels (with the angle(horizontal) or angle(0) option), AND that the label format is general numeric (default format of labels is the format of the variable, and the default format for floats is %9.0g, I believe). The gap goes away if you either change the ylabel orientation to vertical OR if you change the number formatting to fixed-width. However, those seem to be necessary but not sufficient conditions, because other times I'll make a graph with these options and I won't have this issue. I don't know what's going on behind the scenes, but one conjecture is that with floating point labels and general formatting, Stata for some reason blocked out space for a 9-digit long number. But it's weird that it's inconsistent behavior.

It took a lot of digging to figure out a workaround that keeps the horizontal axis labels and general numeric formatting, and doesn't require fixed arguments like the fixed-width gap reduction Eric proposed, because Stata doesn't have any documentation on its object-oriented graphics (i.e. the kind of stuff you see here https://www.stata.com/statalist/arch.../msg00863.html), but here's one way to go:

graph twoway line lqrt date if tin(1963q1, 1974q3), ylabel(, angle(vertical))
foreach d in `.Graph.yaxis1.major.tick_values' {
  .Graph.yaxis1.edit_tick 1 `d' "`d'", custom tickset(major) editstyle(tickangle(horizontal))
}
graph display

The idea is to first make the graph with vertically-oriented ylabels. Then you retrieve a list of the major tick values and loop over them, editing each one to be horizontal. The "graph display" command then propagates these changes to the displayed graph. This is equivalent to going into graph edit mode, right-clicking the y-axis -> Axis properties -> Edit or add individual ticks or labels, and manually changing each label to horizontal orientation.

The hard part (because there's no documentation!!!) was figuring out how to programmatically retrieve the list of labels so that the code can be flexibly used. Here's a little more on how I got there, in case it might help someone in the future: I spent a chunk of time reading through some of the base code in the "C:/Program Files (x86)/Stata15/ado/base/" directory, to try to find objects that would be useful and the right syntax for working with them. Files that were helpful included:

• tick_g.class
• tickposition.class
• ticksetstyle.class
• tickstyle.class

and especially:

• axis.class
• tickset_g.class

My first choice would have been to find whatever object property was creating that gap, but I couldn't figure that out. It might be the "_tick_and_label_width" property spelled out in the axis.class file, but I'm not sure. The easiest thing seemed to be this looped approach, but that required finding where the tick values are stored and how to retrieve them. There is a "tick_values" property in the tickset_g.class file, but I couldn't find it used anywhere else, so it took some trial and error to figure out how to get its value. But the above should work.

[Eric de Souza]

Thanks, Daniel. I shall read your reply carefully this weekend; Maybe Tech Support will see it before and react.

[Jesper Bojeryd]

I can't believe this works. Such a messy solution but I am super impressed and happy I finally found it. This issue has been bothering me for a year.
I am just copy-pasting the code and put it in a separate do file I can call now after every twoway call.
Also, crazy that it hasn't been dealt with yet by Stata

[Hua Peng (StataCorp)]

Just FYI, the bug is fixed in Stata 18.