When I set the h/w to, for example, 320x365 (for capturing the canvas of an iPhone-targeted site in portrait mode), the actual screengrab ends up being 8xx by 8xx anyway. I've worked around this locally by adding an -iphone option that overrides options.[height, width, initHeight, initWidth], but in an overtly hacky way.
use --scale=1 ;)
Hmm, that didn't work. It might be a byproduct of the page being designed wrong, but that still yielded a screenshot at 800x864px.
can you post the command line instruction? I would like to test it since I'm starting with webkit2png and solve this kind of stuff will help us all
Here's the command I used:
webkit2png --scale=1 -o foo "http://www.comcastoffers.com/?exp=mobile"
The quotes are necessary because of the query string param. Like I mentioned above, I dropped in a dirty hack that allows --iphone to constrain the parameters to 320x365. In main():
options.initWidth = options.width = 320
options.initHeight = options.height = 365
would this command give you a foo-clipped.png file that works for you?
python wk2png --scale=1 -o foo --width=320 --clipwidth=320 --clipheight=365 http://www.comcastoffers.com/?exp=mobile
It looks like it, yeah. I'll have to try it with an unhacked webkit2png, though. I might have overloaded settings elsewhere; I'm not sure.
It looks to me like --scale=1 --width=320 --clipwidth=320 gives the output you want, but it seems wrong that it should take so many options to get this to work. I'm going to think about ways to make this better.
--scale=1 --width=320 --clipwidth=320
The --clipwidth=320 doesn’t seem to be required:
webkit2png -Fs 1 -W 320 "http://mathiasbynens.be/"
This creates mathiasbynensbe-full.png that is 320px wide.
But still this is quite painful. Why is -s/--scale needed here?
-s is needed as webkit2png currently makes the initial browser size bigger to ensure that the clipped images are always exactly the requested size. By default the clipped image is 200px wide, at a scale of 25%, so webkit2png increases the browser size to 800px to make sure there's enough webpage to capture. Alternatively, you could pass --clipwidth=1 and no scale option and it would work.
This might have made sense when this code was first written 9 years ago (before the iPhone, when we were debating "Fixed", "Elastic" and "Fluid" designs) but it doesn't make any sense now. In particular there's no reason for this restriction to apply when no clipped image is requested, but it does. This should give a 320-wide image, but doesn't:
webkit2png -F -W 320 "http://mathiasbynens.be/"
The challenge is how to fix this without breaking the behavior of the "clipped" images. As I mentioned in #32 I've been meaning to rethink the distinction between clipped, thumbnails and full size images for some time (most people need just one, generating all three by default is wasteful behavior) and I think this issue might be what tips me over into making that change.
But until then, at least there's a crappy workaround.
I just left a long comment on a related pull request (#66) that proposed a solution to some of the issues brought up here, and I'd love some feedback on it from the people that have been affected by this bug.
Specify scale and clip width to force window to a particular width. See
paulhammond/webkit2png#12 and paulhammond/webkit2png#66 for details of
the underlying webkit2png issue.