[horde] Photos in address books

[Ralph Ballier]

  Zitat von Michael J Rubinsky <mrubinsk at horde.org>:

> 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/hordeprojecthttps://www.twitter.com/hordeproject

At which time is this integrated into the normal distribution?

Ralph