pdfpc Presenter Console for Multi-Monitor PDF Presentations

pdfpc's Split Audience and Speaker Views

pdfpc addresses a specific gap between viewing a finished slide deck and operating it during a talk. Its input is a PDF document, so the editing workflow can remain in presentation software that exports PDF. During the presentation, pdfpc can place a normal presentation window on one screen and a more detailed overview on another. The audience-facing screen therefore does not need to carry presenter notes, elapsed-time information, or a preview of the following slide.

The intended user is a presenter using more than one monitor. This is not a generic PDF annotation tool or a slide editor. It is a console for presenting an existing PDF, with a speaker-oriented display that includes information such as an image of the next slide and the time remaining until the presentation ends. The README also links sample presentations for a basic demonstration and for embedded movies.

That scope makes the output format a meaningful constraint. The documentation says PDF files can be created by most presentation software, but it does not document editable imports for formats such as Keynote or PowerPoint. Workflows that depend on importing a source presentation and modifying its slides inside pdfpc are outside the documented feature set.

How pdfpc Manages a PDF Presentation

pdfpc is implemented primarily in Vala and uses GTK for its desktop interface. The README lists Poppler with GLib bindings among its build requirements, which places PDF handling at the center of the application rather than treating it as a file-format extension around a conventional editor.

The visible architecture is based on separate presentation and overview outputs. The first display shows the current page as it should appear to the audience. The second display provides the speaker with a more information-dense view. According to the README, that overview can include the next slide and the remaining presentation time. This division reduces the need to expose controls and private notes on the projected display.

The project also has feature modules for media playback, Markdown note viewing, and a built-in REST Web server. Movie playback uses GStreamer by default. Markdown notes are rendered through WebKit2GTK and related dependencies, while the REST feature depends on libsoup and libqrencode. These features can be compiled in or omitted through CMake options, which lets integrators avoid runtime and build dependencies for capabilities they do not need. The available repository structure, including `src/`, `cmake/`, `css/`, `schema/`, and `man/`, is consistent with a native desktop application rather than a browser-only viewer.

Installing pdfpc and Opening the First Deck

The simplest installation path is the platform package named by the README. On Debian, Ubuntu, and related systems, the package is `pdf-presenter-console`, while several other distributions use `pdfpc`. Installing a package does not itself configure monitor placement, so the presenter must still arrange the audience and speaker displays at the operating-system level.

For Debian-based systems, run:

sudo apt-get install pdf-presenter-console

After installation, open the command shell on the presentation machine. The README gives this first use with the downloadable `pdfpc-demo.pdf` file:

pdfpc pdfpc-demo.pdf

That command starts pdfpc against a PDF. The README does not document command-line flags for selecting individual monitors, so display arrangement and any window placement options should not be invented. A presenter should prepare the two screens through the desktop environment first.

The official README also points to a `Simple demo` PDF and an `Embedded movies` archive in the latest release downloads. The simple PDF is the better first file because it exercises the core PDF presentation path without assuming that the host has all required media codecs. The video example is relevant only when the installation includes movie support and the necessary GStreamer plugins are available.

Building pdfpc with Only the Required Features

Building from source requires more dependencies than the command-line application itself suggests. The documented minimums include `cmake >= 3.7`, `vala >= 0.48`, `gtk+ >= 3.22`, `gee >= 0.8`, `poppler >= 0.8` with GLib bindings, `pangocairo`, `gstreamer >= 1.0` with `gst-plugins-good`, Discount, WebKit2GTK, json-glib, libsoup3, and libqrencode. Ubuntu users can install the development packages with the command supplied by the README:

sudo apt-get install cmake valac libgee-0.8-dev libpoppler-glib-dev libgtk-3-dev libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev libjson-glib-dev libmarkdown2-dev libwebkit2gtk-4.1-dev libsoup-3.0-dev libqrencode-dev gstreamer1.0-gtk3

The final package in that command is a runtime dependency, and the README separately advises considering plugins for the video formats that will be used. A successful PDF slide deck does not by itself confirm that an embedded movie will play.

The source build creates a separate directory, configures the project, and installs it. These commands reproduce the README's documented sequence:

mkdir build/
cd build/
cmake ..
make
sudo make install

By default, CMake installs under `/usr/local/`. The README documents `/usr` as an alternate prefix:

cmake -DCMAKE_INSTALL_PREFIX="/usr" ..

