[TYPO3-core] RFC #13283: Thumbnail generation broken for PDF files

[Steffen Ritter]

Michael Stucki schrieb:
> Hi Steffen,
> 
>> I don't see a reason to set default to -1 as only is checked if frame is
>> gt 0.
> 
> That is true, but still you kept it in your updated patch. I've made a
> new one which keeps the default value at 0.
> 
>> Why is parameter ommited if frame is 0? Installtool always check
>> "...pdf_from_imagemagick.pdf"[0] and it works.
> 
> Right.
> 
>> And one more, isn't it possible to show a frame of an anigif with frame
>> option?
> 
> There are many files which can have frames, so v7 was wrong in any case.
> At least TIFF can be multipage and allows IM/GM to specify a frame.
> 
> But even more important is that _every_ file can be opened with a frame
> specified. As long as the frame is 0, IM/GM will not refuse to open it
> (as if it would be left out).
> 
> This means that the check for the filetype is not needed at all. You can
> just append the frame in every case (except if "noFramePrepend" is set
> in the Install Tool).
> 
>> So sry for my comments, but patch doesn't satisfy me by reading.
>> I'm sorry that i can't test this as i have problems getting gs into
>> action on my windows system.
> 
> OK, I have a new patch for you which hopefully satisfies you much
> more... :-)
> 
> Find attached v9 with the following changes:
> - Append the frame parameter for every file, not just PDFs
> - Move whitespace after the frame value to the commandline
> 
> Cheers, Michael
> 
> PS: Disclaimer! The solution of this patch was sponsored at the bug
> auction at T3BOARD10. We promised to get it fixed asap, and according to
> our tests, it is working perfectly now.
> 
> PPS: I would like to thank Andy Grunwald who is sitting next to me and
> helped me to catch this gremlin. It looked like a no-brainer to us, but
> now we've been working on it for already 3 hours...
> 
Hey Michael,
thanks for your work at T3BOARD, I have one question.
We introduced the thing with pdf, since all other framed file types 
beside of pdf rendered without a frame-number, too. Multipage PDFs wont 
ever without a frame.
You're patch, ignores the case again. So if you have a multipage PDF and 
select noFramePrepended no PDFs will be shown in frontend anymore... 
Other filetypes will just render "the whole picture".

So your patch fixes "the normal" rendering without "noFramePrepend". But 
as long this option is there, it has to work out with option set too.

So to me there are just two possibilities:
  - care for pdf in special
  - drop noFramePrepended

since dopping the option is not possible in already released version, 
there we have to care about. To me it would be OK depreciating this 
option and say that it may fail sum functionality.

So please think about it at core team what your "policy" will be in this 
case and state it clear in documentation.

Steffen