# Multiple PDFs with page group included in a single page warning

I updated TeX Live to the Ubuntu Quantal version (2012.20120611-4) and I suddenly got this warning:

PDF inclusion: multiple pdfs with page group included in a single page

This is a minimal example for which I get the warning:

\documentclass{book}
\usepackage{graphicx}
\begin{document}
\includegraphics{image1}

\includegraphics{image2}
\end{document}


Both images have been produced by the export PDF feature of Inkscape and contain simple line drawings (no fancy stuff).

I have been looking on the Internet, but only found others with this problem and did not found any solutions:

• In the Latex user group they did not seem to understand/recognise the problem. And told the OP to go to the MikTeX groups, but it is not a MiKTeX specific problem as it is also happening with TeX Live and other distributions.

• At gmane.comp.tex.pdftex they were looking into the use (and versions) of MS Office products. Also not the cause as I am not using MS Office to produce PDFs.

During my search if found the PDFTeX code (pdftoepdf.cc) that spawns this warning, maybe it is of some help in understanding what is happening?

if (pdfpagegroupval == 0) {
// another pdf with page group was included earlier on the same page;
// copy the Group entry as is
pdftex_warn("PDF inclusion: multiple pdfs with page group included in a single page");
pdf_newline();
pdf_puts("/Group ");
copyObject(&dictObj);
} else {
// write Group dict as a separate object, since the Page dict also refers to it
pageDict->lookup((char *) "Group", &dictObj);
if (!dictObj->isDict())
pdftex_fail("PDF inclusion: /Group dict missing");
writeSepGroup = true;
initDictFromDict(groupDict, page->getGroup());
pdf_printf("/Group %d 0 R\n", pdfpagegroupval);
}


Does anyone have an idea what is happening, whether it is serious and how I could get rid of these warnings?

-
"I have been looking on the Internet, but only found others with this problem." Some links could be useful. –  lockstep Oct 11 '12 at 8:40
@lockstep sorry I forgot. I have updated my question showing the two of this discussions going nowhere. –  Veger Oct 11 '12 at 9:07

The problem is also reported in a german forum mrunix.de. It might be a bug in the tex distribution (pdftex). The problem happens only when you include multiple pdf pages, created in a specific manner (e.g. by MS Office products), in a single page.

Solution: Convert pdf files into ps and then back to pdf using Ghostscript, then the warning will go away (pdf2ps -> ps2pdf). This conversion probably removes the "page group" information from pdf files. (Caveat: This renders your pdf and some text might not be selectable or searchable any more.)

Editing the colorspace of pdf files with ghostscript also resolves the issue (if there is no multiple pages in the pdf file):

gs -o image.pdf -sDEVICE=pdfwrite -dColorConversionStrategy=/sRGB
-dProcessColorModel=/DeviceRGB image.pdf


CMYK conversion if RGB does not work for you:

gs -o image.pdf -sDEVICE=pdfwrite -dColorConversionStrategy=/CMYK
-dProcessColorModel=/DeviceCMYK image.pdf


P.S. Some programs generate "page group"s in pdf files; for example when you impose different images/objects in illustrator or inkscape. It seesm that pdftex is unable to handle multiple page groups in a single output page. The reason might be that each page groups specifies a different color space or transparency space.

-
Thank you for your explanation and solution, it works. Minor disadvantage of pdf2ps -> ps2pdf: the text in my PDF figures is not text anymore (ie it is not selectable), so I need to go and find another solution to remove the 'page groups' –  Veger Oct 17 '12 at 13:07
Your ghostscript conversion method works better! Thanks again –  Veger Oct 18 '12 at 6:58
Your gs command entirely screwed up my PDF images. –  Dominique May 2 '13 at 20:20
@Dominique, What happened to your images? The command works for me. You may cosnider converting to another colorspace if RGB does not work for you. –  Aydin May 7 '13 at 10:38
converting to .ps will rasterise anything with transparency, so not an option for many .pdfs –  Chris H Apr 2 at 15:01

PDF has a feature called "Page Groups" (PDF Reference, section 11.4.7). These descibe transparency effects between top-level objects on one page. When pdfTeX (or LuaTeX or XeTeX) includes a page from a PDF, it converts all pages into "Form XObjects" (section 8.10.1). pdfTeX also converts the Page Groups into /Group entries of the XObjects.

