I went back and looked at the manuscript for PhoneGap Essentials and back then
(a year and a half ago) I had tested this and wrote the following:
"The targetHeight & targetWidth parameters are supposed to control the height and
width of the image obtained using getPicture. In my testing though, the parameters did not
affect the resulting picture. The documentation says as well that the parameters must be used
in conjunction with each other and that aspect ratio is maintained. This further reinforces
that these options cannot work as documented (which my testing has proven) since it doesn't
make sense that you have to set both height and width while at the same time maintaining an
aspect ratio for the picture. If it truly was maintaining aspect ratio, then I'd expect that
only one of the values would be able to be set. To truly maintain aspect ratio, you'd only be
able to set either targetHeight or targetWidth, not both."
Anyway, I'll do some testing again and post the results.
On 8/28/2013 12:15 PM, Shazron wrote:
IMO first step would be that we find out what the existing implementations
actually do, and doc them
do our standard deprecation dance and implement the new shiny and correct
functionality
On Thu, Aug 29, 2013 at 12:04 AM, James Jong <[email protected]> wrote:
Several ways we could go here. One is to improve the documentation. iOS
chooses the larger image size. I'm not sure if all the platforms do it the
same way. I'd be happy to update the doc if it's all the same. Second is
to modify the implementation to only require either W or H. Note that we
would break backwards compatibility there.
-James Jong
On Aug 28, 2013, at 10:16 AM, Ray Camden <[email protected]> wrote:
As a user though, that doesn't necessarily make sense. You are saying,
"You must give me a H and W, but I'm going to maintain the aspect ratio
no
matter what." Given that, which side is "corrected" if I pass a H and W
that do not maintain the aspect ratio? Do we document it? I've worked on
another platform that provides a way to pass a H and W that act as a
bounding box, so if I use 150x150, my final result will be no bigger than
150x150, but possibly smaller in order to maintain aspect ratio. If that
is what PG is doing, then the docs should clearly spell that out. Maybe
it
is assumed by "Aspect ratio remains constant", but I think it could be
clearer.
On 8/28/13 9:04 AM, "James Jong" <[email protected]> wrote:
You're right that it could be calculated based on one or the other. The
code expects both today. I think the point is to be clear that the
aspect ratio is maintained, so that the user does not expect to be able
to arbitrarily set both.
-James Jong
On Aug 28, 2013, at 7:15 AM, John Wargo <[email protected]> wrote:
I've got another silly question. In looking at the Camera API, I see
the following:
targetWidth: Width in pixels to scale image. Must be used with
targetHeight. Aspect ratio remains constant. (Number)
targetHeight: Height in pixels to scale image. Must be used with
targetWidth. Aspect ratio remains constant. (Number)
I'm not getting why targetWidth MUST be used with targetHeight (and
visa versa) when aspect ratio remains constant. If aspect ratio remains
constant, then setting one automatically forces the other - that's the
whole point of maintaining aspect ratio, right? If the API is
maintaining aspect ratio while sizing the image, then forcing the
developer to specify both parameters is simply wasted work.
What am I missing here?
