[horde] Photos in address books

[Simon B]

On 20 Nov 2015 9:44 pm, "Michael J Rubinsky" <mrubinsk at horde.org> wrote:
>
>
> 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.

This is one of those times I wish email had a "+1" feature where you could
let the author know you loved his/her email without having to reply... :)

Maybe that's a feature one could build into horde/imp? ;)

Simon