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.

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

Reply via email to