Eliminate usage of Zend_Pdf from Magento 2 Open Source

[vkublytskyi]

References count: 133
Used in EE/B2B: yes

Acceptance Criteria:

1. Usage of Zend_Pdf removed from Magento 2 Open Source
   • all references to Zend_Pdf are removed from Magento 2 Open Source
   • added static a test that verifies that Zend_Pdf is not used
   • Travis builds are green on PHP 7.1 environment
   • all backward incompatible changes are documented (if any)
   • if possible ZF1 component replaced by embedded PHP functionality or PSR interface otherwise migrated to ZF2
   • if ZF1 component replaced by ZF2 component:
     • there is an explanation why it is required to use external dependency
     • if usage of old ZF1 component was exposed in M2 interface/class signatures it is removed for new code
     • there is a list of PHP 7.2 compatibility issues of new ZF2 component
       OR
2. There is an explanation why it is impossible to delete this dependency now:
   • described scope of work that is necessary to totally remove usage of Zend_Pdf
   • described what backward incompatible changes will be caused by dependency removal
   • listed what other ZF1 components are required for Zend_Pdf to support M2
     (if only limited functionality of Zend_Pdf is used by M2
     then not all dependencies may be required and some part of Zend_Pdf
     still may be removed if has incompatibility with PHP 7.2)
   • listed PHP 7.2 compatibility issues for Zend_Pdf

[maxbucknell]

There are a few complexities around this piece of work:

• Zend_Pdf is obsolete, and there is no later Zend Framework component to replace it.
• Zend recommend a library tecnickcom/tcpdf to replace Zend_Pdf.
• tecnickcom/tcpdf says that it should be considered obsolete, as they have a new version of their software.
• This new library, tecnickcom/tc-lib-pdf is in development but doesn't seem to be seeing much in the way of active work, and might never happen.

Given this, my recommendation would be as follows:

• tecnickcom/tcpdf is stable and very widely used, so we should adopt that as the underlying library to generate PDFs.
• Because this library might change in the future, we should build some interfaces that we can implement, so that replacing this library later on becomes a little bit easier, should we need to. This will be better than using TCPDF directly anyway, because that API is not PSR-1 compliant.

[maxbucknell]

Another idea I had was the possibility of rendering HTML for invoices, and then relying on the browser's print feature.

Unfortunately, there are issues with the way browsers print that preclude this working without redesigning things. I've attached a simple invoice for reference, and had a play at recreating this on JSBin.

The first problem I saw was that the browser will try to print a header and footer of its own, containing things like the printed URL, the time of printing, etc. This would be unsuitable, but a new feature of CSS allows this to be removed using the @page CSS at-rule. This is only supported by Chrome and Firefox, and so doesn't meet Magento's requirements for browser support. I'm not sure whether or not these can be bent for the backend, but I'd guess no.

The second problem I found is that the browsers generally refuse to print dark backgrounds, as seen in the header. This too is fixable, but only in Webkit and Chrome with the prefixed -webkit-print-color-adjust.

These issues are annoying, because they probably won't be issues in 18 months time, but we need a solution now, but in the long term, this would be a vastly preferable way of generating PDFs, since it hugely simplifies the process of customisation.

[maxbucknell]

In the meantime, basing a Magento standard API on the features available in Zend_Code seems like a good way to go, to reduce the cost of porting Magento's codebase.

However, given the above issues, it might be worth considering PHP 7.2 support with Zend_Pdf.

I'm going to do something else and wait for a response from somebody who can actually make decisions, though.

[buskamuza]

we should build some interfaces that we can implement, so that replacing this library later on becomes a little bit easier

This is a must if/when we change anything.

IMO, as both Zend_Pdf and tecnickcom/tcpdf are not supported, I'd stay with Zend_Pdf because this is something we already use. Unless tecnickcom/tcpdf provides more features and we need them.

@piotrekkaminski, what do you think about HTML-based PDF as @maxbucknell described above?

[buskamuza]

And yes, we will go with Zend_Pdf for now. It doesn't stop PHP 7.2 support.

[buskamuza]

Didn't try it out, but another lib that converts HTML to Pdf - https://github.com/dompdf/dompdf