CSS styling shows on /debug HTML but not on PDF

Im experiencing the same issue.

Confirming the issue.

UPDATE: clearing cache after each change solved the issue for me (even though theme debugging is enabled).

Clearing the cache does not fix for me

Same issue here. Seeing the custom CSS in Debug but not in the generated PDF.

I got same problem.
All css applied correctly on /print/pdf/node/[nid]/debug, but all css styling lost on PDF.
Clearing cache doesn't fix this.

Same problem here. Any solutions?

I got same problem.
All css applied correctly on /print/pdf/node/[nid]/debug, but all css styling lost on PDF.
Clearing cache doesn't fix this.

I found this cause.
All css are compressed on generating PDF (/print/pdf/node/[nid]), but not on debug (/print/pdf/node/[nid]/debug).
NOTE: The css compress doesn't work correctly on my development environment with S3.

And I solved this problem with this issue's patch. (Turn off css compress.)

When using wkhtmltopdf, I've had success with the patch at https://www.drupal.org/project/entity_print/issues/2996197.

I just recognized that the active theme from where the PDF Print is triggered matters.
I programatically printed the PDF with:

    /** @var \Drupal\entity_print\PrintBuilder $print_builder */
    $print_builder = \Drupal::service('entity_print.print_builder');
    $print_builder->savePrintable([$entity], $print_engine, 'public', FALSE, FALSE);

and found out that in this case the active theme was the admin theme. So the entity_print module was looking for the css library in the wrong theme, because in my case the css library was located in the frontend theme.

When i used /print/pdf/node/[nid]/debug, the css was working fine. (Because the correct theme was used..)

@makkus183 where do you place the code in #11 cause when I look at the PDf generted it obviously using the admin theme. In my case am generating pdfr of a views page.

@ojchris37 i used the hook_entity_presave() in a custom module.
I implemented a switch of the active theme:

/**
 * Implements hook_entity_presave().
 */
function <MODULE_NAME>_entity_presave(Drupal\Core\Entity\EntityInterface $entity) {
  if ($entity->bundle() == '<BUNDLE>') {
    //    Change active theme to <THEME_NAME> to be able to use the containing templates.
    /** @var \Drupal\Core\Theme\ThemeInitialization $theme_initialization */
    $theme_initialization = \Drupal::service('theme.initialization');
    $active_theme = \Drupal::theme()->getActiveTheme();
    \Drupal::theme()
      ->setActiveTheme($theme_initialization->getActiveThemeByName('<THEME_NAME>'));


    /** @var \Drupal\entity_print\Plugin\EntityPrint\PrintEngine\ $print_engine */
    $print_engine = \Drupal::service('plugin.manager.entity_print.print_engine')
      ->createSelectedInstance('pdf');

    /** @var \Drupal\entity_print\PrintBuilder $print_builder */
    $print_builder = \Drupal::service('entity_print.print_builder');
    $print_builder->savePrintable([$entity], $print_engine, 'public', FALSE, FALSE);
    //    Change active theme back.
    \Drupal::theme()->setActiveTheme($active_theme);
  }
}

I also have this bug. The default CSS styles also don't apply in the PDF. Switching to the dev release does not help. I'm using the same theme for front end and admin. So, it's not the wrong theme loading.

It looks like TCPDF Engine does not load CSS with the 2.x release.

I got it working by upgrading to dompdf 1.x.

I am experiencing the same issue. I've already tried:

1. Overridding entity-print.html.twig and putting there inline CSS
2. Adding event subscriber with alterCss(PrintCssAlterEvent $event) method
3. Switching active theme as per comments above
4. Adding patches from 2996197 and 2971822

The CSS loads properly on /debug path, but not in generated PDF file.

We had the same issue, except when we uploaded the site to the dev and prod server, then it worked both on /debug page and PDF generating pages. We're using wkhtmltopdf.

After 2 days of debugging we found out that when using wkhtmltopdf with localhost domains, it could not connect to the local virtual host for the CSS files. We fixed that by adding the virtual host to the /etc/hosts file:

127.0.0.1 mysite.localhost
::1 mysite.localhost

Maybe it helps others, too.

Same problem here. Custom css styling works on:
/print/pdf/commerce_product/1/debug
But not on:
/print/pdf/commerce_product/1

- I have tried just clearing caches multiple times
- I have tried enabling / disabling css minifying via site performance settings
- I have tried patch from issue #2971822 and with and without 'Enable CSS Optimization'
- Have have tried adding {{ attach_library('mytheme/my-pdf-css-library') }} to both entity-print.html.twig as on the entity type's custom pdf view mode twig file thats used
- I have tried replacing the default entity print styling with my custom one by editing mytheme.info.yml file and adding:

libraries-override:
  entity_print/default: mytheme/my-pdf-css-library

