It's probably possible by writing a CLR stored procedure for the task, but having this procedure called by a trigger does not sound like the best of ideas. Keep in mind that even if you don't have a user-defined transaction, the trigger will run in a transaction defined by the statement that fired the the trigger. So the INSERT/UPDATE will not commit until that PDF has generated. This could cause some contention issues in a high-transaction environment.
And what if the PDF generation fails, do you want the INSERT to be rolled back in this case? (Because that is what is going to happen.)
No, most likely you are better off having some polling mechanism that looks for new rows and generates the PDFs. You could still generate the PDF from a CLR stored procedure, but there is quite a bit of red tape with adding CLR code, and you are probably better off by doing this from an external program. You should probably look into what scheduling opportunities that Crystal may offer