Optional modules can reduce the dependency set. Movie support is disabled with `-DMOVIES=OFF`. The built-in REST Web server is disabled with `-DREST=OFF`, which also removes the need for libsoup and libqrencode. Markdown note viewing is disabled with `-DMDVIEW=OFF`, removing the need for WebKit2GTK. The README specifically says `-DMDVIEW=OFF` must be used if WebKit2GTK is unavailable on macOS or Windows.

On Windows with MSYS2/MinGW-w64, the README says source compilation has been tested with the Ninja backend. It calls for `-DCMAKE_MAKE_PROGRAM=ninja` and use of `ninja` instead of `make`. This is compiler-backend guidance from the project, not evidence that native Windows packaging is equivalent to the Linux distribution packages.

Running pdfpc Through WSL on Windows

The documented Windows path is WSL plus a Windows X server, rather than a simple native Windows installation tutorial. The README directs the user to install WSL, open Command Prompt, enter `bash`, and install the Debian package inside WSL. It then requires an X server such as VcXsrv and a multi-screen layout. The documented launch command is:

vcxsrv -nodecoration -screen 0 @1 -screen 1 @2 +xinerama

The X server command is run on Windows and declares two screens while disabling window decorations. In a separate shell, the presenter enters the WSL environment and starts pdfpc with a display variable:

DISPLAY=:0 pdfpc <your PDF file>

The angle-bracket placeholder is literal documentation notation, not a filename that should be copied unchanged. The user must replace it with the path to a real PDF.

This setup has several operational boundaries. The presentation display should be configured as the secondary screen, and the README instructs the user to disable the taskbar there. WSL, the X server, two screens, and Xinerama all participate in the display path. A failure may therefore come from display routing rather than from pdfpc's PDF handling. The README's troubleshooting reference is `FAQ.rst`, which is the appropriate first project file to consult for runtime problems.

Where pdfpc Is Less Suitable

pdfpc is the wrong tool when the presentation must remain editable during delivery. The documented input is a finished PDF, and the repository description identifies it as a presenter console for PDF files. If slide text, diagrams, animations, or media timelines must be changed on stage, the project documentation does not provide an editing workflow for those changes.

A single-monitor setup also removes much of the reason to choose it. The application can still open a PDF, but its defining arrangement is one normal presentation window alongside a richer overview for the speaker. Presenters who only need a full-screen PDF viewer, or who cannot arrange a private second display, may find a conventional document viewer more direct.

Optional playback introduces another failure mode. Movie support depends on GStreamer and plugins for the required video formats. The README warns that suitable format plugins may need to be installed. It does not claim support for every codec or embedded-media construction. A deck containing video should therefore be checked on the actual presentation machine rather than inferred from the fact that the PDF opens.

A real alternative is a conventional PDF viewer used in full-screen mode on one display. That approach keeps the setup simpler, but it does not provide pdfpc's documented split model with a next-slide image, remaining time, and speaker overview. The trade-off is explicit: pdfpc adds presenter-specific controls and information at the cost of a multi-monitor layout and several optional dependencies.

pdfpc Release History and Maintenance Boundaries

The repository is not archived, and the last push was on 2026-04-23. The latest listed release is `v4.7.0`, dated 2024-12-17. Earlier listed releases are `v4.6.0` from 2022-12-22 and `v4.5.0` from 2020-12-20. The release history therefore shows versioned releases through `v4.7.0`, while repository activity continues beyond that release date.

The project uses the GPL-3.0 license. That identifier matters when an organization evaluates redistribution or integration, although this review does not provide legal interpretation. The repository includes `LICENSE.txt`, which is the source to consult for the license text.

Upgrade planning should account for native dependencies and optional subsystems. A rebuild can require updated CMake, Vala, GTK, Poppler, WebKit2GTK, GStreamer, or packaging conventions, depending on the platform. The README's feature switches provide a way to omit components, but it does not publish a compatibility matrix for every release or operating system. For a controlled event, the practical unit of verification is therefore a specific release, the target distribution packages, and the actual PDF deck.

Editorial conclusion

pdfpc suits presenters who already work with PDF slides and need a distinct speaker display containing timing, previews, notes, or optional video. It does not fit teams that need editable presentation authoring or a single-screen-only workflow. Verify first that the target PDF opens correctly, the intended video codecs are installed, and both monitors are arranged as required by the presentation setup.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. pdfpc/pdfpc on GitHub
3. Project website
4. README
5. Releases