Re: [xwiki-users] width=120

2012-02-14 Thread Paul Libbrecht

Le 14 févr. 2012 à 07:59, Vincent Massol a écrit :

 Would be interesting to be moved as documentation on xwiki.org… :)

I'd agree.
This is about UI writing however... not sure where that can be.
(in the syntax definition??)

 Best place IMO would be to create an extension for the Image Plugin on 
 extensions.xwiki.org and document it.

That seems to be a core feature, I would rather keep this inside and not 
separate it.

paul
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users


Re: [xwiki-users] width=120

2012-02-14 Thread Paul Libbrecht
Thank you very much Sergiu,

is there any way that can be ensured to avoid the attachment be loaded 
currently?

paul


Le 14 févr. 2012 à 07:56, Sergiu Dumitriu a écrit :

 On 02/12/2012 05:54 PM, Paul Libbrecht wrote:
 
 Hello fellow xwiki users,
 
 we discovered recently the usage of the width parameter when delivering a 
 picture from an xwiki document attachment.
 
 Surprisingly this is available in our production server, based on the grumpy 
 xwiki 1.5, but has not been used in the UI of Curriki which has, however, 
 been made by a team of XWiki SàRL originally.
 
 Yes, this has been implemented for a very long time. If I remember correctly, 
 it might have been introduced even before 1.0, or at least very soon after 
 that.
 
 - can someone describe me how this feature is working?
 
 Basically, whenever an image download request is processed, the ImagePlugin 
 intercepts it via the downloadAttachment plugin SPI method, and, if there are 
 width or height request parameter, instead of serving the original 
 attachment, it will create a new fake attachment holding the resized image.
 
 - is the resulting downscaled image cached in file or in ram?
 
 There's a filesystem cache for resized images, indeed, so that the same file 
 isn't scaled for each request. Still, when downloading a specific image, it 
 will be held in memory as any XWikiAttachment object.
 
 - has there been a different implementation between the current xwiki (e.g. 
 3.4) and 1.5?
 
 Yes, kind of. It used to be all in 
 https://github.com/xwiki/xwiki-platform/blob/c9b8a703cff266363782eee623ff4eb61aad4b45/xwiki-core/src/main/java/com/xpn/xwiki/plugin/image/ImagePlugin.java#L165
  but the image scaling code has been moved out of the plugin, and is now in 
 https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/internal/plugin/image/DefaultImageProcessor.java
  (the call to this component is still in the plugin, though).
 
 There have been a few changes and improvements between the two versions. 
 Besides the width and height parameters, now there's support for a quality 
 parameter, a number between 0 and 1 controlling the compression quality for 
 JPEG files, and a keepAspectRatio parameter which means that in case both a 
 width and a height are specified, the image will be scaled with the same 
 aspect ratio to fit within the specified width and height.
 
 - except for the CPU hogging of computing the downscaled version, is there 
 any reason not to use this feature? (e.g. RAM overloading?).
 
 It should be used as much as possible. The only problems are the extra 
 storage needed for storing thumbnails, and the extra CPU time needed to 
 scale, or at least to access the cached file from the disk.
 
 In recent versions this feature has been used more and more, so most places 
 where images are used at a different size should already be making use of 
 this feature.
 
 thanks in advance
 
 Paul
 
 -- 
 Sergiu Dumitriu
 http://purl.org/net/sergiu/
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users


Re: [xwiki-users] width=120

2012-02-14 Thread Ludovic Dubost
The most important improvemens are:

1/ We guarantee that the image will always show up, even if the conversion
failed, which is something that does happen with certain specific file
formats. We've introduced exception catching if these cases which makes
sure that at least you'll have the original image.
2/ default quality ratio is better then it used to be

I'm not completely sure also but I think we might have changed the output
format or made sure we keep the original format.

Indeed documentation would be great.

As for why it was not used in Curriki, I think it did not exist when most
of Curriki was developped. Also the issue with possible failures made it
dangerous to use when you don't control the images passed through the
system.

Ludovic


