For future readers who are viewing this post, this bug still exists at 2.12. Here's a visual example of the bug, screenshot from a pdf that I created using the Print Composer. All layers, as well as the Bing imagery basemap, were EPSG:3857 (WGS 84 / Pseudo Mercator). I've noted in red how the underlying imagery had shifted. This shift only occurs in the Print Composer output; everywhere else it aligned correctly. It sure looks like some sort of datum shift:
But it's not a datum shift. It's a Print Composer bug that shifts the map location of any (all? I'm not sure. At least Bing Aerial) OpenLayers basemap when exported to a pdf (png, too, I think). But this shift only occurs if there's a margin around the map in Print Composer - ie the map area is smaller than the paper size. Even by a millimeter (wierd, huh?)
Fortunately, Shankar's explanation (thanks!) provides a workaround. I'll expand his answer with these details:
To work around the bug, if you add a map to the Print Composer that contains an OpenLayers basemap, the map must fill the entire page size, without any margin (this is unfortunate, because white space around the map can help visually). To fill the page, go to the map's Item Properties panel (View > Panels > Item Properties, checked on). Expand the "Position and size" section. Note the X, Y, Width, and Height boxes; they define the map's origin point and extension on the page. Since we want the map size to equal the page size, we enter the page size values. For example, A4 paper dimensions are 210 mm x 297 mm (http://www.papersizes.org/a-paper-sizes.htm). So for a portrait-oriented map, enter:
X = 0,
Y = 0,
Width = 210,
Height = 297
- these values assume that the "Reference Point" is checked to the northwest box.
Notice how the map fills the entire page. Now when you export to a pdf, the underlying basemap image will not be shifted.
