Marius Dumitru Florea wrote:
> On 09/09/2010 12:18 PM, Caleb James DeLisle wrote:
>>
>> Marius Dumitru Florea wrote:
>>> Hi Caleb,
>>>
>>> On 09/09/2010 02:22 AM, Caleb James DeLisle wrote:
>>>> 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
>>>> This seems to be fuzzing the line between url parameters and html
>>>> tag attributes. why not just use [[image:logo.jpg?width=100px]]
>>> First of all, you make the assumption that users know what a URL query
>>> string is. I don't fully agree with this. Then some users might get
>>> confused if there are two ways of specifying image width/height: should
>>> we put the width/height in the image reference or in the image
>>> parameters? Finally, writing:
>>>
>>> [[image:logo.jpg?width=100||width=50px]]
>>>
>>> makes no sense. Why would you want to download a 100px image when you
>>> display it at 50px only.
>>>
>>> Also, IMO wiki syntax is independent from HTML. When you write:
>>>
>>> [[image:logo.jpg||width="100px"]]
>>>
>>> "width" is a parameter of the image. This wiki syntax could be rendered
>>> in many formats. One of these formats is HTML, but it's not the only
>>> one. When rendered in HTML the width parameter is mapped to the width
>>> HTML image attribute but that doesn't mean we can't use the width
>>> parameter for other things, like adjusting the image URL.
>>>
>>> IMO what's really important is to honor user expectations. When a user
>>> writes:
>>>
>>> [[image:logo.jpg||width="100px"]]
>>>
>>> he expects to see the logo.jpg image displayed and its width to be
>>> 100px. My proposal doesn't change this. Resizing the image on the server
>>> is an optimization and I think most of the users will be happy with it
>>> (the page will load faster).
>> I can see the logic in this.
>> +1
>>
>>>>> and
>>>>>
>>>>> [[image:logo.jpg||style="height: 50px; width: 70px"]]
>>>>>
>>>>> will be linked to
>>>>>
>>>>> /xwiki/bin/download/Spage/Page/logo.jpg?width=70&height=50
>>>> Parsing CSS and extracting widths and heights for server side scaling?
>>> Yes, using http://cssparser.sourceforge.net/ .
>> 'IMO wiki syntax is independent from HTML. When you write [...]
>> "width" is a parameter of the image. This wiki syntax could be
>> rendered in many formats.'
>>
> 
>> After thinking it over I agree but now aren't we risking an too much
>>   dependence on CSS? It seems a bit odd to have a CSS parser for only
>> one job and specifying style in an html attribute is WCAG invalid.
>> Is there a common use case?
> 
> Right now the common use case is when a user resizes an image from the 
> WYSIWYG editor using the image resize handlers. The browser puts the 
> width and height information in the style attribute. I can move the 
> width and height to the corresponding attributes afterwards but:
> 
> * The style attribute is still required when width and height are not 
> expressed in pixel or percent. This won't happen often but the user can 
> explicitly set the width/height to other units like em in the edit image 
> WYSIWYG wizard.
> * The user can still write:
> 
> [[image:logo.jpg||style="height: 50px; width: 70px"]]
> 
> in the wiki editor and the image will be displayed as expected.
> 
> I admit that the style parameter for image syntax (and not only) is HTML 
> oriented but I think it's ok to parse it in order to optimize page 
> loading speed.

It still doesn't sound right to me but I'll trust your judgment here.

0

Caleb

> 
> Thanks,
> Marius
> 
>>>>> 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'm +1 for both (A) and (B). WDYT?
>>>> +1 B
>>>> A I need to hear more about how it will be implemented, from what i
>>>> read it doesn't look right.
>>> As Thomas said, it will be implemented in a XWiki specific
>>> implementation of WikiModel (
>>> http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-rendering/xwiki-rendering-xwiki/src/main/java/org/xwiki/rendering/internal/wiki/XWikiWikiModel.java
>>> ). We're going to add a method to get the image URL based on: document
>>> reference, attachment file name and image parameters. The implementation
>>> looks for the width, height and style parameters and tries to extract
>>> image width/height from them. If it succeeds then it adds this
>>> information to the query string of the attachment download URL. When the
>>> image is requested by the browser the image plugin is called and it uses
>>> the width and height request parameters (if specified) to scale the
>>> image attachment. The image size is never increased. The image plugin
>>> uses a component for image processing (decode, scale, encode). The
>>> default implementation of this component uses javax.imageio and java.awt
>>> classes for image processing.
>>>
>>> Thanks for your feedback,
>>> Marius
>>>
>>>> Caleb
>>>>
>>>>> 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
> _______________________________________________
> 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