cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John M. Wargo" <jwarg...@gmail.com>
Subject Re: Camera API
Date Thu, 29 Aug 2013 00:55:01 GMT
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 <wjamesjong@gmail.com> 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 <raycamde@adobe.com> 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" <wjamesjong@gmail.com> 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 <john@johnwargo.com> 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?
>>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message