page.center is not at page center.

[olsak]

I was tried the example from page 262 from TikZ manual where the circle should be (after second TeX run) at page center. When the \hoffset is non-zero then it seems that the circle is not at page center. Example:

\input tikz

\hoffset=1in
\advance\hsize by-2.5in

\tikzpicture [remember picture,overlay]
\draw [line width=1mm,opacity=.25]
(current page.center) circle (3cm);
\endtikzpicture

\bye

Use pdftex or luatex to compile this example.

[muzimuzhi]

Duplicate of #294. A workaround for LaTeX format can be found in https://github.com/pgf-tikz/pgf/issues/294#issuecomment-478804370. I tried to fix it months ago but only found myself having too limited knowledge about plainTeX and ConTeXt to come up with a portable solution.

[olsak]

Please, re-open this issue. The position of page.center is totally wrong if its calculation depends on \voffset, \hoffset. The calcuation is based on \lastxpos \lastypos of \savepos of current point (from previous TeX run) and we want to find the vector from current point to the page center. The \lastxpos values are saved as value from page corner to the current point. The page center is at the postion \pdfpagewidth/2 from page corner. So, we have to calculate \pdfpagewidth/2-\lastxpos, nothing more. And analogical in vertical position.

[ilayn]

Yes that is exactly what the problem is in the linked issue. The reason for the closing is not to ignore this but to track it from a single source. Sorry if that didn't come out correctly.

[olsak]

But the linked issue is seven years not solved. And the discussion here is off topic of the core problem: not to use \hoffset and \hoffset for calculation.

[ilayn]

yes it is still open unfortunately. The solution should apply to all formats simultaneously.

[muzimuzhi]

Actually there are two types of "page sizes":

• the logical size (\hsize * \vsize in plainTeX and \paperheight * \paperwidth in LaTeX) and
• the physical size (i.e. the size of pdf page).

The last sentence of https://github.com/pgf-tikz/pgf/issues/294#issuecomment-478804370 had mentioned the differences as well, maybe implicitly.

Here is the problem: Logical size is always accessible (and is the aimed size and position of node current page), but the physical size is not even known (or "not always known"? not sure) in dvi mode. For example, whether set or not, in dvi mode pdftex will not use \pdfpage(height|width).

@olsak It seems to me that you want the center of logical page. Then I'm afraid currently some manual coordinate calculations like ($(current page.center) + ... $) is needed, with the mentioned workaround applied. And I'm willing to provide help for your specific combination of engine + format (+ compilation chain), here or on tex.stackexchange.com.

[olsak]

Yes, I know the problem about missing information about \pdfpagewidth in dvi mode. Simply, page.center or page.east has no sense in dvi mode because we don't know \pdfpagewidth, the physical size of the page. But in PDF mode page.center, page.east have sense and it would be implemented correctly. It means without \hoffset, \voffset dependencies. No, I don't center logical page, I am sayin ony about physical page and about the example from page 262 of TikZ manuale which can be implemeted corretly in non-DVI mode and wich has no sense in DVI mode. My suggestion of the correction is: pfg/systemlayer/pgfsys-pdftex.def: replace

\def\pgf@sys@pdf@mark@pos@pgfpageorigin{\pgfqpoint{\hoffset}{\voffset}}
to
\def\pgf@sys@pdf@mark@pos@pgfpageorigin{\pgfqpoint{0pt}{0pt}}

in pfg/systemlayer/pgfsys-luatex.def: do the same. in pfg/systemlayer/pgfsys-xetex.def you can do everything but nothing should be correct because you have no sufficient input data.

[muzimuzhi]

It seems to me that you want the center of logical page.

My fault. I meant "physical page".

Your suggestion will break the backward compatibility, see for example https://github.com/pgf-tikz/pgf/issues/294#issuecomment-478804362. Perhaps in pdf mode, what you need is a new node current physical page.

[olsak]

Please, be more clear and give an exact MWE example what "backwad compatibility" is broken. Now, the compatiblity with the manual page 262 is broken and this is more important and fatal IMHO.

[olsak]

If somebody needs a depenedency of the position of the result on \hoffset, \voffset then he can write ($(current page.center) + ... $).

[hmenke]

Fixing #294 would reopen #85 and since Till chose to fix #85 in cdacb877e0dd2cefb2a5e1681ede483e4e5f16a8, I'm going to leave it at that.

[olsak]

The commit cdacb87 is buggy commit. The manual at page 261 says: It is the node of shape rectangle whose west anchor is left corner of the page. But is it not true:

\input tikz
\hoffset=1cm

\tikzpicture [remember picture,overlay]
\draw [line width=1mm,opacity=.25]
(current page.west) circle (3cm);
\endtikzpicture

\bye

You can correct the manual: "It is the node of shape rectangle whose west anchor is left corner of the page shifted by \hoffset due to buggy fix" or you can simply fix this bug refferred here.

[olsak]

Note that when users are using OpTeX then this bug is much more visible because \hoffset is equal to left margin not "left margin minus 1in". Maybe in another plain TeX document, it is less visible because \hoffset is often almost zero.

