cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John M. Wargo" <>
Subject Re: Camera API
Date Wed, 28 Aug 2013 23:45:13 GMT
I could spend some time working through the permutations on a few platforms (Android, BB 10,
iOS and Windows Phone), but will be a while before I can get to it - I've got a day job and
I'm trying to finish writing a book with three chapters to go and a deadline approaching.

If nobody else can get to it before then, then I'll make that my first doc contribution.

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 <> 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 <> 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" <> 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 <> 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?

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