PDF export content-type problem

Hey,
Recently i upgraded one of my sites from Kirby 2 to Kirby 3.
Everything works fine except exporting pages to PDF with the mPDF library.
It seems that kirby 3 is forcing the content-type to be text/html, because the output looks very similar to this.
I already tried the suggestions from this question but wherever i try to put the $kirby->response()->code(200)->type('application/pdf'); it just wont work.

Could you provide some more context, please? Like How is this implemented and where are you calling $kirby->response()->code(200)->type('application/pdf')?

I’ve installed mPdf via composer into the Plugin folder.
For testing purposes i created pdftest.php template with the following code from the mPdf Troubleshoot

<?php
// Require composer autoload

require_once 'site/plugins/vendor/autoload.php';

try {
    $mpdf = new \Mpdf\Mpdf();
    $mpdf->debug = true;
    $mpdf->WriteHTML("Hello World");
    $mpdf->Output();
} catch (\Mpdf\MpdfException $e) { // Note: safer fully qualified exception 
    //       name used for catch
    // Process the exception, log, print etc.
    echo $e->getMessage();
}

Now I tried to put the $kirby->response()->code(200)->type('application/pdf') on every position possible, before/after the $mpdf->Output(); line and even tried it with a route:

[
          'pattern' => '(:all)/pdf',
          'action'  => function () {
            return new Response('content', 'application/pdf');
          }
]

But no matter what, the output is always:

%PDF-1.4 %���� 3 0 obj <> /Contents 4 0 R>> endobj 4 0 obj <> stream x�=�� �@Ds�W�Q/�d۵��x+<��Յ"����7� ��dfqb i���;CuP��=���&3�����C�7\��a41�(h�)4��2��#����"����w^�o@�כ�3W�YQ&��mS endstream endobj 1 0 obj <> endobj 5 0 obj <> endobj 6 0 obj <> endobj 7 0 obj <> endobj 8 0 obj <> stream /CIDInit /ProcSet findresource begin 12 dict begin begincmap /CIDSystemInfo <> def /CMapName /Adobe-Identity-UCS def

[...]

I did a quick test using a content representation: templatename.pdf.php (note that a standard template must be present), which works fine. So that would be one way of handling this.

But a route in my environment also works without issues without explicitely setting any headers.

If I test this using a REST client, I also get the right content type without having to set anything.

What is your environment?

Could you post the HTTP Response headers from your request?

Could you test this route, please:

    'routes' => [
        [
            'pattern' => 'test',
            'action' => function() {
                $mpdf = new \Mpdf\Mpdf();
                $mpdf->WriteHTML('<h1>Hello world!</h1>');
                $mpdf->Output();

            }
        ]
    ]

Thanks @pixelijn inline pdf export works now with content representation.

The proposed route also works. Interestingly, the exact same code as a template doesnt work. Plain text again with an empty <head>

If I put this in a standard template, it also works for me:

<?php 
$kirby->response()->type('application/pdf');
$mpdf = new \Mpdf\Mpdf();
$mpdf->WriteHTML('<h1>Hello world!</h1>');
$mpdf->Output();