unable to cofigure / use logo [#297198]

I'm trying to cofigure the module to print a custom logo. It seems neither the direct image path nor the 'upload image' widgets work, because of their respective interpretation of the path(s).
The direct path doesn't work, as an absolute path isn't considered to be absolute, but is prefixed with something looking like the current DOCUMENTROOT variable (it's not the drupal install directory, or its 'files/' subdirectory that other modules would use in such cases).
The 'upload image' widget doesn't seem to do anything, as the resulting image location is invalid, too. (It points to a non-existant directory.)

Thanks,
Stefan

Comments

Comment #1

jcnventura CreditAttribution: jcnventura commented 20 August 2008 at 11:05

Status:

Active

» Postponed (maintainer needs more info)

Hi,

This is all very strange.. Whatever you put in the logo URL directly, it will come out in the generated printer-friendly page. So if you put an absolute path like /files/logos/print_logo.gif it will come out like this:

<div class="print-logo"><img class='print-logo' src='/files/logos/print_logo.gif' alt='' />

I don't see how it can go wrong. And certainly, there is no DOCUMENTROOT variable there..

The upload image indeed prefixes the path with the base_path() of your site and places the file in your files directory. What non-existent directory did your file get placed in?

João

Comment #2

stefan_seefeld CreditAttribution: stefan_seefeld commented 20 August 2008 at 13:47

I tried setting a 'user-specified' logo, providing an absolute path (no URL).
Then, clicking on the 'pdf' link for a given document, I'm presented a page with a single line of error message (i.e. no pdf), reading:

TCPDF error: Can't open image file: /var/www/html/drupal/files/print_logo.png

And this is why I imagined the DOCUMENTROOT might come into play, as I couldn't figure any other way the '/var/www/html/drupal/' prefix above slipped in. The filename I provided to as user-specified logo was '/drupal/files/print_logo.png'

Comment #3

stefan_seefeld CreditAttribution: stefan_seefeld commented 20 August 2008 at 13:53

And (just to be clear): my drupal installation path is /usr/share/drupal64, not /var/www/html, so this prefix really looks suspicious to me...

Comment #4

jcnventura CreditAttribution: jcnventura commented 20 August 2008 at 14:17

You should have mentioned before that this was for a TCPDF generation..

TCPDF is weird in the sense that to find where an image is, it tries to replaces the var K_PATH_URL in the image URL with the contents of the K_PATH_MAIN...

K_PATH_URL is set to $base_root and K_PATH_MAIN to DOCUMENT_ROOT...

So for an image located at http://myhost/path/files/image.gif, if the $base_root is http://myhost/path, then it will try to get the file from DOCUMENT_ROOT/files/image.gif..

I was the one that configured the variables like that, so it's my fault.. I just fail to see how it can be that your DOCUMENT_ROOT has nothing to do with your Drupal installation. Surely your web server must be able to resolve where Drupal's index.php file is somehow..

João

Comment #5

stefan_seefeld CreditAttribution: stefan_seefeld commented 20 August 2008 at 15:22

Indeed. Apache does the rewrite. It knows that localhost/drupal/ (the base URL for my drupal test suite) maps to /usr/share/drupal64/ (the installation path for my drupal site).
/var/www/html is the root for the webserver without redirection, so I'm not sure how this comes into play. May be the print module generates an URL from the (absolute) filename I specified, and apache then maps that (prefixing with the DOCUMENTROOT) ? How does the print module distinguish absolute URLs from absolute filenames ? Should I use file:/// syntax ?

Comment #6

jcnventura CreditAttribution: jcnventura commented 20 August 2008 at 16:28

As I said, TCPDF is responsible for string replacing it's configuration variables..

One of those variables is set inside the module's code to DOCUMENT_ROOT, as that works for 99.99% of all people. You're in the other 0,01%.

I need to see if there's a way that I can get to 100%, by using something other than DOCUMENT_ROOT, but there's no way to escape the fact that TCPDF is doing this stupid string replacement which it shouldn't be doing in the first place.

João

Comment #7

jcnventura CreditAttribution: jcnventura commented 20 August 2008 at 16:38

Status:

Postponed (maintainer needs more info)

» Needs review

Hi,

I think I have it.

Can you please patch your site with the following and test if it solves your problem?

diff -u -r1.1 print_pdf.pages.inc
--- print_pdf.pages.inc 14 Aug 2008 12:00:30 -0000      1.1
+++ print_pdf.pages.inc 20 Aug 2008 16:37:19 -0000
@@ -108,8 +108,8 @@
   $pdf_tool_path = realpath(dirname($print_pdf_pdf_tool));

   define('K_TCPDF_EXTERNAL_CONFIG', TRUE);
-  define('K_PATH_MAIN', $_SERVER['DOCUMENT_ROOT']);
-  define('K_PATH_URL', $base_root);
+  define('K_PATH_MAIN', dirname($_SERVER['SCRIPT_FILENAME']));
+  define('K_PATH_URL', $base_url);
   define('K_PATH_FONTS', $pdf_tool_path .'/fonts/');
   define('K_PATH_CACHE', $pdf_tool_path .'/cache/');
   define('K_PATH_IMAGES', '');

Comment #8

stefan_seefeld CreditAttribution: stefan_seefeld commented 20 August 2008 at 17:18

I don't have any file called 'print_pdf.pages.inc'. However, I found print.pdf.inc, which looks similar, so I patched that instead. This seems to work fine. Thanks !

Comment #9

jcnventura CreditAttribution: jcnventura commented 20 August 2008 at 18:02

Status:

Needs review

» Reviewed & tested by the community

Hi,

I had forgotten about the post rc9 renaming of some files.. The +/-15 files in the module directory was annoying me, so I organized stuff a bit and harmonized the file names (actually, the only renaming was the print.pdf.inc to print_pdf.pages.inc).

Thanks for confirming that this works for you. I think this solution is more robust, so I will commit it soon. It will be in the next releases.

João