First of all, a big disclaimer: It has been years since I last looked at OLE internals, so I could say something wrong, and I hate speaking about stuff I am not 100% sure.
But the reason you need the pdf reader installed is the same reason you need Excel installed. You are using OLE to control Excel from Delphi, so you need Excel installed to control it from Delphi. Excel uses OLE to control the PDF reader from Excel, so it needs the PDF reader installed to control it.
Remember that what you are doing here is not attaching a file, but running one application inside another. It might be not clear in this particular case of pdf embedded as an icon, but imagine you embed a Word document, not as icon but as an actual Word document inside the Excel file. You can click inside the Word object and edit the Word document from Excel. It is kind of magic if you think about it, and it would be even better if it was reliable, but OLE has been out since windows 3 at least, and it has never been.
Now, there is a lot of interaction between Word and Excel document to make this magic happen. When you click inside the word doc, Excel passes some binary blob to Word, Word uses that blob to get the file it needs to edit, and then displays the file inside the running Excel instance. It handles the keystrokes, so when you insert a character in the word document, it goes to Word and not to Excel. When you click outside the word document, control goes back to Excel, and it asks Word for the modified blob so it can persist it in the file, and pass it again when the user re-clicks inside the word document.
So what we have is:
- User clicks in Word document: Excel gets some data it doesn't understand or care, and passes it to word. Word uses this data to open the document and display it.
- User modifies the Word document
- User exits the Word document, Excel asks Word for that modified data (which it still doesn't understand), and persists it in memory/the file.
- When user clicks again, Excel takes the blob it received in 3. and passes it to word, going back to 1.
The blob is responsibility of Word, not Excel. It has to have the doc/x file inside, but it is not necessary a plain doc/x file, and Excel is not aware of what it has. It just knows it has to pass it when asked by the guest app, and store it back when you exit the guest app.
In your case, you normally don't edit PDF files, so storing the blob back wouldn't be necessary. But you can edit pdf files (acrobat can do it). And even if embedded as an icon, if you double click that icon and acrobat launches, and you modify the pdf, when you close acrobat, those changes must go back to Excel and be stored inside the xlsx file. So you still need the full OLE mechanism here.
What matters from a FlexCel point of view, is that you never really store the pdf file: you have to store the blob the guest app uses to load and persist the data. And you can have infinite guest apps. We could reverse engineer what a PDF reader uses as blob to communicate with Excel. (it is likely the pdf file + some OLE headers). But then, you might want to insert a powerpoint file, and we now need to know what blob Powerpoint uses. It doesn't scale. At the end, the only solution to use that is to Automate the guest app (pdf reader in this case) and ask it for the blob. The main issue being that now you have 2 automations going on: Delphi to Excel and Excel to the PDF reader.
