Contrib.social

DomPdf stops on encountering an unrecognised CSS property and should not

Open on Drupal.org →
Created on 22 November 2022, almost 2 years ago
Updated 4 July 2023, about 1 year ago

Problem/Motivation

The DomPDF library only supports CSS2 and some CSS3 properties as indicated on its project page. This is fine, but in its current implementation this module completely stops processing when an unrecognised CSS3 property is encountered with a bunch of errors like this:

Error generating document: Failed to generate PDF: 'box_sizing' is not a recognized CSS property., 'hyphens' is not a recognized CSS property., 'hyphens' is not a recognized CSS property., 'text_shadow' is not a recognized CSS property.

Steps to reproduce

I wish my PDF to look like the regular website, so I feed the same CSS as the regular website (to avoid having to maintain two different stylesheets).

I have created a subtheme of Bartik, and use its global-styling library as entity print CSS like so:

# mytheme.info.yml
...
base theme: bartik

libraries-extend:
  bartik/global-styling:
    - mytheme/custom-styling
    
entity_print:
  node:
    all: 'bartik/global-styling'

After this, PDF generation is broken and clicking the link redirects back to the entity and the above errors are shown in a warning message. When using the debug path, all is fine and looks great.

Proposed resolution

The DomPdf library uses two global variables for processing all errors encountered when rendering the PDF: $_dompdf_warnings and $_dompdf_show_warnings. All encountered issues are writting to the first, and the second variable indicates if they should be shown or not. This is FALSE by default. DomPDF happily parses what it can and returns a PDF file.

The DomPDF plugin that comes with this module does not take the global $_dompdf_show_warnings into account and only reads $_dompdf_warnings and is therefor inconsistent with the behavior of the library. There is no way to suppress these warnings and users never get to see the PDF that was created.

I believe that Drupal\entity_print\Plugin\EntityPrint\PrintEngine\DomPDF::getError() should check if $_dompdf_show_warnings is true, or maybe better, use a module configuration value to determine if error processing is desired. It could be as easy as this:

  /**
   * {@inheritdoc}
   */
  protected function getError() {
    global $_dompdf_warnings, $_dompdf_show_warnings;
    if (is_array($_dompdf_warnings) && $_dompdf_show_warnings) {
      return implode(', ', $_dompdf_warnings);
    }
    return FALSE;
  }

I could also argue that warnings should not be treated as errors, but I can understand that this module does not make this differentiation.

Remaining tasks

Decide on the solution.

User interface changes

Possibly a debug setting checkbox?

API changes

None.

Data model changes

None.

🐛 Bug report
Status

Fixed

Version

2.0

Component

Code

Created by

🇳🇱Netherlands Neograph734 Netherlands

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024