I have encountered the same crash with the PDF export, but it does not occur for every file. I have not yet been able to identify the conditions under which it reproduces.

You may be able to reproduce this by doing the following:

1. Check your cairo version is 1.18.2 .
2. Create a LaTeX file:

\documentclass{minimal}
\begin{document}
a
\end{document}

3. Generate a PDF with lualatex or xelatex, ( NOT with pdflatex) .
4. Open that PDF with Xournal++, and try to export as PDF.

I get the same error when exporting .xopp to pdf
and downgrading to previous version xournalpp 1.2.2-1 , and there is no more error but the PDF file is broken

In my experience, exporting annotated pdf files containing images with embedded fonts crashes xournal when cairo-1.18.2 is installed.

Here's why on an example:

My beamer example (the included file img-with-fonts.pdf with tight bounding box is exported from a vector graphics program):

% File: beamer.tex
\documentclass{beamer}
\usepackage{graphicx}

\begin{document}
\begin{frame}

\includegraphics{`img-with-fonts.pdf`}

\end{frame}
\end{document}

• The file beamer.tex -> compiled by pdflatex -> beamer.pdf -> anotated by xournalpp beamer.pdf -> beamer.xopp
• Attempt to export to beamer_annotated.pdf either from the GUI or on the command line crashes xournalpp with error message:

Cairo error: out of memory

• If cairo is downgraded to 1.18.0, the export to beamer_annotated.pdf runs flawlessly.

On the contrary:

• If one compiles the same beamer.tex where img-NO-fonts.pdf is included (same vector-graphics file with all inscriptions removed and exported to pdf);
• compiled in same way as above to beamer.pdf with pdflatex and annotated in xournalpp
• can be exported to beamer_annotated.pdf no matter what version of cairo is used.

