PDF Invoice 5.0.0: invoicemarkup.php missing from manifest

-- HikaShop version -- : 6.6.0
-- Joomla version -- : 6.1.3
-- PHP version -- : 8.5.9

Hello,

After updating the PDF Invoice plugin from 4.x to 5.0.0 with the Joomla extension installer, downloading an invoice from the backend fails with this error:

Class "HikashopInvoiceMarkup" not found

Environment:
- Joomla 6.1.3
- PHP 8.5.9
- HikaShop 6.6.0
- PDF Invoice plugin 5.0.0

Cause:
_loadPdfEngine() in attachinvoice.php includes invoicemarkup.php and invoicerenderer.php from the plugin folder. Both files are in the downloaded zip, but the <files> section of attachinvoice.xml only lists attachinvoice.php, facturx.php and the "attachinvoice" and "vendor" folders. Because of that, Joomla does not copy the two files to plugins/hikashop/attachinvoice/, and the classes cannot be loaded.

Fix:
Adding these two lines to the <files> section of attachinvoice.xml should solve it:

<filename>invoicemarkup.php</filename>
<filename>invoicerenderer.php</filename>

Workaround: uploading the two files manually into plugins/hikashop/attachinvoice/ works. After that, invoices are generated correctly.

This looks like the same kind of issue as the facturx.php file missing from the XML, which was fixed in 4.0.1.

Suggestion:
While testing, I noticed that the generated PDF embeds the complete font file. With a CJK font, each invoice is about 3 MB, and this file is attached to every order email. Passing subsetfont: true when the document is created in HikashopInvoiceRenderer::newDocument() embeds only the characters that are used. In my test, the same Japanese invoice went from about 3 MB to about 81 KB, with no visible difference. I only tested it without Factur-X (PDF/A-3). It may be worth making this the default, or an option.

Thank you for the plugin and for looking into this.

Hello again,

I would like to add one more issue with PDF Invoice 5.0.0 (same environment as above). I am not a developer. I am checking these problems with the help of an AI assistant (Claude), which found this one and suggested reporting it, so please excuse me if I cannot answer very technical questions. I can test a fix on my staging site.

The body does not stop at backbottom (content reaches the page edge and overlaps page_footer)

With the new engine, the body of the invoice does not stop at the bottom margin set with backbottom on the <page> tag. Our layout is a modified copy of the corporate layout, with backbottom='24mm' and a <page_footer> about 22 mm tall (an 80px image and 5 lines of text).

- When the content is long enough to reach the footer area, the body and the footer are printed on top of each other on the same page.
- When the content is even longer, the automatic page break happens at the physical bottom edge of the page. Text is printed 1 to 3 mm from the edge, which can be cut off when printing, and the next page starts at the very top edge. The footer is drawn only once, on the last page.

With html2pdf (4.x), the same layout stopped the body at backbottom and started a new page.

Probable cause: in HikashopInvoiceRenderer::drawPage(), addPage() is called without margins, so the content area covers the whole page height. The body is placed with addHTMLCell() and only breaks at the page edge, while the footer is placed at (page height - backbottom), inside the same area.

In a test, passing the top and bottom margins to addPage() (margin CT and CB) made the body break correctly, but the footer, which is placed below CB, was then pushed onto a new page by the automatic page break. So the footer probably needs to be drawn without the automatic page break. As a workaround, we moved our address and seal from <page_footer> to the header area.

Thank you.

Hello,

Thank you very much for releasing 5.0.1 so quickly. As before, I checked it with the help of an AI assistant (Claude). It compared 5.0.1 with 5.0.0 and tested the new renderer with our layout. All three points from this thread are solved: the two files are now in the XML, font subsetting is enabled by default, and the body now stops at backbottom, with the footer drawn on every page without overlapping. We only had to change backbottom in our own layout, because we no longer use a page_footer.

The AI assistant also found a Japanese font that works very well with the new engine, and suggested sharing it with you, so here it is.

Suggestion 1: BIZ UDPGothic for Japanese shops

Unifont covers Japanese, but it is a bitmap style font, and our customers found invoices hard to read. We now use BIZ UDPGothic instead:

- It is a Japanese font by Morisawa, designed for readability (UD means Universal Design).
- It is free and released under the SIL Open Font License 1.1. The copyright notice has no Reserved Font Name, so it can be bundled with the plugin (with the OFL.txt file) and used on commercial sites.
- Source: github.com/googlefonts/morisawa-biz-ud-gothic (also available on Google Fonts).
- We converted the TTF file with the Import class of tc-lib-pdf-font that is already included in the plugin, placed the result in vendor/tecnickcom/tc-lib-pdf-font/target/fonts/bizudpgothic/, and added it to the font list in attachinvoice.xml. It works with subsetting, and our invoices are about 70 to 80 KB.
- The converted files are about 3.4 MB.

Please note that it covers Japanese only: it does not include Korean (Hangul), and many Simplified Chinese characters are missing. So it would be best as an additional option for Japanese shops, while Unifont stays for Chinese and Korean. It could also be a good replacement for the old kozminproregular setting.

I have attached an image comparing Unifont and BIZ UDPGothic.

Suggestion 2: build the font list from the fonts folder

At the moment, the font list is fixed in attachinvoice.xml, so every update removes the option we added, and we have to edit the XML again. If the list could be built from the fonts found in the fonts folder, and if the plugin could also look in a folder that is not replaced by updates (for example media/com_hikashop/plugins/attachinvoice/fonts/, like the custom layouts), shops in any country could add their own fonts safely.

Thank you again for the plugin and for your quick support.