Print view not using custom css or module css [#1110046]

Comment	File	Size	Author
#2	custom_css-1110046-2.patch	939 bytes	guillaumev

#1	1110046.patch	562 bytes	essbee

Comment #1

essbee CreditAttribution: essbee commented 30 March 2011 at 00:57

Status:

Active

» Needs review

File	Size
1110046.patch	562 bytes

Patch attached. Checks that the css file being unset isnt actually the css file added via the custom option.

Allows user to still keep their custom css file in their themes directory (previously would be unset).

Log in or register to post comments

Comment #2

guillaumev CreditAttribution: guillaumev commented 13 April 2011 at 13:23

File	Size
custom_css-1110046-2.patch	939 bytes

This first patch does not work. I'm proposing another one to solve the issue...

Log in or register to post comments

Comment #3

garnett2125 CreditAttribution: garnett2125 commented 20 April 2011 at 20:56

Category:

bug

» support

Hi guys,

I'm trying to make any css file working on the pdf that is generated by this module but its still not working. I've try with the last patch you gave us guillaumev but no happy end. Does it works on your sides ?

Thanks

Log in or register to post comments

Comment #4

essbee CreditAttribution: essbee commented 28 April 2011 at 07:23

Well this was all working fine, now I can't get dompdfto render anything but inline css. Just seems to ignore all @imports, I even debugged and checked the $html being passed and the css are their... No idea.

Log in or register to post comments

Comment #5

ts145nera CreditAttribution: ts145nera commented 28 April 2011 at 09:53

work for me. Thank you

Log in or register to post comments

Comment #6

sdsheridan

he/him/his

CreditAttribution: sdsheridan commented 28 April 2011 at 15:25

All:

Check out http://drupal.org/node/968016#comment-4404402 . I believe I've solved the issue for 6.x-1.12.

Shawn

Log in or register to post comments

Comment #7

essbee CreditAttribution: essbee commented 28 April 2011 at 23:47

I went a different route to solve the same problem, which involved removing code rather than adding more.

Currently in print.pages.inc in _print_var_generator() if the page is being sent by email it embeds the CSS. I simply commented out the if statement (lines 196, 206-209) so that it embeds the CSS in all scenarios. This ensures the PDF doesnt even need to download css files.

Possibly worth considering, maybe not for all, but at least for PDF generated pages.

Cheers,
Sam

Log in or register to post comments

Comment #8

PixelClever CreditAttribution: PixelClever commented 8 June 2011 at 22:33

Category:

support

» bug

This is definitely a bug report not a support request. I've confirmed the same issue in dompdf and tcpdf in the 6x branch. I suspect it is an issue related to the path to the css file.

P.S. For those posting in the issue queue, you should be aware that changing the status to a "support request" can prevent the issue from getting noticed by the maintainer. Many maintainers (myself included) don't respond to support requests at all.

Log in or register to post comments

Comment #9

essbee CreditAttribution: essbee commented 9 June 2011 at 02:01

Is there any reason not to go down the embedded CSS per #7?

I think embedding the CSS prior to PDF generation completely solves any of these type of issues. It works well for the email routine so the code is already there - in fact it actually reduces the amount of code overall.