[horde] Photos in address books

[Michael J Rubinsky]

Quoting Torben Dannhauer <torben at dannhauer.info>:

> 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
>
> ----------------------
>
> Well, the gain might be little, but on the other hand, the current  
> solution does not look very professional with large images, being  
> shown using a large portion of the screen...



I've added changes in Git master that do the following:

For any 'image' type of attribute, an additional attribute type would  
be supported with the text '_orig' appended to the attribute name. So,  
e.g., I have added the 'photo_orig' field in config/attributes.php and  
added it to the default map for localsql in backends.php (so be sure  
to run the new db migration as well).

What happens is - during vCard import if turba finds an image  
attribute with the '_orig' field available, the image data is saved to  
that field unchanged.

When a contact is loaded (more accurately, when Turba requests the  
value of an image type field) Turba checks if the non-original field  
is non-empty. If it's non-empty that image is used as-is. If it *is*  
empty *and* we have some value in the '_orig' field, we automatically  
resize it based on the default size parameters that have been added to  
turba's configuration and store it in the non-original field.

If uploading images via the UI one can check the "save original image"  
check-box before re-sizing and saving for the original image to be  
saved to the '_orig' field.


So, for any existing backends that Turba is connecting to that contain  
full sized images, that full size image field should be mapped to the  
'photo_orig' field and a new field should be added that can store the  
resized image that should be mapped to the 'photo' field. This allows  
one-time re-sizing to be done on-demand and leaves the original image  
data intact.

-- 
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/20151120/86a60a6a/attachment.bin>