![]() To check that this worked properly, I opened some of my test files, which included some containing orphaned objects, only for those objects to vanish from the PDF source. Checking the minimalist documentation provided by Apple, I thought that using the latter might reduce memory usage, so was calling that and converting the data into ASCII format to display in the view. ![]() One is to take the data exactly as read from the file, the other using an instance method of the PDFDocument class, dataRepresentation(). There are two ways of accessing the raw data in a PDF document. So odd that I thought my file system had broken. I have been adding features to Podofyllin to help the user check for orphaned content, and a couple of days ago had modified its source code to display the PDF file in ASCII format in the app’s Source window, when I discovered something very odd. I showed how even Adobe Acrobat (Pro) DC’s structure browser is based on what is listed by the document Catalog, and can readily miss orphaned data left in a previously edited file. The greatest difficulty facing even the expert user is that of checking whether a PDF document has been sanitized, or still has sensitive information remaining in it. ![]() Two techniques are available to sanitize PDF documents: as with most document formats, using the Save As command usually forces the app to write all the data out afresh, and more specifically for PDF, some apps (including both PDF Expert and PDFpenPro) offer commands to write ‘flattened’ versions of the document. I’ve been drawing attention to the danger of hidden and orphaned content being left in PDF documents, something which frequently catches people out when they release those documents, only for someone to discover embarrassing secrets left within the files.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |