[horde] Photos in address books

Michael J Rubinsky mrubinsk at horde.org
Mon Nov 16 22:36:34 UTC 2015


Quoting Arjen de Korte <arjen+horde at de-korte.org>:

> Citeren Ralph Ballier <ballier at mail.schule.de>:
>
>> Zitat von Michael J Rubinsky <mrubinsk at horde.org>:
>>
>>> Quoting Ralph Ballier <ballier at mail.schule.de>:
>>>
>>>> Hello,
>>>>
>>>> a colleague had written a software for an webbased addressbook. There
>> are
>>>> stored personal datas of many persons together with here photos. If you
>>>> look, all photos seem to have the same size.
>>>>
>>>> Now we had transported all data into an addressbook under Horde. The
>> data
>>>> are stored in LDAP. Now we see in Horde all photos in here original
>> size.
>>>> Some are very very large (bigger than the screen). But if you look onto
>>>> the
>>>> sychronized contacts at my tablet, the size are correct.
>>>>
>>>> How I can solve this problem, which seems to be only if I call the
>>>> addressbook in Horde?
>>>
>>> We don't dynamically resize the photos on page view since this is an
>>> expensive operation. On image upload we provide a UI to resize the image
>>> before committing the change. Obviously this doesn't work for API/Import
>>> access. We can add a config option for Turba going forward though for
>>> default picture size when importing.
>>>
>>> Please create an enhancement ticket on bugs.horde.org so this doesn't
>>> get lost.
>>>  
>>
>> My colleague means, that the reduction of the number of pixel before
>> storing is not the right way. He means, you must say to the browser to show
>> the desired resolution. The number of pixels in the stored photo shall
>> remain unchanged because he don't want degradation. Later he will print the
>> photos and then the quality is bad.
>
> By default, Horde will embed the images in base64 in the page (which  
> saves on server connections and roundtrip delays). This means that  
> resizing will have to be done on the server, which is a costly  
> operation and therefor is best done once (on uploading the image).

Turba uses Horde_Form's image type for this, which is rendered by  
Horde_Core_Ui_VarRenderer_Html::_renderVarDisplay_image() and doesn't  
use base64 embeded images. That being said, resizing in the browser  
using height/width attributes of the image tag is still problematic  
because the tag is generated within the HCUi_VarRenderer_Html::class  
without any size attribtues.

> This doesn't mean the originals necessarily are lost, it might be an  
> option to allow downloading the originals from Turba.

Horde_Form by default only returns the final, resized image but *can*  
be told to return both. We would need to refactor a bit in Turba to be  
able to save the original image to the backend as well. This of course  
would mean that the backend would need to add a new photo_resized(?)  
field to store it.

I don't know, to me this seems like overly complicating things for too  
little gain. I'm guessing this will also only make sense for backends  
that are accessed through means other than Turba as well.



-- 
mike
The Horde Project
http://www.horde.org
https://www.facebook.com/hordeproject
https://www.twitter.com/hordeproject
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5751 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/horde/attachments/20151116/aede7d4c/attachment.bin>


More information about the horde mailing list