Serious Bug: Broken RTL Text Rendering in PDF Exports

Hello Akaunting Team,

We are writing to report a critical issue regarding PDF generation for RTL (Right-to-Left) languages, such as Farsi (Persian) and Arabic.

The Problem Description
Despite Akaunting's strong promotion of supporting over 50 languages, the PDF exports (e.g., Invoices, Bills) for RTL languages are currently broken.
Missing Glyphs (Initially): Texts initially appeared as question marks (????) due to the lack of proper font configuration.
Current Issue (RTL/BIDI Failure): After successfully configuring a Farsi font (Vazirmatn FD.ttf), the text now appears with separated characters (no character shaping) and is often rendered in reverse order (Bi-Directional failure).
This occurs because Dompdf, the library currently used for PDF generation, lacks the necessary built-in engine to correctly handle the complex BIDI (Bi-Directional) algorithm and Glyph Shaping required by these languages.

Technical Analysis and Root Cause
The issue is not with the font itself, but with the PDF rendering engine:
Engine Limitation: Dompdf does not natively support the full BIDI rendering required for languages like Farsi and Arabic.
Akaunting's Reliance: The current implementation uses the dompdf.wrapper service, which relies on a deficient engine for RTL rendering.

The Proposed Solutions (Call to Action)
For Akaunting to truly support 50+ languages, particularly those with complex scripts, a change in the PDF rendering engine is essential. We kindly ask the development team to consider one of the following long-term solutions:

1. Integrate MPDF as a Standard RTL Solution (Recommended)
mPDF is the industry standard in the PHP ecosystem for generating PDFs with flawless RTL support. We recommend replacing the core Dompdf binding with mPDF.

Implementation Idea: Allow the community (or the core team) to easily Bind a better PDF library like mPDF to the existing dompdf.wrapper service key via a Service Provider. This minimizes core code changes.

2. Introduce a Core BIDI Fixer
Alternatively, if replacing Dompdf is too complex, a PHP library that fixes the BIDI HTML (e.g., using an RTL fixer package) must be executed on the HTML output before passing it to dompdf.wrapper. This would involve modifying the pdfInvoice core method to include the fixing logic.

Conclusion
The inability to generate professional, correctly rendered documents is a showstopper for all businesses using Akaunting in RTL-speaking regions. Since Akaunting promotes robust language support, resolving this PDF limitation should be a high-priority bug fix.

Thank you for your attention to this critical matter.
Best regards, A Concerned User/Module Developer