When using pdfpages in LaTeX, how to avoid page breaks before the first page ? - pdf

I am creating a large LaTeX document, and my appendix has reproductions of several booklets that I have as PDFs. I am trying to create a section header and then include the pages at a slightly lower scale. For example:
\section{Booklet about Yada Yada Yada}
\includepdf[pages={-}, frame=true, scale=0.8]{booklet_yadayada.pdf}
However, pdfpagex does two annoying things. First, it devotes one output document page for included document page. I can live with that as I am using 80% scale. The main problem, however, is that the first page is also a new page, so I have a page with just a section title, and then a separate page with the booklet.
Is there some way to get pdfpages to be a little smarter here?

\includepdf uses \includegraphics internally, so something like
\section{Foo}
\fbox{\includegraphics[page=1,scale=0.8]{foo.pdf}}
would include the page without starting a new one, although it only does one page at a time.

For me the following worked just fine:
\includepdf[pages=1,pagecommand=\section{Section Heading}]{testpdf}
\includepdf[pages=2-,pagecommand={}]{testpdf}

I tried this solution too, but \includepdf keeps the advantage of outputting the file over the margin (the output is centered from the edges of the page).
So I openned pdfpages.sty, and I searched for \newpage command. I deleted the first occurance (line 326), just to try, and after saving then compiling again, there were no page break anymore.

