Last Comment Bug 282434 - fails to correctly print route maps in Google Maps
: fails to correctly print route maps in Google Maps
Status: RESOLVED INVALID
: qawanted, testcase
Product: Core
Classification: Components
Component: Printing: Output (show other bugs)
: Trunk
: All All
: -- normal with 9 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jet Villegas (:jet)
Mentors:
http://maps.google.com
: 323345 (view as bug list)
Depends on: 141656
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-15 22:10 PST by Hal Mozer
Modified: 2014-01-16 08:43 PST (History)
11 users (show)
moz: wanted1.9.1?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
screenshot google-maps print preview (43.51 KB, image/png)
2007-10-08 19:06 PDT, j.j.
no flags Details

Description Hal Mozer 2005-02-15 22:10:58 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

When I try to print a route map in Google Maps beta, the map and text directions
print OK, but the route line, which shows on the screen, fails to print and
fails to appear in the print preview. I tred printing on both a Samsung laser
printer and an HP 990Cse Deskjet printer and the same problem occurred on both
printers.

Reproducible: Always

Steps to Reproduce:
1.open maps.google.com
2.select starting and ending addresses and display the map
3.view the map in print preview
4.print the map 

Actual Results:  
After step 2 the map, including the route, displayed correctly on my screen.
After step 3 the map displayed, but without the route line. After step 4 the map
printed, but without the route line.

Expected Results:  
Correctly displayed the map and route line in Print Preview and correctly
printed the map with route line.
Comment 1 Eric Allen 2005-02-27 13:46:56 PST
I get the same thing with

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050226 Firefox/1.0.1

Also, the start and end markers don't have transparency so the map doesn't show
behind them.
Comment 2 jag (Peter Annema) 2005-02-28 15:29:05 PST
Same problem on Mac.

