I have a working solution for getting PDF previews with the MBS plugin:
dim PreviewPic as Picture
dim thePDF as new PDFDocumentMBS(MimeData)
if thePDF <> nil then
dim thePDFPage as PDFPageMBS = thePDF.pageAtIndex(0)
dim theColor as NSColorMBS = NSColorMBS.whiteColor
if thePDFPage <> nil then
dim theImage as NSImageMBS = thePDFPage.Render(DPI, 0, theColor)
if theImage <> nil then PreviewPic = theImage.CopyPicture
Catch err as NSExceptionMBS
This works fine for most of the PDFs. Except when the PDF is odd. I have one PDF which is fine on High Sierra and makes my app and Preview crash on Mojave. I have a fallback solution using the sips command
dim theShell as new Shell
dim theCommand as String = "sips -s format png " + thePDFFile.ShellPath + " --out " + theResultFolderitem.ShellPath
which unfortunately is much slower than the MBS plugin. I’ve now got a customer who sees crashes from sips even on High Sierra.
I have looked for a replacement library to get the PDF previews. I don’t like to whine about prices but DynaPDF is way too expensive right now. I have looked around but only found either GPL solutions or enterprisey ones (“we are too expensive to put our prices on the website”). Does anyone know about a solution that works for macOS and doesn’t cost an arm and a leg?
Well, grab DynaPDF plugin when it’s on sale? e.g. with a conference discount?
You could use QLPreviewViewMBS for a preview dialogue or QuickLookMBS to get a picture from a pdf. For us both are working fine under Mojave.
@Christian Schmitz: just no.
@Dagmar Schreeck-Oeser : not a bad idea for testing. If QLPreviewViewMBS doesn’t use the same library as PDFDocument and Preview…
@Beatrix Willius Though using the same libraries does not mean that the same (buggy?) functions will be used
@Stephane Mons: yeah. This is likely but I’ll check. Quicklook also is slow.
@Beatrix Willius Well I agree that most of what we see from Quicklook is slow, however that does not mean that every Quicklook function is slow. I suspect that the Finder uses Quicklook previews and they don’t seem particularly slow to me, even in asynchronous mode.
And on the bright side, if an XPC helper crashes during the process, it will not impact your application.
if this is for macOS … try from shell
sips -s format png your_pdf_file.pdf --out your_png_file.png
did you try to load the pdf in an htmlviewer ?
You can try CGImageSourceMBS:
dim c as new CGImageSourceMBS(f)
dim img as CGImageMBS
dim d as new Dictionary
img = c.CreateThumbnailAtIndex(0, d)
p = img.Picture
Both should work with PDF.
@Dave S : please see my first post. sips already is my fallback. One customer gets crash reports from the command.
@Jean-Yves Pochez : thought about the idea, too. Not sure if feasible.
@Dagmar Schreeck-Oeser : good ideas.
I don’t know if you can eliminate the possibility of any PDF engine ever crashing on an “odd” PDF document (i.e. a PDF with errors).
Perhaps you should spin the PDF-to-image code out to a helper app. If it crashes, your entire app doesn’t come down and you can inform the user that they may have a damaged PDF.
[quote=433942:@Beatrix Willius]@Jean-Yves Pochez : thought about the idea, too. Not sure if feasible.
I display small preview of jpg or pdf with it and it works fine.
displaying the pdf in an htmlviewer may not work x-platform
Beatrix wants it for Macos.
I recall you must install acrobat reader in order to see pdf in htmlviewers ? is it correct ? may be not on macos.
macos it should just work to open the pdf in an htmlviewer as it will use the system pdf renderer
@Jean-Yves Pochez : yes, I’m a Mac. I don’t do the dark side.
@Norman Palardy : the system PDF renderer is the one that crashes.
@Daniel Taylor: a PDF renderer shouldn’t crash. Your idea is the last resort.
but PDF renderer WILL crash (including Preview, and Adobe Reader) if the PDF file itself is corrupt. Sometimes the stand-alone readers will “recover” and fail gracefully… but I would not expect that from command line tools such as SIPS where they expect to fail back to the command line (ie. crash).
I ran across this many times when writing my gPDF package, when testing code that wasn’t producing a valid PDF as expected
Got some data from the customer. Holy guacamole. Whatever is in the PDF makes my iMac crawl when the PDF is rendered. I quit Xojo and the debug app still was running.
Using CGImageSourceMBS for the customers PDF works fine. However, as expected CGImageSourceMBS still crashes on Mojave with another corrupt PDF that I have because macOS only uses the same PDF library everywhere.
@Dave S : below is the beginning of the crash log from sips. I was very very surprised to see something like this:
Process: sips 
Code Type: X86-64 (Native)
Parent Process: Mail Archiver X 
Responsible: sips 
User ID: 502
Date/Time: 2019-04-22 14:29:43.968 +0200
OS Version: Mac OS X 10.13.6 (17G6030)
Report Version: 12
Anonymous UUID: A1B78A3D-87C9-1685-791E-3EA776CDCF5D
Sounds like a helper app would help you.
With DynaPDF we can fix such bugs ourselves. And with Optimize command we can repair broken PDFs.