The problem now is that Adobe products need also a /Group entry (whose content should not matter) in the /Page object which contains these XObjects to correctly render transparency (this is just needed to select the right rendering engine; the transparency information for the included pages should be taken from these included pages).

pdfTeX will either use the first /Group it encounters when including PDFs or synthesize one when including PNGs with transparency. The warning is triggered when multiple Page Groups are encountered on one page (since the engine will then use the first one encountered and this may not be the "correct" one) and can probably be ignored. Of course this should be described somewhere in the pdfTeX documentation...

-
Thanks for your extensive explanation, it clarifies a lot! –  Veger Oct 17 '12 at 13:08

Instead of using pdf2ps or ghostscript (which both introduced some errors in my pdfs, e.g. missing lines), I just removed the Group information from the PDF with

sed -i 's/\/Group.*R//g' file.pdf


I don't know if this could introduce any problems, but in my case, with only single-paged libreoffice-exported images, it works well.

-
Welcome to TeX.SX! –  Claudio Fiandrino Jan 16 at 15:08
Thank you! I edited the regex to include the 'R', which happens to appear on those useless page groups, but not in real groups - at least in libreoffice PDFs. If someone would look further into this, I'm sure a Method can be found which securely deletes only the page group information in all PDFs. –  user44252 Jan 17 at 8:00
I have the same problem but only /Group >> followed by a short section. So this regex cannot help. –  math Mar 24 at 13:01
Sorry, this is dangerous advice. It would be nice if you could just delete text from a PDF file but you can't -- there are internal pointers that get corrupted, because they depend on the exactly location of the various elements in the file. So this answer is best deleted. –  Silvio Levy 2 days ago

Additional Info / Workaround for MS Office Users: I have been using pdfLaTeX with PDFs generated from Visio for years. I just reinstalled my PC and then I got the warning - but only for NEWLY saved PDFs, not for the old ones. Therefore I looked for PDF options in Visio: If you tell Visio to generate PDF/A compatible PDFs, the warning will disappear.

-

Another additional info for Adobe Illustrator users: select "Acrobat 4 (PDF 1.3)" Compatibility when saving the PDF. Then the warning will disappear.

-

Following the pdf2ps -> ps2pdf advice from a previous answer, this is how I solved the issue. I browsed to the folder where my pdf images are located, used find to get all filenames, performed both transformations and deleted the temporary ps file.

In short:

for f in $(find . -type f -name "*.pdf"); do echo$f; pdf2ps $f${f%.*}.ps; ps2pdf ${f%.*}.ps$f; rm -f ${f%.*}.ps; done  - Here is what I found: Somewhere at the beginning the PDFs contain a group which defines the contents of the page. For a ghostscript generated PDF it looks like this: 5 0 obj <</Type/Page/MediaBox [0 0 172.8 201.6] /Rotate 0/Parent 3 0 R /Group 4 0 R /Resources<</ProcSet[/PDF /Text] /ExtGState 104 0 R /XObject 105 0 R /Font 106 0 R >> /Contents 6 0 R >>  The line /Group 4 0 R refers to a group object which looks like this: 4 0 obj <</Type/Group /S/Transparency /CS/DeviceRGB>>endobj  This object defines the page transparency and color space. To get rid of the pdftex warning it is enough to remove the reference to this group i. e. remove the line /Group 4 0 R with an editor that won’t hurt the binary data like vi or use sed: sed -i".bak" -e "/^\/Group 4 0 R$/d" "filename.pdf"


For PDFs generated by matplotlibs backend_pdf the group won’t be in a separated group. The main object looks like this:

10 0 obj
<< /Group << /CS /DeviceRGB /S /Transparency /Type /Group >> /Parent 2 0 R
/MediaBox [ 0 0 172.8 201.6 ] /Resources 8 0 R /Type /Page /Contents 9 0 R
>>
endobj


Here /Group << /CS /DeviceRGB /S /Transparency /Type /Group >> has to be removed.

P. S.: The ghostscript method did unfortunately not work for me, the error still appears. Only when I forced PDF version 1.3 in ghostscript it would go away. But that rasterizes the image.

