7

I get an error with the following MWE when using pdflatex.

\documentclass{article}
\usepackage{pgfkeys, pgfcalendar}
\usepackage{transparent}
\begin{document}
hello world
\end{document}
! Undefined control sequence.

\pgfutil@addpdfresource@extgs ...urce@extgs@plain

                                         {#1}

I can trace it back to \input pgfutil-common.tex so it is not really pgfcalendar and seems like a general clash with pgf. Is this a bug? If so is it known and is there a work around. If not, which side is it on so I can report it.

9

I dare say the fault on in PGF's side, sorry if I'm wrong.

The \pgfutil@addpdfresource@extgs which shows in the error message seems to be a generic macro which, with the current settings, expands to \pgf@sys@addpdfresource@extgs@plain. The latter, however, is undefined. Searching the files for that macro, I found it in driver-specific definition code like pgfsys-pdftex.def and the like, which seems like it's not being loaded.

I was going to say that loading pgfsys-pdftex.def (or pgfsys-luatex.def or pgfsys-dvipdfmx.def) manually solves the problem, however loading the driver code when one is using only pgfrcs (loaded by pgfcalendar, which causes the error) doesn't make much sense, so perhaps the way to go is to un-define \pgfutil@addpdfresource@extgs, so that transparent's code won't try to use it:

\documentclass{article}
\usepackage{pgfkeys, pgfcalendar}
\makeatletter
\AtBeginDocument{%
  \@ifundefined{pgf@sys@addpdfresource@extgs@plain}%
    {\let\pgfutil@addpdfresource@extgs\SomethingProbablyUndefined}{}}
\makeatother
\usepackage{transparent}
\begin{document}
hello \transparent{0.3}world
\end{document}

enter image description here

Another way around, instead of loading the driver code manually, would be to load pgfsys (and graphicx, without which pgfsys apparently doesn't work):

\usepackage{graphicx}
\usepackage{pgfkeys, pgfsys, pgfcalendar}
  • 3
    No it is not the fault of pgf but of the compability code in transparent: it tries to detect pgf to coordinate the pdf resources but the test is not quite correct if only a subpart of pgf is loaded. As we are currently working on the management of pdfresources this will stay until a real solution is there. See also github.com/ho-tex/oberdiek/issues/62 – Ulrike Fischer May 30 at 9:50
  • 1
    I think it's strange for pgf to define the generic \pgfutil@addpdfresource@extgs in terms of a driver-specific macro which is undefined, but this is just my opinion. However the issue appeared after an update in transparent.sty, so... – Phelype Oleinik May 30 at 10:51
  • 1
    @PhelypeOleinik yes it is a bit strange, but it is an internal pgf command and it is not pgf's fault if transparent uses such an internal command wrongly. – Ulrike Fischer May 30 at 11:27
  • 1
    @UlrikeFischer Putting it like that, indeed it makes sense to be on transparent's side. What if the \ifcsname test was done for the inner \pgf@sys@addpdfresource@extgs@plain? Apparently there is only one definition for \pgfutil@addpdfresource@extgs (repo search) so perhaps changing the tested macro solves the problem. – Phelype Oleinik May 30 at 11:39
  • 3
    As I wrote we are currently working in the pdfresources management and try to setup things so that tricks as transparent has to use now to coordinate the resources with pgf is no longer needed. This will mean changes in both packages so I don't see much sense to do some intermediate repairs now. – Ulrike Fischer May 30 at 12:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.