The start and end marker problem is bug 141656. Dunno what is causing the
problem with the route-line itself.
Comment 3 isaacg 2005-03-01 22:45:54 PST
My guess is that transparent PNG's aren't being included in the printing.  The
marker shadows are also not printed.  BTW, Google Maps does print correctly in
IE6SP2.
Comment 4 Jon Baumgartner 2005-04-07 13:18:24 PDT
Any thoughts on this? This is another reason I need to keep IE around. FWIW,
this works in Camino.
Comment 5 jpl24 2005-04-24 15:49:03 PDT
I was about to write that this is not a firefox bug, as the mapline image is
explicitally styled not to print using the noprint class(display:none for media
type print). But after removing the noprint class from the image, it looks like
google is working around a firefox bug. Print preview looks correct and includes
the map line, but the printout has a big square black box for the transparent
pixels of the mapline image. So this is a dupe of bug 141656, the same bug that
jag commented was causing the start and end market problem.
Comment 6 Hal Mozer 2005-09-10 20:39:59 PDT
(In reply to comment #5)
> I was about to write that this is not a firefox bug, as the mapline image is
> explicitally styled not to print using the noprint class(display:none for media
> type print). But after removing the noprint class from the image, it looks like
> google is working around a firefox bug. Print preview looks correct and includes
> the map line, but the printout has a big square black box for the transparent
> pixels of the mapline image. So this is a dupe of bug 141656, the same bug that
> jag commented was causing the start and end market problem.

Is anyone at Mozilla addressing this bug?
Comment 7 Carlo Alberto Ferraris 2005-11-14 07:48:17 PST
(In reply to comment #3)
> My guess is that transparent PNG's aren't being included in the printing.  The
> marker shadows are also not printed.  BTW, Google Maps does print correctly in
> IE6SP2.

Satellite view is also affected. In print preview (and spool viewer) instead of the images a solid black box is displayed.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
Comment 8 Mike Cowperthwaite 2006-04-09 10:53:38 PDT
*** Bug 323345 has been marked as a duplicate of this bug. ***
Comment 9 Evan McLain 2006-10-06 20:17:34 PDT
Note that bug 141656 is linux-only, but this problem also exists on Windows.
Comment 10 Gabriel Chadwick 2006-11-28 19:56:39 PST
Get it to with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061128 Minefield/3.0a1.
Comment 11 Elijah Lofgren 2007-05-10 12:57:01 PDT
Reproduced with: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)
Comment 12 Robert Bradbury 2007-07-19 22:28:59 PDT
I'll confirm that the bug occurs in Firefox 2.0.0.4 under Gentoo Linux.
The same problem occurs with the same route from mapquest.com and maps.google.com so whatever the problem is it it seems directly related to how they "paint" the route on top of the displayed map.

I'd rate this as a critical in that it makes Firefox (& related browsers) almost useless when working with sites that provide maps with directions and routes.  Seeing the route on the map is essential to planning possible alternate routes that one might feel are better (typical directions are generally far from perfect if you have a general knowledge of the area).
Comment 13 Jeremy Morton 2007-07-21 02:17:50 PDT
Bug 141656 has been marked RESOLVED FIXED.  The real open bug on this problem is bug #191099, which is still open.  I'd love to see that fixed.  Any print gurus around?
Comment 14 Smokey Ardisson (offline for a while; not following bugs - do not email) 2007-07-21 12:09:43 PDT
(In reply to comment #4)
> Any thoughts on this? This is another reason I need to keep IE around. FWIW,
> this works in Camino.

Just to clarify, Google Maps directions print as expected in both Camino *and* Firefox/Mac.  Someone poked #camino about this today, and my Camino 1.8branch nightly and Firefox 2005 print virtually identically (as does the GPa7pre I had sitting around), no black spots or white spots or anything of the sort.

Given that all development in core areas like printing has stopped on the 1.8branch (Firefox 2.0.0.x), you should be sure to check the latest trunk nightly (Minefield) or milestone (GranParadiso); it's possible that the switch to Cairo has fixed whatever printing/widget or gfx bugs were causing this on Windows and/or Linux (which sounds to me like bug 191099).
Comment 15 Robert Bradbury 2007-07-23 15:14:09 PDT
I'll confirm that this bug is still in the CVS source tree (3.0a7pre) extracted on 19 Jul 2007 under Linux.  If this really works on the Mac, the question would be why?  It is my understanding that the Mac is using pretty much the same browser code and library code as that used under Linux (or is that a gross misconception on my part)?

It is true that does seem to be some kind of transparent image overlay to printer format problem in that in the blue "route" traced on the screen I can clearly see the text written on the underlying roads.  But in the resulting printout I only see the text on the roads, no blue route line overlaying them.  Could it be a resolution issue? (I'm using an inkjet printer and the printed resolution seems poorer than the screen resolution.)
Comment 16 Jeremy Morton 2007-07-23 15:34:05 PDT
(In reply to comment #15)
> I'll confirm that this bug is still in the CVS source tree (3.0a7pre) extracted
> on 19 Jul 2007 under Linux.  If this really works on the Mac, the question
> would be why?  It is my understanding that the Mac is using pretty much the
> same browser code and library code as that used under Linux (or is that a gross
> misconception on my part)?

I was talking to someone on #camino about this the other day.  It seems to be to do with the way the various OS printing systems work.  Mac uses PDF to render graphics on screen, and to print.  Windows uses GDI to render on screen, PostScript (similar to PDF) to print.  The way he put it:
[19:59] <ardissone|away> but Mac graphics is "basically" PDF
[20:00] <ardissone|away> so where on windows moz would have to do GDI->PS to print (or whatever)
[20:00] <ardissone|away> on the Mac, PDF -> PDF

Therefore, the Mac printout appears the same as it is rendered on screen (correctly), whereas there are plenty of possibilities for bugs on Windows when the GDI rendering is being converted to PS.  Lack of image transparency appears to be one of them.
Comment 17 Elijah Lofgren 2007-09-05 19:20:04 PDT
This bug seems to new be fixed for as of today. Maybe Google fixed it? :)

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty)
Comment 18 mozbug1 2007-09-05 20:17:10 PDT
It doesn't work for me in 2.0.0.6
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Comment 19 j.j. 2007-10-08 14:33:22 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007100804 Minefield/3.0a9pre

I see this bug on current trunk (FF 3), at least in print preview (haven't printet)

Reporter (or someone else with permission), please change
Product >> Core
Component >> Printing
Version >> Trunk
Comment 20 Gabriel Chadwick 2007-10-08 16:59:49 PDT
This works for me on Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9a9pre) Gecko/2007100804 Minefield/3.0a9pre with a Deskjet 932c and also WFM withMozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9a9pre) Gecko/2007100705 Minefield/3.0a9pre ID:2007100705 but only tested with print preview.

For me this looks like it is fixed on windows...
Comment 21 j.j. 2007-10-08 19:06:15 PDT
Created attachment 284080 [details]
screenshot google-maps print preview

Using today's Minefield from comment 19 on winXP and this testcase:
http://maps.google.de/maps?f=d&hl=de&geocode=&saddr=galgenhof&daddr=bulmannstr+6,n&sll=49.443124,11.085264&sspn=0.006739,0.014591&ie=UTF8&z=17&om=1
I have 3 issues:

1. The blue route isn't drawn in print preview (printing not tested).
   This is what this bug is about.
2. The single images are misaligned, causing 1px white lines and 1px
   overlapping in print preview. This is probably off topic here.
3. The start and finish flags are drawn, but haven't transparent background.
   Is this related to this bug?
Comment 22 Gabriel Chadwick 2007-10-09 06:46:56 PDT
Using testcase of comment #21 in Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9a9pre) Gecko/2007100804 Minefield/3.0a9pre ID:2007100804 . The printing preview works if you click the print function in the page but does not work if you try to print directly the initial page. So to get a good print you need to use the print function offered by google. This means I think that the initial bug comment #0 is still there.
Comment 23 Glenn Randers-Pehrson 2008-06-18 16:29:39 PDT
This bug still persists in Firefox 3.0  The blue route is missing in the direct print (firefox>file>print) but present when using the google print button.
Comment 24 timeless 2008-12-13 09:16:20 PST
i wasted more than enough time looking. the blue route can be printed by firefox if it isn't hidden by google's css. tested w/ 20081213032835 + a printer driver called: "Foxit PDF Creator Version 2.0.0 build 0725".

the shadows for the markers can also be printed. and if you investigate, the gray box for the marker is really part of something which can appear in the browser view.

if you have a problem with a page, create a reduced testcase. if you have a problem w/ a google application (and google maps is a google application), file a bug with the vendor (google).
Comment 25 Jeremy Morton 2008-12-13 10:53:16 PST
I've investigated this, and come to the conclusion that Firefox's behaviour is correct, and Google Maps' code is incorrect.  My full explanation is here:
http://www.game-point.net/misc/googlemaps/

Please bug Google Maps to fix their code.  I have no idea why they tell the browser to print non-transparent GIFs instead of the perfectly good transparent PNGs used on the browser screen.

Note You need to log in before you can comment on or make changes to this bug.