[muzimuzhi]

In normal (and most) cases, users do expect current page to be the physical page. But with specific packages, for example crop, the expected current page becomes the logical page (hence the fix for #85). In general, when \[hv]offset is non-zero, it's almost impossible for pgf to know which kind of page sizes is the expected one.

Since the y-coordinate of reference points in TeX and in PDF are different, this part of #294 should be fixed. But since your need is to have an always-physical-page node ... perhaps OpTeX has to have some compatibility lines for pgf.

[olsak]

This is not only OpTeX problem: when plain TeX sets \hoffset, \voffset to different sizes than default then the bug is shown. When a user sets \hoffset, \voffset different from zero in LaTeX document manually (i.e. not in output routine), then the bug is shown. I call bug: there is difference behavior than written in TikZ manual. Please, correct this bug. We cannot do patches to the bug using obscure code in another formats. And I repeat again: give a MWE please where the correction suggested by me above does not work.

[ilayn]

There is a moot point here. We should simply change the manual to reflect this point. Because this is not fixable for all formats. And there is almost a decade of usage out there to not to be broken. So we can't simply modify this.

I wish people stopped using DVI mode anyways because why would you in 2020 but that's a hill I don't want to die on. Unless that day comes or dvi mode actually changes behavior we cannot break people's docs. But indeed this should be mentioned in the docs. Then people can reintroduce the offsets of their liking to the node anchor coordinates which is the actual problem. Detecting page size is a different monster

[olsak]

If I understand well, you insist to the current state because of a latex package crop.sty. (I still waiting for MWE.) The crurrent page position calculation was broken by commit #88 in 2013 because of this LaTeX package. When \hoffset, \voffset is non zero, then the current page position is shifted from since this commit. LaTeX kernel sets \hoffset, \voffset to zero and it resets them locally in its output routine only (if latex packages for margins are used). So, LaTeX documents are typically OK (if uses does not set \hoffset explicitly). But plain TeX users (and users of formats derived from plain TeX) read in the TeXbook, that \hoffset, \voffset shifits the typesetting area and they are using such settings of these registers commonly. Whenever they do such a setting, the Tikz breaks the feature about current page described in its manual. This was not seven years reported because only few users use plain TeX (unfortunately). But Tikz manual says that plain TeX is supported. It means that the feature about current page should be supported too.

You can insert these lines after the \pgf@sys@pdf@mark@pos@pgfpageorigin definition into the files pgfsys-pdftex.def and pgfsys-luatex.def:

\ifpgfutil@format@is@plain
   \def\pgf@sys@pdf@mark@pos@pgfpageorigin{\pgfqpoint{0pt}{0pt}}
\fi

Now, plain TeX users will be happy and LaTeX users do not notice any change.

[muzimuzhi]

You can insert these lines after the \pgf@sys@pdf@mark@pos@pgfpageorigin definition into the files pgfsys-pdftex.def and pgfsys-luatex.def:

\ifpgfutil@format@is@plain
   \def\pgf@sys@pdf@mark@pos@pgfpageorigin{\pgfqpoint{0pt}{0pt}}
\fi

Now, plain TeX users will be happy and LaTeX users do not notice any change.

@olsak I think your proposal for plaintex is right. Currently, with pdftex + plaintex,

• the page origin (\pgf@sys@pdf@mark@pos@pgfpageorigin) is \pgfqpoint{\hoffset}{\voffset} and
• the page size (\pgfsys@thepagewidth x \pgfsys@thepageheight) is \pdfpagewidth x \pdfpageheight, which are mismatching hence need a fix.

And here is a LeTeX example which requires the page origin not being \pgfpointorigin (a shorthand for \pgfqpoint{0pt}{0pt}).

\documentclass{article}
\usepackage{lipsum}
\usepackage[pass, showframe]{geometry}

\usepackage[cam,center,width=250mm,height=337mm]{crop}
\usepackage{tikz}

\begin{document}
\tikz[overlay, remember picture]
  \draw[blue, line width=10pt] 
    (current page.north east) rectangle (current page.south west);
\lipsum[1-5]
\end{document}

[hmenke]

Could you please discuss this under #294 instead of the closed duplicate?

[olsak]

@muzimuzhi Thank you for the example. I see that there was very bad decision in 2013 because two different features (primitive feture and feature needed by crop.sty) were merged to single control sequence (\hoffset, resp. \voffset). Much more clear is to add something like this to the manual, page 262 (the sentence added to the end of 17.13.2): "The rectangle given by current page can be shifted right by \hpgoffset and down by \vpgoffset. These registers are zero by default, but crop.sty package (for example) can use them." And implemt this. And do \hpgoffset=\hoffset \vpgoffset=\voffset in the crop.sty package.

[olsak]

@hmenke I can move to different issue number if this increases the chance of correcting this bug. This is not explicitly my interest (because I know how to work around it) but it is interest of all plain TeX users and of the TikZ itself (in order to do it more conceptual and less buggy).

[hmenke]

Hm, I've closed #294 instead, because there is more activity here. Now #294 is marked as duplicate of #983 instead of the other way around.