Issue with displaying Arabic (and likely other RTL languages) in generated PDFs

[snipe]

We have a user who has a mix of Arabic and English in their EULAs and they're encountering an issue where the Arabic is displaying incorrectly, garbled. The fonts are fine, it's just parsing them incorrectly.

Unfortunately, this looks like it might be an issue with DomPDF, not with us specifically.

It's possible we could try to switch to using a different package, such as https://github.com/misterspelik/laravel-pdf, but we would obviously need to test this pretty thoroughly to make sure there are no unintended consequences. It also hasn't been updated in quite some time, which gives me a bit of pause as well.

There are also workarounds for DomPDF via Ar-PHP, but I don't know if that will support non-Arabic RTL text.

We also already include TCPDF, so we might be able to make it work using that library instead of DomPDF.

OR we can consider trying to write some sort of CSS shim into the parsedown handler. :(

[snipe]

I’ve had some successful attempts with mPDF + a custom extension for Parsedown. Will update this with a PR once I have something not completely awful to look at.

Additional bonus, mPDF would make it easier for us to allow users to add a header+footer to different sections of the PDFs. Still have to do a bunch of testing for non-acceptance PDFs, however this would NOT affect table listing export PDFs, as those are generated via jsPDF, which is an entirely different library.

[snipe]

Sigh.

Okay, I had it working, but with mixed RTL and LTR, I'm getting an undefined variable $shift coming from vendor/misterspelik/mpdf/src/Otl.php. If I wrap that return $shift into an isset() it works fine, but obviously I'm not going to edit vendor files.

[snipe]

Still doing some more digging on this - I think the dompdf issues are old. It's a popular project, so I'm sure someone has figured it out.

[snipe]

Ugh....

Looks like DomPDF still doesn't handle RTL properly, so I figured I'd see what TCPDF could do for us.

I've got TCPDF mostly working here, but holy crow is it awful. The documentation is traaaaash, it's basically just like "Here are some examples, figure it out for yourself, jackass."

Unfortunately, you have to set the RTL stuff at the page and $pdf->writeHTML() level, so the HTML template we were using won't do when you have mixed RTL and LTR.

So now I'm having to walk the lines of the EULA to see whether or not we need to change the RTL part.

$eula_lines = preg_split("/\r\n|\n|\r/", $item->getEula());

foreach ($eula_lines as $eula_line) {
    if (Helper::hasRtl($eula_line)) {
        $pdf->setRTL(true);
    } else {
        $pdf->setRTL(false);
    }
    $pdf->writeHTML(Helper::parseEscapedMarkedown($eula_line), true, 0, true, 0, '');
}

(I hate even typing this crap out.)

And this also means we can't use the HTML templates we were using before. For some reason, TCPDF simply does not give a shit about the RTL/LTR HTML, as far as I can see.

$html = view($pdf_view_route, $data)->render();
$pdf->writeHTML($html, true, 0, true, 0, '')

That technically works, but doing something like {!! str_replace('<p>', '<p dir="auto">', $eula) !!} in the HTML for that PDF template just gets ignored.

That said, I guess the PDF looks alright, but I'll need to do a LOT more work to get this to a place where it doesn't look terrible in the code:

As an added bonus, the preview on the accept page doesn't even match the PDF, since we handle it in two different ways.

Super fun way to spend a Friday night, and I'm not even close to done.

[viclou]

[FD-50485]