Anything else I could try ? Does it maybe have to do something with the entity type (depsite the fact that the /debug works) ? Are there people that got it working on other entity types beside 'node' ? In my case I need to generate a PDF from a commerce_product entity type.

UPDATE

Decided to start from basic and replace my custom css with only:

body{
  color: red;
}

Now the generated PDF content was red, so that styling did work.

So in my case, some stuff in my original css (scss) seemed to cause the pdf to loose all styling.
Probably because of including bootstrap or something.
I am now in the process of creating a new css file from scratch trying to keep it as simple as possible without any includes.

I found that in my case the wkhtmltopdf binary was not able to fetch the styles from the server as the nginx had basic auth enabled.

There's an easy test you can perform if that's authentication issue or something else:

1. Make sure you have ssh access to the web server and you can run wkhtmltopdf binary.
2. Take the HTML from the /debug page and save it on the server as pdf_source.html
3. Run wkhtmltopdf pdf_source.html pdf.pdf
4. If wkhtmltopdf is able to fetch the styles from the web server, it will not produce any errors.
5. If wkhtmltopdf has trouble fetching the style files, you should see Error: Authentication Required or perhaps other message which indicates of the problem.

If it's the basic auth issue, enter the credentials in the Authentication section of the Entity print configuration page.

If you don't know the basic auth credentials or do not want to use them, you can tweak \Drupal\entity_print\EventSubscriber\PostRenderSubscriber::postRender() so that instead of setting the absolute URLs to the CSS files, it generates absolute path to the files on the file system (e.g., file:///var/www/mysite/web/sites/default/css/style.css).

Need preprocess_entity_print and add Your css.
Its work for me.
https://www.droptica.com/blog/make-pdf-any-entity-drupal-review-entity-p...

I can also confirm this problem. But it goes a bit deeper than simply having problems in the published version.
DomPdf has problems with many CSS things and currently other rendering problems related to variables.

I've found this here in @bsweeney's answer: https://github.com/dompdf/dompdf/issues/2828

That's why @flyke was able to render the 'color:red;' css without problems.

My theme was being loaded correctly by the rendering as well.

I've also had this problem. What worked for me was choosing to not optimize the CSS for the pdf. I've applied a patch from this issue: https://www.drupal.org/project/entity_print/issues/2971822. Maybe this will help someone.

Using entity_print:2.13, dompdf/dompdf:2.0.3

I also have an issue when using bootstrap 5.x as base theme. My main issue I faced was trying to change the font-family heading tags, e.g. h1, h2, etc in my print stylesheet.

I could see the changes on other elements e.g.

I am loading my font like so

@font-face {
  font-family: 'DanielBlack';
  src:  url('../fonts/daniel-black-webfont.ttf') format('truetype');
  font-weight: normal;
  font-style: normal;
}

This is then imported from my entiityprint-all.scss file which compiles to css/entiityprint-all.css

So I can change the body font e.g.

body {
  font-family: "DanielBlack";
}

but this does not seem to work.

h1 {
  font-family: "DanielBlack";
}

however this does seem to work ok:

h1 {
  font-size:20pt;
}

I get that dompdf does not support css variables etc and that there is no support for bootstrap 5. However I do not really understand why I can set the custom font on some elements, and not others.

I have also checked /tmp folder and can see that dompdf seems to recognise the fonts there in installed-fonts.json. This needs to be manually cleared as if you want to reset things there. I have also made sure that $headings-font-family is not set to null, and also moved

$font-family-code: 
$font-family-sans-serif: 
$font-family-monospace: 
$font-family-serif: 
$font-family-base: $font-family-sans-serif;

from typography to variables as this tends to be loaded first.

Further more I have removed references like this

$font-family-base: var(--#{$prefix}font-sans-serif);
$font-family-code: var(--#{$prefix}font-monospace);
$font-family-serif: var(--#{$prefix}font-serif);

Other things I have tried using the dompdf media query e.g.

@media dompdf {
  h2 {
    font-family: "DanielBlack";
  }
}

But unfortunately no success there either. As mentioned preview seems to work fine but there are other differences from the final generated pdf as far as ai can tell.

Not sure if i am missing anything obvious, or if the issues I am having actually stem from using Bootstrap 5.x base theme or not. I think the main issues there appear to be no support for flex box or grid as well as limited support for css variables. Not sure how that relates to this issue?

I have also tried the above patch e.g.disabling css optimisation

Ok I have recreated this issue locally. dompdf seems to set headings to use the default font or fallback.

I have added an issue here to try and clarify.

https://github.com/dompdf/dompdf/issues/3313

Turns out my problem could be solved by making sure that font-weight is set to 500 or higher on the @font-face declaration.

#17 worked for me