Enhancement request: Provide a public way to query the parameters' values

[EvanAad]

The intuitive parameters provided by the geometry package, such as left, and textheight, can be used to set and change the dimensions of the page and its layout elements, but cannot be queried. More accurately, the package's public interface doesn't make the values of these parameters accessible. Please enhance the package's public interface with means of querying the values of the geometry package's parameters, at least those parameters, such as left, and textheight, that accept concrete, single dimension values.

See this related TeX Stack Exchange post.

[davidcarlisle]

I'm not sure I see any use case here? LaTeX will save package options as \opt@geometry.sty and the values can be accessseed as in @u-fischer's answer on stackexchange.

The options by design allow over-specifcation: you can specfy page size and width of text and so margins are calculated, or specify margins and calculate the textblock. The actual effective values are calculated as the keys are processed and having access to original unadjusted values would seem to offer danger of confusion without real benefits, unless I am missing something?

[u-fischer]

@davidcarlisle well I don't see a use case to get the key values, but something to access the calculated values (e.g. the real "left margin", or the distance from the bottom to the footer baseline) could be nice. But perhaps this is something that should be done by the layout package so that it can be used also without geometry?

[EvanAad]

1. @u-fischer's answer makes use of internal variables, which are undocumented in the package's manual, and whose implementation should be at the discretion of the package's implementors, and should not be relied on by the package's users.
2. The names of these internal variables include the ampersand symbol, which is not, and should not, be available for casual package users.
3. Unlike the parameter names, the variable names are not intuitive, and they are not in 1:1 correspondence with the parameter names.

The whole point of the package, as I see it, and as it is explained in the manual, is to make available parameters whose names are intuitive and whose meanings are useful, and to spare the user the calculations. If the only way to access the values of these parameters is by ugly names and using intricate calculations, the entire raison d'etre of the package is undermined.

And as for use case. Suppose I wish to set the \marginparwidth to 0.8 the width of the right margin. I'd like to be able to write \setlength{\marginparwidth}{.8\right}, where \right is the (possibly calculated) value of the geomtery package's right parameter. Or perhaps

\geometryget[right]{\right}
\setlength{\marginparwidth}{.8\right}

P.S. As u-fischer wrote above, these enhancements may be a part of another package, like layout, for all I care. But regardless of the package, I think the user should be able to access these values, and I think the way of accessing them should be consistent with the way they are set in the geometry package.

[u-fischer]

The names of these internal variables include the ampersand symbol, which is not, and should not, be available for casual package users.

Well you don't have to use internal variables. At the end geometry set standard lengths like \oddsidemargin or \textwidth and so you can calculate everything from it. The internal variables only make that a bit faster.

Unlike the parameter names, the variable names are not intuitive, and they are not in 1:1 correspondence with the parameter names.

Well that reflects the fact that there is no 1:1 correspondence. "right" and "outer" and "hmargin" more or less set the same value.

I think the user should be able to access these values, and I think the way of accessing them should be consistent with the way they are set in the geometry package.

While I agree that it would be nice to have access to some layout parameters more easily: the geometry package has tons of keys where it doesn't make much sense to retrieve the value. Also what do you expect to get from "right" in a twoside document? The outer margin or the right margin (and then of which page)?

[EvanAad]

Well that reflects the fact that there is no 1:1 correspondence. "right" and "outer" and "hmargin" more or less set the same value.

Precisely, and, in my opinion, this one value should be accessible via all three of these names, for the same reasons that it is settable via all three of these names.

the geometry package has tons of keys where it doesn't make much sense to retrieve the value.

I disagree. In my opinion if it makes sense to set it, it makes sense to retrieve it, and vice versa.

what do you expect to get from "right" in a twoside document? The outer margin or the right margin (and then of which page)?

I expect "right" and "left" to have the same meanings when they are retrieved as when they are set. In the case of "left" this meaning is specified on p. 9 of the manual thus: "left margin (for oneside) or inner margin (for twoside) of total body."

[EvanAad]

I submit this implementation suggestion using pgfkeys.

[u-fischer]

I submit this implementation suggestion using pgfkeys.

As I already tried to explain I don't think that it is a good idea to bind this so heavily to geometry: If as a user I would want to retrieve layout values I wouldn't want to have to investigate first if my class or template uses geometry, or typearea, or some memoir code, or something manual.

(Apart from this: As geometry uses keyval it should add code using pgfkeys.)