On 09/09/2010 10:25 AM, Marius Dumitru Florea wrote:
> On 09/09/2010 12:08 AM, Anca Luca wrote:
>>
>>
>> On 09/08/2010 11:40 PM, Marius Dumitru Florea wrote:
>>> Hi devs,
>>>
>>> Currently the image plugin [1] allows us to create image thumbnails by
>>> specifying the image width and/or height in the query string of the
>>> image attachment download URL:
>>>
>>> /xwiki/bin/download/Spage/Page/image.jpg?width=100
>>>
>>> I propose that we:
>>>
>>> (A) Use the image width and/or height (when they are specified in the
>>> image syntax using pixel unit) to resize the image on the server side.
>>> For instance:
>>>
>>> [[image:logo.jpg||width="100px"]]
>>>
>>> will be linked to
>>>
>>> /xwiki/bin/download/Spage/Page/logo.jpg?width=100
>>
>> If I remember correctly this would mean that we give special meaning to
>> some parameters (right now they are automatically copied to HTML
>> attributes of the element). I don't remember exactly why, but I think
>> this was an issue (Thomas? Vincent?)
>>
>
>> otherwise I would be +1 for this, image will be resized anyway, and
>> let's hope the image plugin can do it as well as the browser would (in
>> terms of quality of the result).
>
> For jpeg images there is the quality parameter that is configurable so
> you can set it to a value closer to 1 to preserve image quality.
>
> Also, I'm refactoring the image plugin to use a component for image
> processing. The default implementation will use javax.imageio and
> java.awt for decoding, scaling and encoding images. If you are not
> satisfied with the result you should be able to write a custom
> implementation using third party image processing libraries.
>
>>
>>>
>>> and
>>>
>>> [[image:logo.jpg||style="height: 50px; width: 70px"]]
>>>
>>> will be linked to
>>>
>>> /xwiki/bin/download/Spage/Page/logo.jpg?width=70&height=50
>>>
>>> The image plugin also accepts a quality parameter that controls the
>>> compression quality when encoding jpeg images. The default value of this
>>> parameter (i.e. when not specified in the URL) is configurable. I
>>> propose we use 0.3 by default, 1 representing the best quality.
>>>
>>> (B) Add the ability to limit the image dimensions (preserving aspect
>>> ratio) when the image width and/or height are not specified in the image
>>> syntax (or when they are not using pixel unit). The width and height
>>> limit will be configurable and -1 by default (i.e. no limitation). For
>>> instance:
>>>
>>> image:logo.jpg
>>>
>>> will be linked to
>>>
>>> /xwiki/bin/download/Spage/Page/logo.jpg?width=1024
>>>
>>> when width limit is 1024, and to
>>>
>>> /xwiki/bin/download/Spage/Page/logo.jpg?width=1024&height=768&keepAspectRatio=true
>>>
>>> when width limit is 1024 and height limit is 768. Note that in this case
>>> the image aspect ratio is preserved. The image is resized to best fit
>>> the limits. If the user want to bypass the limit he has to specify the
>>> image width/height in the image syntax.
>>
>
>> I would say we would need a way to bypass and say "original size", be it
>> a special value of the width (negative) or another method.
>
> If the image width/height limit is reasonable for a web page (you can't
> expect to display 3640x2736 images on the web) then you won't have to
> view the original image most of the time. And if you do want to view the
> original image then you can specify the (original) image width/height to
> bypass the limit (since this won't happen often it won't be an overhead
> for the user).

yes, but I'm talking about the situation when you don't know the image 
width and height, for example if a script generates the syntax.

I think in general is not a good idea to prevent the users from getting 
the original image, even if in most of the cases it's not that useful. 
If the users know what they're doing, they should be able to, with a 
special param or something, just as a general policy.

Thanks,
Anca

>
> Limiting the image width/height is very useful when users attach photos
> without resizing them first to a web-friendly width/height. Instead of
> downloading a few MB you'll be downloading just a few KB.
>
> Thanks for your feedback,
> Marius
>
>>
>> +0 for B
>>
>>>
>>> I'm +1 for both (A) and (B). WDYT?
>>>
>>> Thanks,
>>> Marius
>>>
>>> [1]
>>> http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/plugin/image/
>>> _______________________________________________
>>> users mailing list
>>> [email protected]
>>> http://lists.xwiki.org/mailman/listinfo/users
>> _______________________________________________
>> users mailing list
>> [email protected]
>> http://lists.xwiki.org/mailman/listinfo/users
> _______________________________________________
> users mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/users

Reply via email to