Use the minipage environement :
\chapter*{Sujet du stage}
%\fbox{
\begin{minipage}{\textwidth}
\includepdf[scale=0.8]{../sujet-stage/main.pdf}
\end{minipage}
It doesn't add any extra page and it works with includepdf.

Thanks for all the answers - I couldn't for the life of me figure out what logic \includepdf uses to insert blank pages; the trick with including the first page via \includegraphics solved most (but not all) of those problems; so here are some notes:
First, out of curiosity, I have also tried to use only \includepdf, but split in two parts:
\includepdf[pages=1]{MYINCLDOC.pdf}
\includepdf[pages=2-last]{MYINCLDOC.pdf}
... unfortunately, this has the same problem as the question in OP.
Since #WASE's answer, there are now multiple \newpages in the source (pdfpages.sty). I tried reading the source, but I found it quite difficult; so I tried temporarily setting \newpage to \relax only for \includepdf - and that puts all pages in the document on top of each other; so probably not a good idea to get rid of \newpage blindly.
Just \includegraphics[page=1,scale=0.8]{foo.pdf} works - but (as #WASE also note) it is aligned at the top-left corner of the page body, which is to say inside the margins; for a full page we'd want the pdf inclusion overlaid over the whole page, margins included.
This page: graphics - How do I add an image in the upper, left-hand corner using TikZ and graphicx - TeX - LaTeX points to several possibilities for positioning on page over the margins; but for me, the best solution for a full page PDF inclusion is to use package tikz to center it to the page:
\begin{tikzpicture}[remember picture,overlay]
\node at (current page.center) {\includegraphics[page=1]{MYINCLDOC.pdf}};
\end{tikzpicture}
\includepdf[pages=2-last]{MYINCLDOC.pdf}
After this is done, as a bonus, I have also experienced:
Proper targets of PDF bookmarks (going to the right page when clicked)
If you use package pax, the data seems to be included also for the \includegraphics standalone first page, so no difference there
If you have a twoside document - pdfpages, with the above split of the first page in \includegraphics, will now (seemingly) correctly insert the equivalent of \cleardoublepages between pdfs that are included back to back (so I don't have to insert such a command manually).
Hope this helps someone,
Cheers!

I'm a little late, but the following solution worked for me:
\includepdf[pages={-},angle=90, scale=0.7]{lorem-ipsum.pdf}
All pages are imported, scaled and rotated by 90 degrees.
Works with Texmaker 5.0.4

Related

Customize anchor-sections.css with blogdown

I saw in the html_document help page an easy-way to customize the anchor style by adapting the anchor-section class. This works well for individual Rmd documents.
I would like to know how to achieve the same thing within blogdown. I thought that I could simply customize the static/rmarkdown-libs/anchor-sections/anchor-sections.css file.
This actually work temporarily, but is not working properly since this file is automatically regenerated every time any Rmd file is rendered.
I'm sorry I did not include a reprex, this is more of a technical question.

Ghostscript - create a pdf with multiple identical pages and keep size down

Im trying to use Ghostscript to create a PDF with multiple identical pages. I will later use this together with another multipaged PDF to stamp on unique information onto every page.
Is it possible to use Ghostscript to create such a PDF and keep the size of the final file down? Maby there is a flag that i have not noticed that can do this in a better way than the script below?
I have tried to use a regular merge command like the one below but the size of the resulting PDF grows alot and the original file size of 2,061MB merged to a 100page pdf results in a final size of 46,117MB.
"C:\Program Files\gs\gs9.20\bin\gswin64.exe"^
-dBATCH^
-dNOPAUSE^
-q^
-sDEVICE=pdfwrite^
-sOutputFile=outputpdf.pdf^
"inputpdf.pdf"^
"inputpdf.pdf"^
"inputpdf.pdf"(and so on 100 times)
You can construct such a file manually easily enough, which is much smaller, by reusing the page content stream for each page.
However Ghostscript's pdfwrite device won;t do that, not least because it can't. It cannot know in advance that the page its about to receive is the same as the previous page. As a result it will create a new page content stream for each page, and create new content for it.
Note that resources (forms, patterns, colour spaces, image XObjects etc) which are used on each page will be reused on other pages.
However, it seems to me that you're already getting nearly a 5:1 ratio (2k * 100 pages = 200Kb, the final file is 46Kb) though in fairness a good bit of that 2Kb is 'stuff' around the page.
Without seeing your input file I can't really comment any further, but frankly I doubt its possible to make it any smaller without hand-crafting the file. What's the problem with a 46Kb file anyway ?

Doxygen LaTeX / PDF links point to page 1

I am using Doxygen to create a product manual, and I ran into this issue.
Some links in the outputted PDF (created from LaTeX) are broken; they point to the first page of the document.
The accompanying HTML output does not suffer from this issue; links work just fine, as shown below:
The Doxygen code for this page:
/**
#mainpage [product] Developer's Guide
Blah blah blah.
This manual is divided into the following sections:
- #subpage intro
- #subpage [etc]
*/
Further notes:
I tried #ref instead of #subpage. No difference.
Some other references in the PDF are broken as well (automatic file references in some sections), but many work fine.
Here's the LaTeX intermediate for this page:
This manual is divided into the following section\-:
\begin{DoxyItemize}
\item \hyperlink{intro}{Product Introduction}
[etc]
Edit: Manual Solution Found
Open refman.tex from the LaTeX output directory
Change the entry \hypertarget{d1/dfb/intro}{} to \hypertarget{intro}{}
Repeat for other pages
Run the LaTeX to PDF tool
This is obviously not a viable solution for automated processes though, so this question is definitely still open.
As stated in the answer provided by #aaronncfca. The problem is caused by the not proper handling of paths in case CREATE_SUBDIRS is set to YES.
A, proposed,patch has been created for this problem and pushed (pull request 328) to github
Valid workaround found: Disable CREATE_SUBDIRS in the Doxygen configuration (Expert tab, Project topic in doxywizard).
The issue (as shown in the manual solution in my question) is that Doxygen puts the path in the hypertarget thing, where only the symbol is needed. By eliminating the path entirely, disabling sub-directories fixes the issue.

beamer "second screen" with XeLaTeX

I want to use beamer to project slides onto one screen and my notes onto a second screen. Beamer's show notes on second screen option is designed for this purpose. It requires the pgfpages package, and it is supposed to create PDF pages of ordinary height but twice the ordinary width, so that half of the page can be projected onto one screen, half onto the other.
The option works as intended when I use pdflatex. But when I use xelatex (from MikTeX 2.9), I get pages of only the normal width. The pages are my normal slides; my "note" slides are not created. Here is an example:
\documentclass{beamer}
\usepackage{pgfpages}
\setbeameroption{show notes on second screen=right}
\begin{document}
\begin{frame}{Note test}
\begin{itemize}
\item<1-> Eggs
\item<2-> Plants
\note[item]<2>{Tell joke about plants.}
\end{itemize}
\end{frame}
\end{document}
When I use pdflatex, this code produces a PDF file of double width, with note slides on the right. When I use xelatex, it produces a PDF file of normal width, and no note slides are included. Changing the first line to \documentclass[xelatex]{beamer} makes no difference.
Is there anything that I can do to make the show notes on second screen option work with xelatex?
I am using beamer 3.27 and pgfpages 0.02 (which is distributed with v3.0 of the pgf package).
Adding these lines solves the problem:
\renewcommand\pgfsetupphysicalpagesizes{%
\pdfpagewidth\pgfphysicalwidth\pdfpageheight\pgfphysicalheight%
}
Credit to Tomáš Janoušek, who provided the answer in this post to the XeTeX mailing list: http://www.tug.org/pipermail/xetex/2009-June/013325.html.

Dojo - Some of my form.dijit's seem to be dead/inactive on one page

I was started to work on my first sample of the dijit.Tree control.
When it didn't work, I added a couple of dijit.form.Textbox'es to the screen, and they didn't work either, even though I have them working fine on a similar form.
Interesting enough, when I killed FireFox and restarted it, I was got a clear message in FireBug console on what was wrong with my tree control, and got it fixed.
But now I'm rather puzzled while the simple dijits like NumberTextBox that I added are not working.
My Samples:
1) http://3wcloud-com-provisioning-qa.appspot.com/testDijitDate - this works great
(except the initial date value not showing - I have a separate question open on that)
2) http://3wcloud-com-provisioning-qa.appspot.com/testDijitTree
I've done several "diff"s on the two files, and I kind find the difference that would cause one to work and one not to work.
Thanks,
Neal
You should put your dojo.require statements immediately in a script block, not wrapped in the onload callback. Also, your input tags should be HTML style without the XHTML style slash (you didn't declare XHTML in your document) though I doubt that's the problem. See if either of those things help.