Moreover, if img-with-fonts.pdf is converted to totally pixelized `img_with_fonts.png, by e.g. ImageMagic and included in the same beamer.tex

\includegraphics{`img-with-fonts.png`}

can likewise be compiled, annotated and exorted to beamer_annotated.pdf no matter what version of cairo is used.

img-NO-fonts.pdf
img-with-fonts.pdf

Tne pixelized img-NO-fonts.png cannot be attached, only shown in github:

Seems to be related #5820.

Using openSUSE and libcairo2 1.18.2 from GNOME:Factory or GNOME:Next, I am able to reproduce the PDF export issue, but not the PNG inclusion one.

Here's a minimal reproducible code that causes the error, similar to https://www.cairographics.org/cookbook/renderpdf/:

#include <iostream>
#include <filesystem>

#include <cairo-pdf.h>
#include <glib-2.0/glib.h>
#include <poppler-document.h>
#include <poppler-page.h>

int main ()
{
    // open PDF using poppler
    auto uri = g_filename_to_uri(std::filesystem::absolute("in.pdf").c_str(), nullptr, nullptr);
    auto document = poppler_document_new_from_file(uri, nullptr, nullptr);
    g_free(uri);

    // create pdf rendering surface and target
    auto surface = cairo_pdf_surface_create("out.pdf", 0, 0);
    auto cr = cairo_create(surface);

    // render pages one by one
    auto num_pages = poppler_document_get_n_pages(document);
    for (int i = 0; i < num_pages; ++i) {
        auto page = poppler_document_get_page(document, i);
        double width, height;
        poppler_page_get_size(page, &width, &height);
        cairo_pdf_surface_set_size(surface, width, height);
        cairo_save(cr);
        poppler_page_render_for_printing(page, cr);
        cairo_restore(cr);
        cairo_show_page(cr);
        g_object_unref(page);
    }

    g_assert(cairo_surface_status(surface) == CAIRO_STATUS_SUCCESS);  // no error yet
    cairo_surface_finish (surface);
    auto status = cairo_surface_status(surface);
    if (status) {
        std::cerr << cairo_status_to_string(status); // outputs "out of memory"
    }
    
    // clean up
    cairo_destroy(cr);
    cairo_surface_destroy (surface);
    g_object_unref(document);

    return 0;
}

Using a PostScript surface instead of a PDF surface still works. It looks like an upstream regression to me.

same here, downgrading to cairo 1.18.0-2 fixed if for now

Thanks for reporting the issue to upstream, @tmoerschell .
This bug has already been fixed in upstream, and I've confirmed the crash is gone.

@tmoerschell: Can you please take a look?
As far as I've been told, this bug seems to already been fixed in upstream wit the crash is gone. Can these changes be merged?

Thanks in advance for your time and attention!

Yes, I can also confirm this bug has been fixed upstream. However, release might take a while. Since it is an external dependency, there is nothing we can merge on the xournalpp side.

To build cairo yourself:

Install build dependencies: from cairo's README:

• Debian (and similar):

  • apt-get build-dep cairo

• Fedora (and similar):

  • dnf builddep cairo

Or check what the meson setup command below complains about and install the corresponding packages. Then run:

git clone https://gitlab.freedesktop.org/cairo/cairo.git
cd cairo
mkdir build
meson setup --prefix=/usr --buildtype=release build
ninja -C build
sudo ninja -C build install

@tjavdar does this also fix the PNG inclusion issue? I wasn't able to reproduce it.

@tmoerschell: Thanks for the immediate response!

• Yes, Cairo 1.18.2.r19.gb9eed915f-1 seems to fix the (%.pdf+%.xopp)->%-annot.pdf compilation problem.
• And no, PNG or ePDF inclusion on an empty xournalpp-canvas still crashes xournalpp.

May be the latter is not a Cairo problem whatsoever. Or because I run xournal++ natively under Wayland (stock Arch-package 1.23.1-1) on Hyprland (hyprland-git 0.43.0.r22.d35e70a8-1)? (Still, I don't think that it's Hyprland's fault. This crash persists throughout both the stable Artch package, as well as 10-ish git revisions. Can test it under Wayland/Sway or X/i3 if you think this is a good idea).

Enclose the specific PDF and PNG (produced from same metapost source).

errorlog.20240914-135737.log

Partition1.pdf

I'm curious, I don't think it is possible to include a PDF as an image. Do you mean opening the PDF directly for annotation?
In #5820, the issue is an improperly recognized mime type. Does file <your-image> -i output "image/png;"? In order to upload the original file to GitHub, you can simply zip it.

@tmoerschell: Thanks again; Here are direct answers to your questions:

• No, I tried to insert pdf in an empty Xrnl++ canvas via the menu, and NOT to annotate. And you are right, encapsulated pdf's seem not to be insertable in xournal++, only jpg's and png's are.
• Yes, the PNG image is a _PNG image, file produces: _Partition1.png: PNG image data, 200 x 126, 8-bit grayscale, non-interlaced, nothing to write to home about.
• To verify that Cairo is still a suspect cause for the crash, I reverted to old version of Cairo 1.18.0 and included with no problems that very same PNG which crashes Xournalpp under all newer versions of Cairo, including the newest 1.18.2.r19.gb9eed915f, and saved the %.xopp file.

I attach for your convenience a zip of both the xopp-file, the PNG, the ePDF, as well as the metapost source they are produced from.

Xrnl++CrashEx.zip

Hi, thank you very much for the precision and availability. I still couldn't directly find out what is wrong. The image loading code might have one or two issues, but I can't understand why it'd crash for a simple PNG under 4096 bytes.

If you're up for it, could we maybe try something so that we can find out what is happening remotely? I wrote the image loading / format determination part as a standalone, with better error checking. Compile and execute the following, with your file name as argument: main.cpp.txt

mv main.cpp.txt main.cpp
g++ -o load-image $(pkg-config --cflags --libs gdk-pixbuf-2.0) main.cpp
load-image _Partition1.png

What is the output? On success, you should get:

file size: 1227 bytes
Format was successfully determined after closing the image

Can you find images that make it fail and others that don't? If you modify line 55 of the source as stated in the comment right above it and recompile, are there any differences?

As you can see in the source, cairo is not used for this specific part of the code, I'd be really surprised if the cairo version makes a difference in the standalone. This whole thing puzzles me.

@tmoerschell: If God is nice, we might not have to get that far.

Sorry to tell you that (you've spent time to distill that that standalone), but C++
compiling is a bit of a strectch for me, would be first time ever.
I will try eventually if needed, but it does not seem to be necessary.
Here's why:

Vaguely remembering that the same PDF/PNG generated with inscriptions
commented out didn't crash Xrnl++ under the newer cairo, I tried to reproduce
the example you asked for. Namely, two copies of a PNG -- one that does crash
Xournal++, and one which does not.

Success part:

Here comes the mystic successful part: Amazingly enough, updating to stock Arch package
cairo 1.18.2-1 this morning, inclusion of both PNG and JPG seem to work fine:

I prepared from the same source 3 Figs (in dir ./Figs):
-_Fig.{png,jpg} which have text inscriptions/fonts in them
-_Fig-blank.{png,jpg} whith no iscriptions (commented out in source)
and
-included them all 4 under the both older cairo-1.18-0 and newer 1.18.2 successfuly.
-expored them to pdf both unde older cairo-1.18-0 and the newer 1.18.2 correspondingly.

Crash part:

As a Maths teacher I'm mostly annotating LaTeX Beamer presentations, often with
included pictures in them, so I wanted to see if this part works.

And Bingo, here came the font-no-font cairo export divide.

I prepared (LaTeX-sources in ./LaTeX-dir):
-bLaTeX-all6figs.pdf with all six Figs,_Fig.{pdf, png,jpg}, _Fig-blank.{pdf,png,jpg}, which could be annotated no matter which cairo version was used. It could be exported to %-annot.pdf only unde cairo 1.18-0., whereas Cairo 1.18.2 pdf export chashes with cairo memory error.
-On the conrary, bLaTeX-just3blank.pdf (no inscriptions/fonts) can be annotated and exported under both versions of cairo .

All above references in the uppdated:
Xrnl++CrashEx.zip

Thank you again for all the details.

The fact that exporting some PDFs does not work with cairo-1.18.2 is "expected". By installing version 1.18.2, you reverted the fix that was done on the latest build (b9eed915f). So if I understand this right, the image inclusion crash happens on the self-built package, but not on those from the distribution? Or not anymore at all? Is the "stock Arch package
cairo 1.18.2-1" any different from the one that caused the issue initially? I am thinking that the image inclusion issue must be entirely separate from the cairo library used. It might have some other totally unrelated cause.

PS: You can use LD_LIBRARY_PATH="/<path>/<to>/cairo/build/src/" xournalpp to use the self-built library without installing it back and forth.

@tmoerschell: I will probably have to apologize for your time and effort, now that things seem to work well with newest cairo-git.

Yes, I did revert to stock Arch Cairo 1.18.2-1 when doing all experiments of pure curiosity. And yes, it might have been updated in the recent 2-3 days, I realy don't know. (Switching between stock versions of cairo is not a problem, as well as installing cairo-git from AUR using yay is a breeze).

Good News under newestcairo-git:

Reverting back to cairo-git 1.18.2.r19.gb9eed915f-1 yields total success this time, namely:

• including both png-images (text and no-text) in a blank canvas with subsequent export to pdf
• Exporting the annotated presentation with all six images to pdf.

For the record: Both previous and current tests were done using xournalpp-git 1.2.3.r334.gd435ef5fa-1.

Here are the resulting exported pdfs:
Included-under-Cairo-1.18.2.r19.gb9eed915f-1-annot.pdf
bLaTeX-all6figs-annot-Cairo-1.18.2.r19.gb9eed915f-1.pdf

No need to apologize, I'm happy to hear it finally works for you. If everything is working fine, I think this issue can be closed.

I whish you all the best with Xournal++!

Yes, xournalpp-git 1.2.3.r334.gd435ef5fa-1 under cairo-git 1.18.2.r19.gb9eed915f-1 seem to work hassle-free in this regard, so I'm closing this issue.

Still, I cannot help the feeling some black magic took place behind the scences (some random Arch package got uppdated or something).

Thanks again everybody!

@tmoerschell : for me the issue happens on the current flatpak version

@kostat you need to install the latest build of cairo. You can either build it yourself as described above: #5847 (comment)

Or you might be able to find a packaged nightly build such as cairo-git or similar for your distribution.

@tmoerschell , you understand that your suggestion may work only with xournallpp installed natively. The flatpak version uses a bundled cairo.

Ok I understand. I'm a little out of my depth when it comes to flatpaks. I'm not sure how this would need to be specified in the flatpak manifest, but you could open an issue on the corresponding flathub repo. If you feel confident enough, you could as well try to build the flatpak package yourself.
Otherwise, I've read that you could try flatpak override, but I'm not sure if that will get you anywhere.

The Xournal++ flatpak uses the Gnome runtime which in turn is based on the Freedesktop runtime. The Cairo version in used is defined there: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/master/elements/components/cairo.bst?ref_type=heads