[horde] Photos in address books

[Ralph Ballier]

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

> Quoting Ralph Ballier <ballier at mail.schule.de>:
>
>> 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?
>
> Turba 5/Horde 6.
>
> --
> mike
> The Horde Project
> http://www.horde.org
> https://www.facebook.com/hordeprojecthttps://www.twitter.com/hordeproject

When can we expect it?

Ralph