I am having an issue with PDFs generatied in Inkscape. If multiple files generated in this way are included on a single page I get the following error:

pdfTeX warning: pdflatex.exe (file <FILENAME>.pdf): PDF inclusion: multiple pdfs with page group included in a single page>]

This seems to be a known bug in TeX and has been discussed here: Multiple PDFs with page group included in a single page warning

Rather than running all my PDFs twice through ghostscript I would like to address this by using silence to surpress the warnings however I am unable to create a warning filter which works.

I have tried \WarningFilter{pdflatex}{PDF inclusion} and various permutations however this does not work. I believe this is due to the file name being placed at the start of the error.

The silence manual states that it is better to use the \WarningFilter* option and to find the process that generates the error message in the .sty files. Since pdfTeX is not a package it does not (to the best of my knowledge) have a .sty file. I cannot work out which file contains the scripts for generating the errors and thus have not been able to create a function filter.

Does anyone know which file (Windows MiKTeX based distribution) generates these errors or how to make a working filter in this case?

  • From the texlive root (on Mac), grep finds that ... Binary file **2013/bin/universal-darwin/pdflatex** matches ... Binary file **2013/bin/universal-darwin/pdftex** matches .... Seems like this would be something hard coded into the TeX binary itself, given this.
    – cslstr
    Jun 4, 2014 at 17:16
  • 1
    It's a warning, not an error. Jun 5, 2014 at 8:31
  • related: tex.stackexchange.com/questions/198583/…
    – user6853
    Sep 1, 2014 at 3:28

2 Answers 2


The warning is generated by the binary itself. Since pdfTeX 1.40.15 (TeX Live 2014) it can be suppressed by a new primitive:


Quoting the documentation:

\pdfsuppresswarningpagegroup (integer)

Ordinarily, pdfTeX gives a warning when more than one included pdf file has a so-called "page group object" (/Group), because only one can "win" — that is, be propagated to the page level. Usually the page groups are identical, but when they are not, the result is unpredictable. It would be ideal if pdfTeX in fact detected whether the page groups were the same and only gave the warning in the problematic case; unfortunately, this is not easy (a patch would be welcome). Nevertheless, often one observes that there is no actual problem. Then seeing the warnings on every run is just noise, and can be suppressed by setting this parameter to a positive number. The primitive was introduced in pdfTeX 1.40.14.

In the file NEWS the version number is 1.40.15, where the primitive is introduced.

  • 1
    Is it possible to update MiKTeX 2.9 to use pdftex 1.40.15?
    – Tom Brien
    Jun 4, 2014 at 18:25
  • 1
    @TomBrien: The roadmap for MiKTeX 2.9 reveals: "pdf/Xe/Lua TeX engine updates (Summer 2014)" Jun 4, 2014 at 18:44
  • Finally marking as accepted since MiKTeX 2.9 now includes pdfTeX 1.40.15
    – Tom Brien
    Jan 26, 2015 at 15:10
  • Seems the quoted documentation is actually incorrect about pdfTeX 1.40.14 and your answer gets it right. This one confirms that 1.40.14 reports undefined control sequence: tex.stackexchange.com/q/310451/25546
    – Palec
    Jul 31, 2016 at 15:15

I haven't either been able to find a quick answer to this issue. The following command-line code does not silence the issue, however solve it. It should be straightforward to understand and is general:

find . -name "*.pdf" -type f -exec sed -i '\/Group <</,+5d' {} \;

What it does: It recursively searches the current folder for .pdf files. In these files the entry "/Group <<" is searched. Starting from this line +5 more , which is the entire Group entry, the lines are deleted. Problem solved!

Note that for a single, specific file this script would be:

find . -name "FILENAME.pdf" -type f -exec sed -i '\/Group <</,+5d' {} \;

Best regards

  • 2
    Internally pdf files work entirely by byte offsets within the file, have you checked if any of those pdfs still work after such an edit (it would be surprising)? May 19, 2016 at 13:50
  • 1
    @DavidCarlisle You are right @felix-schranner This sed statement does work all type of PDF. After doing that, pdflatex says xpdf: reading PDF image failed
    – SebMa
    Dec 1, 2017 at 11:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .