Extra horizontal space with forest and standalone pacakage

Question

I created some style files for standalone pictures. However, I get unwanted horizontal space.

Here is my first MWE1:

\documentclass[convert={true,convertexe={magick.exe},
   command=\unexpanded{{\convertexe\space -density \density\space \infile\space \ifx\size\empty\else -resize \size\fi\space \outfile}}}]{standalone}

\RequirePackage{forest}

\begin{document}

\begin{forest}
[ 2 [1] [3]]
\end{forest}

\end{document}

The result is:

However, I want to change my transparent background. Here is MWE2:

\documentclass[convert={true,convertexe={magick.exe},
   command=\unexpanded{{\convertexe\space -density \density\space \infile\space \ifx\size\empty\else -resize \size\fi\space -transparent white'rgb(100,200,100)' \outfile}}}]{standalone}

\RequirePackage{forest}
\RequirePackage{xcolor}

\begin{document}

\definecolor{tr}{RGB}{100,200,100}
\pagecolor{tr}

\begin{forest}
[ 2 [1] [3]]
\end{forest}

\end{document}

The result is:

Notice the extra horizontal space before the tree. This is just a MWE, so it is not a lot. However, with bigger trees, the space gets bigger:

Does anyone have an idea to get rid of this?

Welcome! Add percentage signs: \definecolor{tr}{RGB}{100,200,100}% and \pagecolor{tr}%. You may also just move \begin{document} after \pagecolor{tr}. — , Oct 24 '19 at 12:46
@Schrödinger'scat Can you test `\documentclass{article} \usepackage{forest}
\begin{document} \begin{forest} for tree={circle,draw} [1[2[3][4]][5]] \end{forest} \end{document}`? Do you get an error? — cfr, Oct 26 '19 at 01:54
@Schrödinger'scat Weird, isn't it? There's no error with Texlive 2018, even though forest.sty is identical. (I may not have the last updates to reach TL2018, so it could be it works for some point in TL2018 and not later.) Thanks for checking. — cfr, Oct 26 '19 at 02:03
https://tex.stackexchange.com/questions/513716/what-is-the-cause-of-this-dimension-too-large-error-occurs-with-tl2019-but-not @Schrödinger'scat anyone. — cfr, Oct 26 '19 at 02:04
@Schrödinger'scat forest is definitely adding spurious space, too. Non-answer: https://tex.stackexchange.com/a/514047/. Does anything look suspicious to you in the two lines I've marked? — cfr, Oct 29 '19 at 02:19

egreg · Accepted Answer · 2019-10-29T13:32:11.627

You just have to place the settings before \begin{document}

\documentclass{standalone}

\usepackage{forest}
\usepackage{xcolor}

\definecolor{tr}{RGB}{100,200,100}
\pagecolor{tr}

\begin{document}

\begin{forest}
[ 2 [1] [3]]
\end{forest}

\end{document}

However, forest has the tendency to add space; an easy workaround is to call standalone with the varwidth option.

\documentclass[varwidth]{standalone}

\usepackage{forest}
\usepackage{xcolor}

\definecolor{tr}{RGB}{100,200,100}
\pagecolor{tr}

\begin{document}

\begin{forest}
  [A[B[D][E]][C[F][G]]]
\end{forest}

\end{document}

Compare with the output one gets without varwidth:

General solution

The spaces are added because of an unprotected end of line in the definition of \pgfutilsolvetwotwoleqfloat in pgfutil-common.tex, precisely at the end of line 712

712                 \edef\pgf@marshal{
713                     \noexpand\pgfmathfloatdivide@
714                         {\csname r\Pb\endcsname}
715                         {\csname m\Pb b\endcsname}%
716                 }%

Indeed, if I do

\documentclass{standalone}

\usepackage{forest}
\usepackage{etoolbox}

\makeatletter
% remove the stray space
\patchcmd{\pgfutilsolvetwotwoleqfloat}
  { \noexpand\pgfmathfloatdivide@}
  {\noexpand\pgfmathfloatdivide@}
  {}{}
\makeatother

\begin{document}

\begin{forest}
  [A[B[D][E]][C[F][G]]]
\end{forest}

\end{document}

the result is correct as expected

Thanks to cfr who was able to circumscribe the problem. See the issue report at https://github.com/pgf-tikz/pgf/issues/764

This doesn't solve the general problem which is that space is being added inside the forest environment. It does not happen with all trees, including the one here, but it happens with many (most?). That is, this solves the problem for the first tree, but not the second. — cfr, Oct 29 '19 at 02:06
@cfr Now I saw the issue, with a different forest. The workaround is using varwidth. — egreg, Oct 29 '19 at 07:52
Fantastic! Schrödinger's cat and I were trying to pinpoint it below, but I, at least, was not getting much beyond the intersections library. — cfr, Oct 29 '19 at 15:48
It was a long time ago since I posted this problem. Sorry for not responding. Thank you for your investigation and solution! — Eltjo, Oct 17 '20 at 11:31

score 2 · Answer 2 · answered Oct 29 '19 at 02:17

2

This isn't an answer, but an attempt to point towards the problem. forest is adding space, as the following example shows:

\documentclass[border=12pt]{standalone}
\usepackage[]{forest}
\forestset{
  pack stage/.style={TeX=a,for root'=pack,TeX=b}
}
\begin{document}
\fbox{\begin{forest}
  [A[B[D][E]][C[F][G]]]
\end{forest}}
\end{document}

The problem can be traced to the following lines in forest.sty:

  \pgfintersectionofpaths{\pgfsetpath\forest@all@edges}{\pgfsetpath\forest@node@edge}%
  \def\forest@edgenode@intersections{}%

Adding markers as follows

  X\pgfintersectionofpaths{\pgfsetpath\forest@all@edges}{\pgfsetpath\forest@node@edge}%
  Y\def\forest@edgenode@intersections{}%

shows the culprit is somewhere here

However, I'm not sure how to debug this further, so posting this in the hope somebody else may be able to follow the trail from here.

answered Oct 29 '19 at 02:17

cfr

198,882

1

Naively one may think it shouldn't come from the \pgfsetpath because it is used all over and does not seem to produce spaces. But this could be wrong since in tikzpictures these spaces would be gobbled anyway. This leads to the question how on earth the problem can arise because I thought a forest tree is a tikzpicture. Does forest have a "survey phase" before it starts the actual tikzpicture? – Oct 29 '19 at 02:37
1

@Schrödinger'scat Yes. At least, I think so. It works in stages and I don't think they're all inside tikzpicture. I've seen Forest add spurious spaces before, but I think this one is at lines 168/169 of pgflibraryintersections.code.tex. At least, if I put markers on those lines, I catch the spaces between. – cfr Oct 29 '19 at 02:46
1

Yes. I think to have ruled out \pgfsetpath , which is northing but \pgfsyssoftpath@setcurrentpath which gets defined in pgfsyssoftpath.code.tex, and seems to be clean. – Oct 29 '19 at 02:48
1

@Schrödinger'scat In fact, you can change the tikzpicture environment to something else, if you want to. It is only used in the final stage, when the tree is actually drawn (or saved into a box, if you choose that option). Before that, we have all the other stages. prooftrees has even more :(. – cfr Oct 29 '19 at 02:53
1

I was hoping that the old pgfplotsoldpgfsupp_pgflibraryintersections.code.tex would not have the problem, but no. So one real possibility is that in the very tiny ecosystem of TikZ somewhere there is a spurious space that went mostly unnoticed so far because the respective macro was mostly used inside a tikzpicture environment, where it does not have an effect. Searching for a needle in a haystack might be fun in comparison... :-( – Oct 29 '19 at 03:05
@Schrödinger'scat But forest have to have not noticed as well and this space seems awfully easy to trigger. – cfr Oct 29 '19 at 03:14
@Schrödinger'scat Version 1 includes \usepgflibrary{intersections}, so my guess is that, yes, Forest always used them. I don't know about the fpu thing in intersections, though. – cfr Oct 29 '19 at 03:24
1

@Schrödinger'scat Yes, that's line 168. https://tex.stackexchange.com/questions/513491/extra-horizontal-space-with-forest-and-standalone-pacakage/514047?noredirect=1#comment1299930_514047 – cfr Oct 29 '19 at 03:40
1

It is really weird. If I add a {} after the \pgf@intersect@next at the very end of \def\pgf@intersectionofpaths, i.e. in line 237 of pgflibraryintersections.code.tex the issue is gone. BUT I am more than just a bit worried that this will break something. I do not have any understanding for the flip-flop between \pgfutil@firstoftwo and \pgfutil@secondoftwo in its redefinitions. – Oct 29 '19 at 04:25
@Schrödinger'scat The problem is not there if I compile with Texlive 2017 ... – cfr Oct 29 '19 at 04:46
@Schrödinger'scat Or Texlive 2018 (which has identical forest.sty to TL 2019). So it is something relatively recent. – cfr Oct 29 '19 at 04:47
1

Well, given all the troubles with intersections, i.e. here and your recent question, the problem may be there. (I only have one TeX installation so I cannot check.) – Oct 29 '19 at 04:50
1

@Schrödinger'scat See egreg's comment above: https://tex.stackexchange.com/questions/513491/extra-horizontal-space-with-forest-and-standalone-pacakage/514047?noredirect=1#comment1300036_513549. ;) – cfr Oct 29 '19 at 15:48
I actually have an unrelated question I wanted to ask since you were writing packages for trees. Have you ever isolated the sorting machinery of forest? That is, do you know something that is fast, does not load all the expl3 overhead, and allows me to sort lists? Or, even better, to sort lists in which each entry is a list, i.e. arrays, by the first entry of each sublist, say? – Nov 01 '19 at 23:47
1

@Schrödinger'scat I'm not sure what you have in mind, but I only wrote prooftrees. forest got adapted a bit, spurred by prooftrees, but I only know the user-level stuff. prooftrees uses forest's sorting, but that's about it. (I'm only sorting nodes - not content.) You should ask Sašo about the internal stuff. However forest and 'fast' are not generally words one would think of together. The pgfmath stuff is s-s-l-l-o-o-w-w. The argument processor, which uses TeX instead, is fast. But the overall result is generally slow. You could look at forest's index stuff? – cfr Nov 02 '19 at 01:49

score 0 · Answer 3 · answered Feb 24 '23 at 18:42

I want to add an answer for anyone with a recent TeXlive (in my case 2022) who comes across this question and still gets horizontal space. Use case is for defining commands for that standalone file that are not needed in the main document that the standalone is being \includestandalone{}'ed into to. Comments are required at the end of every line after \begin{document} regardless of whether it is necessary in normal LaTeX. For example:

\documentclass{standalone}
\usepackage{forest}
\usepackage{xcolor}
\begin{document}
\definecolor{tr}{RGB}{100,200,100}
\pagecolor{tr}
\tikzset{%
    dotted_block/.style={draw=red!70!white, line width=0.5pt, dash pattern=on 2pt off 2pt,
            inner ysep=0pt,inner xsep=-2pt, rectangle, rounded corners}%
}
\begin{forest}
[ 2 [1] [3]]
\end{forest}
\end{document}

produces:

whereas with comments at the end of every line after \begin{document}:

\documentclass{standalone}
\usepackage{forest}
\usepackage{xcolor}
\begin{document}
\definecolor{tr}{RGB}{100,200,100}%
\pagecolor{tr}%
\tikzset{%
    dotted_block/.style={draw=red!70!white, line width=0.5pt, dash pattern=on 2pt off 2pt,%
            inner ysep=0pt,inner xsep=-2pt, rectangle, rounded corners}%
}%
\begin{forest}
[ 2 [1] [3]]
\end{forest}
\end{document}

produces:

I could not find a reference to this and searching within the forest documentation on CTAN for "space" and "comment" didn't turn up this advice so maybe it will be helpful to others.

Extra horizontal space with forest and standalone pacakage

3 Answers3

General solution

Linked

Related