I was excited reading about the printer-specific page template support. Trying this out seems to suggest that this only works for the printer-friendly html rendering, but not the pdf generation. Is this correct ?
If so, is there an alternative way to customize the pdf generation ?

Thanks,

Comments

jcnventura’s picture

jcnventura
Primary language English
commented
Status: Active » Postponed (maintainer needs more info)

If you use dompdf, the PDF template is fully reused.
With TCPDF, due to it's limited support for CSS, etc., only the contents of the template after the header are used to generate the PDF.

If you want to create a PDF specific template, create a print_pdf.tpl.php file. It's recommended to start from the contents of the print.tpl.php file and work your way from that.

Hope this helps you.

João

stefan_seefeld’s picture

stefan_seefeld commented
Status: Postponed (maintainer needs more info) » Active

Thanks for the prompt reply !
I'm using tcpdf, and did add print_pdf.tpl.php files, both, to the modules/print/ directory, as well as to my theme directory. It doesn't appear as if either is picked up, as I can't see some test text I added to the templates. In contrast, customizing the printer-friendly templates ('print.tpl.php') works fine. Any ideas what I could be doing wrong, or how to debug this ?

Thanks

PS: The tcpdf project seems to be in more active development than dompdf. Your reply suggests dompdf might be functionally more complete. Would that be a better choice ?

jcnventura’s picture

jcnventura
Primary language English
commented
Status: Active » Postponed (maintainer needs more info)

Strange that it didn't pick the templates up.. I just tested it and it seems to be working..

Note that any text added before the print-content div will simply be obliterated.. I have to improve this somewhat, as it's a bit tied to my current template, but for now it's the rules of the game.

As to dompdf/TCPDF.. Yes, TCPDF is being actively developed (sometimes +2 releases per day). However dompdf renders a much more faithful rendering of the web page than TCPDF does.. TCPDF doesn't understand about CSS and some more advanced HTML stuff.

João

stefan_seefeld’s picture

stefan_seefeld commented
Status: Postponed (maintainer needs more info) » Active

Oh, that explains it ! Indeed, I can now confirm that 'it works'. The problem is that I wanted to remove things printed prior to the content (the 'created by' and other meta data on top). If that doesn't stem from the template, what generates that ? And, how can I remove it ?

As to dompdf, does this follow more closely the template, i.e. do I have more control over headers, meta data, etc. ?

Thanks,
Stefan

jcnventura’s picture

jcnventura
Primary language English
commented
Title: pdf generation not using templates ? » pdf generation using TCPDF not using templates ?
Status: Active » Postponed

dompdf generates all its contents from the template.. However, because of that, it has no notion of a page header and footer.. It's a lot closer to what you'd get if you used the browser's print button when viewing the printer-friendly version.

TCPDF did such a lousy job of displaying the template as it was, that I was forced to hardcode some of the stuff that goes into the template. There's lots of room to improve on TCPDF's rendering of the template, but I am trying to focus on getting all the features and architecture improvements at this point, so that I can finally release the 1.0 version one of these days.

I will keep this in the postponed queue as a reminder to myself to find a way to get TCPDF's output be less hardcoded (maybe via theming).

João

stefan_seefeld’s picture

stefan_seefeld commented

OK, thanks for the heads up. I think it would be useful to outline those things in the docs (even something as simple as a little issue list in the README).

Also, talking about formatting issues: is there a way to put markers into the input specifically targetted at the printer-friendly output (print or print_pdf) ? I have just defined a document type specifically designed to be used as an easily maintainable template for printed documents, so users can edit via their preferred input format, and then generate a pdf document from that. Having a means to inject pdf processing instructions (such as forced line breaks) would be very useful for that.

Thanks

jcnventura’s picture

jcnventura
Primary language English
commented

Hi,

I haven't completely understood your last request.. The problem in translating the HTML in the template to TCPDF is that they are not related at all.. I write all HTML via TCPDF's writeHTML method, so it's not very easy to place any type of marker, without TCPDF's support.

The one possibility that comes to my mind would be markers identified with like this: <!-- TCPDF: arg1 arg2 -->. The module could then split the HTML for each of these markers and call a themed function (e.g. theme_print_pdf_userfunc) passing as arguments the contents of the comment (and of course, the pdf object).

Is this what you're wishing for?

João

stefan_seefeld’s picture

stefan_seefeld commented

Hi Joao,

yes, that's exactly it. Specifically, I'd suggest to use processing instructions:

<? instruction here ?>

Or, if that doesn't work, a specially marked-up HTML comment, such as

I'm not sure whether this is possible at all, and if so, whether it has to be dealt with within the backends (dompdf or tcpdf), or whether you could preprocess the output, without interferring with the generated page layout.

(I can think of a number of useful processing instructions. For a start, a forced line-break would certainly be good. It could also be markers to inject other contextual information. This mechanism seems quite extensible to me.)

Thanks,
Stefan

jcnventura’s picture

jcnventura
Primary language English
commented

Just wanted to let you know that the original motive for the postponed status has now been 'fixed' and committed to the HEAD.

The TCPDF-generated content now follows the template completely, and can be fully customized via themed functions by the users.

The insertion of TCPDF calls through special comments will take some time more (specifically, #222926: HTML Corrector filter escapes HTML comments must be committed to Drupal core before I even start work on it, since people won't be able to use it until then).

João

jcnventura’s picture

jcnventura
Primary language English
commented
Status: Postponed » Fixed

Since a new issue was created for the final point, and the original motive for the issue has been fixed, I am changing the status on this issue.

João

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.