-
But it's not an error but a warning. Did you read my answer? –  Martin Schröder Jan 17 at 15:39
Welcome to TeX.SX! You can have a look at our starter guide to familiarize yourself further with our format. –  Martin Schröder Jan 17 at 15:40
Yes, I read that but by the time you have about 70 warnings it is simply annoying and I couldn’t see real warnings and errors anymore. Of course this can only be a workaround until a proper solution, probably in pdftex, is found. –  Velocipede Berserker Jan 17 at 15:43
And thanks for the downvote, any explanations? :-/ –  Velocipede Berserker Jan 17 at 15:58
Your answer does not answer the question - only the last part, and since the warning is harmless, it's not needed and will probably do more harm then good. –  Martin Schröder Jan 17 at 19:05

I had the same problem when I was using the SVG file. To solve my problem and to automate the process under Microsoft Windows OS I did:

1) Add to the environment variable 'PATH' the full folder paths of Inkscape and Ghostviewer command line executables;

2) You may need to restart the computer, in order to update the environment variable 'PATH' with your changes;

3) Edit a batch file with the following content and name it 'svg2pdf.bat'. Save it in your main folder of the Texniccenter project:

@echo off
SET FileName=%1

::Convert forward to backward slash
SET FileName=%FileName:/=\%

::generate pdf image from svg
inkscape -z -D --file=%FileName%.svg --export-pdf=%FileName%.pdf
::remove the multiple page problem
gswin32c -sDEVICE=pdfwrite -o %FileName%_aux.pdf %FileName%.pdf
::save the resultant pdf file
move /y %FileName%_aux.pdf %FileName%.pdf


4) In the preamble of the tex file, define the latex commands:

\newcommand{\executeiffilenewer}[3]{%
\ifnum\pdfstrcmp{\pdffilemoddate{#1}}%
{\pdffilemoddate{#2}}>0%
{\immediate\write18{#3}}%
\fi%
}

\newcommand{\includesvgpdf}[2][\columnwidth]{%
\includegraphics[#1]{#2.pdf}%
}


This new latex command \includesvgpdf accepts 2 arguments, where the first one must be "width=ToDefine", where "ToDefine" will be the width and the second argument must be the SVG file name without the extension.

\includegraphics[width=0.5\textwidth]{SVG_FILE_NAME}


use

\includesvgpdf[width=0.5\textwidth]{SVG_FILE_NAME}


Hopping it also works for you.

-
Welcome to TeX.SX! –  Heiko Oberdiek Jan 31 at 14:59
For me the gswin32c -sDEVICE=pdfwrite -o %FileName%_aux.pdf %FileName%.pdf won't remove the warning. –  math Mar 24 at 13:12

Unfortunately the issue is not always as harmless as stated in previous comments. I have a file (about 50 pages) with about 70 little sketches (typically 15mm x 8mm, all of them images.pdf), up to 8 sketches on one page. When the warning "multiple pdfs with page group included in a single page" appeared, 5 pages got completely black in the output pdf file, with the Acrobat Reader returning an error message. The remaining 45 visible pages were displayed correctly, including the sketches. With shifting some sketches to other places, other pages got black, with no clear relation between certain images and blackened pages discernible. After I opened all images with GSView, applied File>Converte>pdfwrite with Properties>Compatibility/Level 1.2, both the warnings and the black pages disappeared, and everything is fine now.

Remark: The problem turned up when I started with a new TexLive installation under Windows 8.1 on a new computer. There was no problem with the self-same images.pdf with an older TexLive installation under Windows XP on my old computer. When I viewed the dammaged pdf files with Acrobat Reader on the old computer, they were dammaged as well. When I viewed the pdf output file from the old computer with Arobat Reader on the new computer, everything was fine. Thus obviously the new Techlive is handling images.pdf different than the old TexLive did.

-

I had the same problem when using graphs exported from OriginLab 9.0 and compiling with PDFTeXify (WinEdt 8.1 + MiKTeX). However, changing export options under PDF/Image Settings/PDF Options/Fonts/OutLine Mode into Adobe Type 3 I do not receive any more warnings. So, thanks guys for clarifying this issue

-

I had the same issue with exporting pdfs from inkscape. The work around was to export into ps and then convert pstopdf, e.g. with Adobe Distiller or other tools.

-
This is rather a comment than an answer –  Christian Hupfer Jul 3 at 8:33