[horde] Photos in address books

Wed Jan 20 08:23:06 UTC 2016

Zitat von Ralph Ballier <ballier at mail.schule.de>:

> 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
> -- 
> Horde mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: horde-unsubscribe at lists.horde.org

When it's ready.

-- 
Jan Schneider
The Horde Project
http://www.horde.org/