Gmap & PDF

Hi, again

There is yes, but first you must make it show up in the printer-friendly web version.. In your previous bug (#217439: Include Java-script in the header so that e.g. Google-maps, can be printed) you weren't able to make it using the module, so I am guessing that you're still doing your way..

There's a reason why the modules are bundled. They all use the simpler HTML version as the input, so if you can't make it work with that, then it's not possible to use the sub-modules.

João

Hi,

If you have the web version working, the fact that it doesn't show the map in pdf means that the object rendering is not working inside the PDF library. Which one are you using? Try the other, anyway :) I would guess dompdf stands a better chance of rendering the map correctly..

Unfortunately, the only general solution for such a thing would be to have this module to render all objects into images and replace the whole object tag with a static img tag. I don't even know about a generic way to do that.

João

Well, in your case, there is actually a solution:

code.google.com/apis/maps/documentation/staticmaps/

Using this as a fallback in case the object isn't rendered would still show an image. The flash player in my homepage works like this and the static image is correctly output to PDF.

João

No real advice...

I see two options:

1. Hack dompdf to have a default extension (probably easier and since dompdf hasn't been updated in years, probably stable)
2. Hack the module to fetch the image and replace the static URL with the image (complicated and you'd have to update the module each time I created a new release)
3. Ask Google to include an extension to the file (ideal, but it might take a loooong time)

João

I think the same issue applies to tcpdf. It also tries to figure out the image type from filename extension. In the tcpdf code it does this far before it actually gets the image via the URL, and it seems that there's no easy way to create a hack that would allow the use of the mime-type from HTTP headers of server's reply. This came up with Google Charts, but most likely concerns static GMaps, too. As suggested in #6, the first option for default file type hack is probably the only way to go here, too.

Yes, but in TCPDF's case, you can actually try to have it fixed by the author, as it is still actively maintained.

João

Any tips on "Hack dompdf to have a default extension"? Which file, line? what did you change? Thanks!

update: file image_cache.cls.php line 69 (i think)

Nevermind: http://drupal.org/node/190173#gmap no, still no luck, red cross :(

Problem with dompdf is when it tries to save image in cache like this $image = file_get_contents($url); where $url is proper, working url of static map, but result fails next test

if ( strlen($image) == 0 )

there it dies and goes to hell :,( i did hack file extension and it is gif, same as static map, but that file_get_contents fails i think.

Hello, I'm an active developer of the DOMPDF project.

Did you try to use the latest release of DOMPDF (0.6 beta 2) ?
http://code.google.com/p/dompdf/downloads/list

It has a huge list of new features and bug fixes: http://code.google.com/p/dompdf/wiki/ReleaseNotes

Some of them are related to the images handling and may make this plugin work as expected.

Hi PhenX, nice to see you here!

Yes, I do use 0.6 beta 2 and all I get is red cross. I did some digging in 0.5.2 and it depended on file extension, google does not provide file extension for static map. Is it still so in 0.6 beta 2?

Here is html and result, just in case it helps.

<img src="http://maps.google.com/staticmap?key=ABQIAAAAXU-Dfe413Z95tTm2puFfeBTJ_lRpSdYTUGQZoJSau7xuivzxWhQkWuEd6HYqSIKpzlvqd0rJT-gYxw&amp;size=300x300&amp;maptype=roadmap&amp;format=gif&amp;sensor=false&amp;hl=de&amp;markers=48.109816,16.310255,red&amp;center=48.109816,16.310255&amp;span=0.0087,0.006732" alt="http://maps.google.com/staticmap?key=ABQIAAAAXU-Dfe413Z95tTm2puFfeBTJ_lRpSdYTUGQZoJSau7xuivzxWhQkWuEd6HYqSIKpzlvqd0rJT-gYxw&amp;size=300x300&amp;maptype=roadmap&amp;format=gif&amp;sensor=false&amp;hl=de&amp;markers=48.109816,16.310255,red&amp;center=48.109816,16.310255&amp;span=0.0087,0.006732">

PhenX, thanks for showing up here.

This is clearly a problem that can't be solved in this module's side, so I'm closing the issue. If there isn't one yet, you should create a bug in dompdf's issue queue.