2012/2/14 Sergiu Dumitriu ser...@xwiki.com

 On 02/12/2012 05:54 PM, Paul Libbrecht wrote:


 Hello fellow xwiki users,

 we discovered recently the usage of the width parameter when delivering a
 picture from an xwiki document attachment.

 Surprisingly this is available in our production server, based on the
 grumpy xwiki 1.5, but has not been used in the UI of Curriki which has,
 however, been made by a team of XWiki SàRL originally.


 Yes, this has been implemented for a very long time. If I remember
 correctly, it might have been introduced even before 1.0, or at least very
 soon after that.


  - can someone describe me how this feature is working?


 Basically, whenever an image download request is processed, the
 ImagePlugin intercepts it via the downloadAttachment plugin SPI method,
 and, if there are width or height request parameter, instead of serving the
 original attachment, it will create a new fake attachment holding the
 resized image.


  - is the resulting downscaled image cached in file or in ram?


 There's a filesystem cache for resized images, indeed, so that the same
 file isn't scaled for each request. Still, when downloading a specific
 image, it will be held in memory as any XWikiAttachment object.


  - has there been a different implementation between the current xwiki
 (e.g. 3.4) and 1.5?


 Yes, kind of. It used to be all in https://github.com/xwiki/**
 xwiki-platform/blob/**c9b8a703cff266363782eee623ff4e**
 b61aad4b45/xwiki-core/src/**main/java/com/xpn/xwiki/**
 plugin/image/ImagePlugin.java#**L165https://github.com/xwiki/xwiki-platform/blob/c9b8a703cff266363782eee623ff4eb61aad4b45/xwiki-core/src/main/java/com/xpn/xwiki/plugin/image/ImagePlugin.java#L165but
  the image scaling code has been moved out of the plugin, and is now in
 https://github.com/xwiki/**xwiki-platform/blob/master/**
 xwiki-platform-core/xwiki-**platform-oldcore/src/main/**
 java/com/xpn/xwiki/internal/**plugin/image/**DefaultImageProcessor.javahttps://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/internal/plugin/image/DefaultImageProcessor.java(the
  call to this component is still in the plugin, though).

 There have been a few changes and improvements between the two versions.
 Besides the width and height parameters, now there's support for a
 quality parameter, a number between 0 and 1 controlling the compression
 quality for JPEG files, and a keepAspectRatio parameter which means that
 in case both a width and a height are specified, the image will be scaled
 with the same aspect ratio to fit within the specified width and height.






  - except for the CPU hogging of computing the downscaled version, is
 there any reason not to use this feature? (e.g. RAM overloading?).


 It should be used as much as possible. The only problems are the extra
 storage needed for storing thumbnails, and the extra CPU time needed to
 scale, or at least to access the cached file from the disk.

 In recent versions this feature has been used more and more, so most
 places where images are used at a different size should already be making
 use of this feature.

  thanks in advance

 Paul


 --
 Sergiu Dumitriu
 http://purl.org/net/sergiu/

 __**_
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/**mailman/listinfo/usershttp://lists.xwiki.org/mailman/listinfo/users




-- 
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users


Re: [xwiki-users] width=120

2012-02-14 Thread Vincent Massol
Hi Paul,

On Feb 14, 2012, at 9:47 AM, Paul Libbrecht wrote:

 
 Le 14 févr. 2012 à 07:59, Vincent Massol a écrit :
 
 Would be interesting to be moved as documentation on xwiki.org… :)
 
 I'd agree.
 This is about UI writing however... not sure where that can be.

From Sergiu's answer I understood it's a feature of the Image plugin.

That said this feature is also partially located in the Platform module for 
extending the Rendering (XWikiWikiModel) so we also need to create a module on 
extensions.xwiki.org for that and document it there too.

 (in the syntax definition??)

Definitely not in the syntax.

This should go in the documentation for the Image Plugin and the Platform 
extension of Rendering, i.e. both on http://extensions.xwiki.org.

 Best place IMO would be to create an extension for the Image Plugin on 
 extensions.xwiki.org and document it.
 
 That seems to be a core feature, I would rather keep this inside and not 
 separate it.

I think you misunderstand what we call an extension.

Core features are packaged as extensions even though they're bundled by 
default.
Check http://extensions.xwiki.org to see what we have there and you'll see 
core features are documented there.

Thanks
-Vincent
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users


Re: [xwiki-users] width=120

2012-02-14 Thread Paul Libbrecht

Le 14 févr. 2012 à 10:28, Vincent Massol a écrit :

 (in the syntax definition??)
 
 Definitely not in the syntax.
 
 This should go in the documentation for the Image Plugin and the Platform 
 extension of Rendering, i.e. both on http://extensions.xwiki.org.

you need to make it central in the documentation.
Documenting all the details in an extension is useful for sure.
But the basic should be referenced from the syntax I feel.


Le 14 févr. 2012 à 10:00, Ludovic Dubost a écrit :

 As for why it was not used in Curriki, I think it did not exist when most
 of Curriki was developped. Also the issue with possible failures made it
 dangerous to use when you don't control the images passed through the
 system.


Thanks, that is the perfect explanation.
And indeed we have places where it miserably fails.
We'll be sure to use it better on the new core.

paul

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users


Re: [xwiki-users] width=120

2012-02-13 Thread Sergiu Dumitriu

On 02/12/2012 05:54 PM, Paul Libbrecht wrote:


Hello fellow xwiki users,

we discovered recently the usage of the width parameter when delivering a 
picture from an xwiki document attachment.

Surprisingly this is available in our production server, based on the grumpy 
xwiki 1.5, but has not been used in the UI of Curriki which has, however, been 
made by a team of XWiki SàRL originally.


Yes, this has been implemented for a very long time. If I remember 
correctly, it might have been introduced even before 1.0, or at least 
very soon after that.



- can someone describe me how this feature is working?


Basically, whenever an image download request is processed, the 
ImagePlugin intercepts it via the downloadAttachment plugin SPI method, 
and, if there are width or height request parameter, instead of serving 
the original attachment, it will create a new fake attachment holding 
the resized image.



- is the resulting downscaled image cached in file or in ram?


There's a filesystem cache for resized images, indeed, so that the same 
file isn't scaled for each request. Still, when downloading a specific 
image, it will be held in memory as any XWikiAttachment object.



- has there been a different implementation between the current xwiki (e.g. 
3.4) and 1.5?


Yes, kind of. It used to be all in 
https://github.com/xwiki/xwiki-platform/blob/c9b8a703cff266363782eee623ff4eb61aad4b45/xwiki-core/src/main/java/com/xpn/xwiki/plugin/image/ImagePlugin.java#L165 
but the image scaling code has been moved out of the plugin, and is now 
in 
https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/internal/plugin/image/DefaultImageProcessor.java 
(the call to this component is still in the plugin, though).


There have been a few changes and improvements between the two versions. 
Besides the width and height parameters, now there's support for a 
quality parameter, a number between 0 and 1 controlling the 
compression quality for JPEG files, and a keepAspectRatio parameter 
which means that in case both a width and a height are specified, the 
image will be scaled with the same aspect ratio to fit within the 
specified width and height.



- except for the CPU hogging of computing the downscaled version, is there any 
reason not to use this feature? (e.g. RAM overloading?).


It should be used as much as possible. The only problems are the extra 
storage needed for storing thumbnails, and the extra CPU time needed to 
scale, or at least to access the cached file from the disk.


In recent versions this feature has been used more and more, so most 
places where images are used at a different size should already be 
making use of this feature.



thanks in advance

Paul


--
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users


Re: [xwiki-users] width=120

2012-02-13 Thread Vincent Massol
Would be interesting to be moved as documentation on xwiki.org… :)

Best place IMO would be to create an extension for the Image Plugin on 
extensions.xwiki.org and document it.

Thanks
-Vincent

On Feb 14, 2012, at 7:56 AM, Sergiu Dumitriu wrote:

 On 02/12/2012 05:54 PM, Paul Libbrecht wrote:
 
 Hello fellow xwiki users,
 
 we discovered recently the usage of the width parameter when delivering a 
 picture from an xwiki document attachment.
 
 Surprisingly this is available in our production server, based on the grumpy 
 xwiki 1.5, but has not been used in the UI of Curriki which has, however, 
 been made by a team of XWiki SàRL originally.
 
 Yes, this has been implemented for a very long time. If I remember correctly, 
 it might have been introduced even before 1.0, or at least very soon after 
 that.
 
 - can someone describe me how this feature is working?
 
 Basically, whenever an image download request is processed, the ImagePlugin 
 intercepts it via the downloadAttachment plugin SPI method, and, if there are 
 width or height request parameter, instead of serving the original 
 attachment, it will create a new fake attachment holding the resized image.
 
 - is the resulting downscaled image cached in file or in ram?
 
 There's a filesystem cache for resized images, indeed, so that the same file 
 isn't scaled for each request. Still, when downloading a specific image, it 
 will be held in memory as any XWikiAttachment object.
 
 - has there been a different implementation between the current xwiki (e.g. 
 3.4) and 1.5?
 
 Yes, kind of. It used to be all in 
 https://github.com/xwiki/xwiki-platform/blob/c9b8a703cff266363782eee623ff4eb61aad4b45/xwiki-core/src/main/java/com/xpn/xwiki/plugin/image/ImagePlugin.java#L165
  but the image scaling code has been moved out of the plugin, and is now in 
 https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/internal/plugin/image/DefaultImageProcessor.java
  (the call to this component is still in the plugin, though).
 
 There have been a few changes and improvements between the two versions. 
 Besides the width and height parameters, now there's support for a quality 
 parameter, a number between 0 and 1 controlling the compression quality for 
 JPEG files, and a keepAspectRatio parameter which means that in case both a 
 width and a height are specified, the image will be scaled with the same 
 aspect ratio to fit within the specified width and height.
 
 - except for the CPU hogging of computing the downscaled version, is there 
 any reason not to use this feature? (e.g. RAM overloading?).
 
 It should be used as much as possible. The only problems are the extra 
 storage needed for storing thumbnails, and the extra CPU time needed to 
 scale, or at least to access the cached file from the disk.
 
 In recent versions this feature has been used more and more, so most places 
 where images are used at a different size should already be making use of 
 this feature.
 
 thanks in advance
 
 Paul
 
 -- 
 Sergiu Dumitriu
 http://purl.org/net/sergiu/
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users


[xwiki-users] width=120

2012-02-12 Thread Paul Libbrecht

Hello fellow xwiki users,

we discovered recently the usage of the width parameter when delivering a 
picture from an xwiki document attachment.

Surprisingly this is available in our production server, based on the grumpy 
xwiki 1.5, but has not been used in the UI of Curriki which has, however, been 
made by a team of XWiki SàRL originally.

- can someone describe me how this feature is working?
- is the resulting downscaled image cached in file or in ram?
- has there been a different implementation between the current xwiki (e.g. 
3.4) and 1.5?
- except for the CPU hogging of computing the downscaled version, is there any 
reason not to use this feature? (e.g. RAM overloading?).

thanks in advance

Paul
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users