DomPdf stops on encountering an unrecognised CSS property and should not

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.