You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please note that the example contains sensitive data.
Try to attach it to some email and then check the preview, currently:
a) small thumbnail shows only the 1st page/image
b) in the preview window only the last page/image is shown
Expected result:
a) thumbnail should show multiple images if multiple images are presented in one file
b) preview should do the same or should display very visibly a warning with somethink like: "The TIF image attachment does contain multiple page. Roundcube currently support to show only the first page. To display another pages, please download the attachment and open it in a program with full TIF support." (and please note, that currently the last page instead of the first one is shown in the preview window)
TIFF is tricky business. Not all browsers support it. And if they do I'm not sure they support multi-page. So, it has to be noted that:
On browsers that do support Tiff we send the image to the browser as-is and we can't do nothing about how it is presented by the browser. Maybe with some javascript we could workaround no support to multi-page tiff.
On browsers with no Tiff support we convert the image to Jpeg using ImageMagick. This process is error prone. For example on my system for the above image I see the thumbnail contains both pages, but one overlaps the other. Opening the image does not work, the jpeg is malformed (might be another bug).
So, while not impossible it might be not that easy to fix these cases.
ps. on my linux system also not all apps support multi-page, e.g. Gwenview does not, but Okular does.
A quick test with converting to GIF proves that it could be an option, but requires some additional parameters for ImageMagick because by default it makes the image blinking (pages/images switch without any delay). Still I think that's not an option, pages should switch on user request or be displayed one below another.
I would vote to always convert the image on server to PNG (as TIFF is lossless).
a) in thumbnail display the first page and overlay it with text like "N pages" (or display all as in b), but then there may be a lot of additional code for styling).
b) in preview window display one large image with pages rendered one by after each other.
c) I would not modify the image to download in any way, use will see in the preview, that it has multiple pages and it is up too the user to choose the right program.
The image opening bug I described earlier is caused by the fact that such image is converted to multiple jpeg files (with -0 and -1 suffix). That is not taken care by the code so instead of all or one of them the original tiff is sent to the browser. So, this is a related issue that should be fixed anyway.
I checked the commits and we do not allow exec in PHP. Is the code with Imagick class fixed too? Can you make the conversion for preview make implicit, i.e. not check for TIF browser support as at least Firefox is currently showing only the last page.
As I see the Imagick-based code is not broken. It will output a single page to jpeg. For unknown reason I see the first page in a thumbnail, but the last page in the full view. Maybe that's a side effect of resizing.
I don't think we should make exceptions for browsers not supporting multi-page. Not until we have proper multi-page support.
As I see the Imagick-based code is not broken. It will output a single page to jpeg. For unknown reason I see the first page in a thumbnail, but the last page in the full view. Maybe that's a side effect of resizing.
This is probably the issue. I have nothing about native support if it works reliably. Please test the support in Firefox.
Firefox does not support Tiff, so the image is converted to Jpeg by Roundcube (if it has Imagick or im_convert_path enabled). And that is the browser I'm using and the behavior I described. So, I don't know what more do you want me to test.
Here is a screenshot how it looks like currently, one attachments, two very different renders. Maybe the exec render is working, but we have exec disabled and use the PHP Imagick extension. And with it only the fist page is shown in the thumbnail and only the last page is shown in the attachment (pre)view.
I would suggest to:
a) fix the thumbnail to render all pages or overlay the thumbnail (to keep the size small) whith some red text like "N pages".
b) fix the (pre)view render to render properly all page sequentially
That's why the ticket is still open. That difference is not a big deal if you can't see all pages anyway. I agree that it can be improved with proper multi-page support. What you suggest should be considered as possible solutions.
Activity
[-]TIF with multiple images in one file[/-][+]TIF with multiple pages/images in one file[/+]alecpl commentedon Jun 26, 2019
TIFF is tricky business. Not all browsers support it. And if they do I'm not sure they support multi-page. So, it has to be noted that:
So, while not impossible it might be not that easy to fix these cases.
ps. on my linux system also not all apps support multi-page, e.g. Gwenview does not, but Okular does.
alecpl commentedon Jun 26, 2019
A quick test with converting to GIF proves that it could be an option, but requires some additional parameters for ImageMagick because by default it makes the image blinking (pages/images switch without any delay). Still I think that's not an option, pages should switch on user request or be displayed one below another.
mvorisek commentedon Jun 26, 2019
I would vote to always convert the image on server to PNG (as TIFF is lossless).
a) in thumbnail display the first page and overlay it with text like "N pages" (or display all as in b), but then there may be a lot of additional code for styling).
b) in preview window display one large image with pages rendered one by after each other.
c) I would not modify the image to download in any way, use will see in the preview, that it has multiple pages and it is up too the user to choose the right program.
alecpl commentedon Jun 26, 2019
The image opening bug I described earlier is caused by the fact that such image is converted to multiple jpeg files (with -0 and -1 suffix). That is not taken care by the code so instead of all or one of them the original tiff is sent to the browser. So, this is a related issue that should be fixed anyway.
Fix bug in converting multi-page Tiff images into Jpeg (#6824)
Fix bug in converting multi-page Tiff images into Jpeg (#6824)
mvorisek commentedon Jun 26, 2019
I checked the commits and we do not allow exec in PHP. Is the code with
Imagickclass fixed too? Can you make the conversion for preview make implicit, i.e. not check for TIF browser support as at least Firefox is currently showing only the last page.alecpl commentedon Jun 26, 2019
As I see the Imagick-based code is not broken. It will output a single page to jpeg. For unknown reason I see the first page in a thumbnail, but the last page in the full view. Maybe that's a side effect of resizing.
I don't think we should make exceptions for browsers not supporting multi-page. Not until we have proper multi-page support.
mvorisek commentedon Jun 26, 2019
This is probably the issue. I have nothing about native support if it works reliably. Please test the support in Firefox.
alecpl commentedon Jun 27, 2019
Firefox does not support Tiff, so the image is converted to Jpeg by Roundcube (if it has Imagick or im_convert_path enabled). And that is the browser I'm using and the behavior I described. So, I don't know what more do you want me to test.
mvorisek commentedon Jun 27, 2019
Here is a screenshot how it looks like currently, one attachments, two very different renders. Maybe the exec render is working, but we have exec disabled and use the PHP Imagick extension. And with it only the fist page is shown in the thumbnail and only the last page is shown in the attachment (pre)view.
I would suggest to:
a) fix the thumbnail to render all pages or overlay the thumbnail (to keep the size small) whith some red text like "N pages".
b) fix the (pre)view render to render properly all page sequentially
alecpl commentedon Jun 27, 2019
That's why the ticket is still open. That difference is not a big deal if you can't see all pages anyway. I agree that it can be improved with proper multi-page support. What you suggest should be considered as possible solutions.