Urlaubsplaning 2017.pdf The file I've been editing with Preview.app this morning. Screenshot 08.31.06: Clearly visible how memory usage went back up seriously when continuing to edit a file in preview.app at the same time, Preview.app uses about no memory. Screenshot 08.26.32: Clearly visible how memory usage went seriously down the moment I killed preview.app This morning I have noticed a serious problem, which may be related to the fix in PDFKit (nothing else changed really). Recently noticed serious problems with PDFKit and upgraded 10.12.2 Beta (16C32e) as advised through Apple Bug Reporter. #APPLE FIXES PREVIEW BUT PROBLEMS WITH PDFKIT PDF#Editing a super simple PDF adding just some colorful boxes to it makes suddenly the system use all available swap space - after some minutes only - and then get to a grinding halt. It now not only breaks Skim (where annotations mostly worked now, as others have observed too), but it also breaks Preview.app. See my bug description which I'll copy/paste below. I may have seen a serious memory leak after upgrading to 10.12.2 Beta (16C32e) as mentioned earlier in this thread. This kind of sucks, and of course the whole issue sucks big time, but hey, at least I'm back in business with Skim, which is so much more important for me. The only real downside - besides the time required to do all of that if you don't use the version of PDFKit that I provide - is that you need to disable System Integrity Protection in order for that switching of versions to still work. Skim continues to work, interestingly, in that case. That's why I've written the little helper script - if, for example, I've started up with the Mavericks version of PDFKit, and see that while Skim works, Preview is not starting, then I just switch over to the Sierra version - without rebooting or anything - and then Preview works. It also breaks, from time to time, Preview. This fixes the annotation issues with Skim for me. One way or the other, you can then utilize a small helper script that I also have documented to switch between the different PDFKit versions. It involves either getting a Mavericks Version of PDFKit that I have created today, or to create one yourself going the detour of an installation of Mavericks in a virtual machine, which I also fully documented. I fully expect this will get fixed but in the meantime, I’m sticking with PDFpen and I recommend you do the same.I've worked a couple hours on it now, and have worked out and documented a method of switching back to the Mavericks version of PDFKit, while using Sierra. Preview cannot not display (or properly save) some of my form PDFs and seems to be wiping the OCR text layer out of previously OCR’d PDFs. After getting all this email, however, I decided to use Preview for a few days to see how bad it is. I spend most of my time working with PDFs in PDFpen, which largely does not rely on Apple’s frameworks and works fine. Adam Engst did his usual bang-up job talking to developers about this over at TidBITS. #APPLE FIXES PREVIEW BUT PROBLEMS WITH PDFKIT CODE#Unfortunately, in doing so, they broke much of the code PDF apps rely upon. Sierra is where they started implementing this. The underlying problem is that Apple wants to use the same foundational PDF code for both macOS and iOS. (This is why the Fujitsu ScanSnap took longer to become Sierra-friendly.) Apparently with the release of macOS Sierra, Apple rewrote many of the PDFKit frameworks used in Preview and several other third party PDF applications. I am receiving a lot of email lately from readers encountering PDF problems on the Mac.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |