[horde] Photos in address books

[Michael J Rubinsky]

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
>
> When I can use this feature in my Horde system?
>
> Ralph
> -- 
> Horde mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: horde-unsubscribe at lists.horde.org


You need to be using a Git install. This is a new feature that won't  
be available in production until the next major release.

-- 
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/20151129/099a9f84/attachment.bin>