This produces about 5000 pages before crashing:
\documentclass{article}
\usepackage{framed}
\usepackage{graphicx}
\begin{document}
\begin{framed}
\noindent\includegraphics[height=35cm]{example-image-a}\par
% \kern-33cm\penalty0
% \kern10cm\penalty0
% \kern10cm\penalty0
% \kern10cm\penalty0
% \kern3cm
\end{framed}
\end{document}
or to get more real-life case
\documentclass{article}
\usepackage{framed}
\usepackage{graphicx}
\begin{document}
\vspace*{15cm}
\begin{framed}
\noindent\includegraphics[height=20cm]{example-image-a}\par
\end{framed}
\end{document}
Adding breakpoints by de-commenting out the "kern" lines "solves" this, of course the included graphic is too big.
in second example, the compilation succeeds if height is say at most 18cm and framed picture ends up then on page 2, but it fails for 18.55cm (for info
\textheight
is19.33cm
here.)
I thought, maybe I can use multiple \includegraphics
with trim
option to insert only say a \baselineskip
high horizontal slice of the image. Hoping that the backend pdftex or xetex will include the image file only once for all such successive horizontal slices. (real use case is a png image). Hoping too that there will be no artefact (from anti-aliasing or whats not) in PDF for the list of successive "horizontal slices" allowing suitable pagebreak.
Problem is the "trimming" should be done relative to rescaled picture for a total height of 35cm (forget in this example that it is too wide, too). I looked at the graphicx documentation but failed to see how to do that easily.
What about this problem if using other framing tools tcolorbox
, mdframed
?
From further testing, my original issue is clearly solved by ensuring that the included graphics has a height reasonably smaller than \textheight
as the contents will be shifted to next page if not enough room, and the infinite loop arises if framed
does not find enough room on new page.
But my question about "horizontal slices" still stands.
About avoiding the problem with framed
and keeping into account the \includegraphics
are not manually written but originates elsewhere, I will fix it this way:
\makeatletter
\newbox\my@image@box
\newdimen\my@image@maxheight
\AtBeginDocument{%
\my@image@maxheight\textheight
\advance\my@image@maxheight -2.5\baselineskip % -20pt not enough in my testing
}
\newcommand*{\myincludegraphics}[2][]{%
\gdef\my@includegraphics@options{#1}%
\setbox\my@image@box\hbox{\includegraphics[#1,draft]{#2}}%
\in@false
\ifdim \wd\my@image@box>\linewidth
\g@addto@macro\my@includegraphics@options{,width=\linewidth}%
\in@true
\fi
% no rotation, no need to worry about depth
\ifdim \ht\my@image@box>\my@image@maxheight
\g@addto@macro\my@includegraphics@options{,height=\my@image@maxheight}%
\in@true
\fi
\ifin@
\g@addto@macro\my@includegraphics@options{,keepaspectratio}%
\fi
\setbox\my@image@box\box\voidb@x % clear memory
\expandafter\includegraphics\expandafter[\my@includegraphics@options]{#2}%
}
\makeatother
This ensures the width does not exceed \linewidth
and the height something a bit smaller than \textheight
to allow some room for framed
.
@DavidCarlisle code, with a loop added:
\documentclass{article}
\usepackage{framed}
\usepackage{graphicx,adjustbox}
\usepackage{xinttools}
\begin{document}
\vspace*{15cm}
\raggedbottom
\begin{framed}\parskip0pt \lineskip0pt
%\noindent\clipbox{0 30cm 0 0cm}{\includegraphics[height=35cm,width=\linewidth]{temp}}
\xintFor*#1in{\xintdimensions[0pt+\baselineskip]}:
{%
\noindent\clipbox{0 {\dimexpr35cm-\baselineskip-#1} 0 #1}%
{\includegraphics[height=35cm,width=\linewidth]{example-image-a}}\par
\ifdim\dimexpr#1+\baselineskip>35cm
\expandafter\xintBreakFor
\fi
}
\end{framed}
\end{document}
The screenshot is from Adobe Reader. However one sees some separation between the slices.
In Skim.app also I see artefacts: (not very visible here)
height=35cm
image in a standard sized document? – Sigur Jan 11 '19 at 17:30\vbox
and then\vsplit
? – touhami Jan 11 '19 at 18:30\vsplit
can't split something unsplittable. – user4686 Jan 11 '19 at 18:33tcolorbox
. – touhami Jan 11 '19 at 18:36