Earlier this week, when I considered how best to save websites using Safari, I pointed out that the PDFs it saves aren’t intended to be in archival format, using one of the PDF/A standards. As some of you pointed out, Preview has an option to export PDFs in “PDF/A” format. This article examines whether those are suitable for archiving.
PDF/A
PDF is a generic document type and includes a multiplicity of different standards. Standard PDF generated by the Quartz 2D engine should comply with PDF version 1.4, from 2001, although the first open ISO standard of 2008 was based on version 1.7, and the current ISO standard is version 2.0. There are also five specialised subsets of PDF, among them PDF/A intended for archival purposes, each with their own families of ISO standards.
PDF/A was originally based on PDF version 1.4, but more recently has adopted 1.7. Its standards impose additional restrictions on core features, such as requiring all fonts to be embedded, and forbidding the use of encryption and LZW compression. Its standards are based on three levels of conformance: basic (B), accessible (A), and full Unicode text (U). The two standards and levels in most common use are PDF/A-2A (accessible) and PDF/A-2B (basic). A more detailed account is given in Wikipedia’s article.
Although Preview claims to export PDF documents in PDF/A format, I’ve been unable to discover which standard or level those are intended to comply with. However, each of the test documents is reported by Adobe Acrobat CC (Pro) as claiming compliance with PDF/A-2B in ISO 19005-2.
Conformance
Three test PDF documents were used, two saved from Safari 26.1 (macOS 26.1) as detailed previously, and the Help book for LogUI, written by Nisus Writer Pro. All three were opened in Preview 11.0 (1113.2.5) and Exported As PDF/A, with just the Create PDF/A option ticked in the File Save dialog.
All three exported PDFs were then opened in Adobe Acrobat ‘Pro’ version 2025.001.20841. That reported that each claimed “compliance with the PDF/A standard”, so opened them read-only to ensure they couldn’t be modified. When each was verified against PDF/A-2B, that failed.
Details of the compliance failures were then obtained using Acrobat’s Preflight feature. In each there were multiple errors, such as those shown below.
To assess what changes were required to make the LogUI help book compliant with the standard, Acrobat then performed the conversion. Corrections it made are shown below.
Although those were quick and simple, without them the file exported from Preview wasn’t considered by Acrobat to comply with the standard.
When do you need to use PDF/A?
Although I’m confident that PDF documents created using the engine in Quartz 2D in macOS Tahoe will remain fully accessible for at least the next 20 years or more, looking 50 or 100 years ahead the use of a major open standard intended and widely used for archives becomes more important. Whether the imperfect PDF/A exported by Preview would make any difference to that is unclear.
If you intend any PDF documents created on Macs to be true archives that should stand the test of long times, then you should convert them into PDF/A-2B or another appropriate standard before committing them to archival storage. Otherwise, it’s moot whether Preview’s conversion is a good investment of your time.
Summary
According to Adobe Acrobat, the ‘PDF/A’ format exported by Preview doesn’t comply with its claimed standard of PDF/A-2B. Thus the answer to the question posed by the title is no, not quite.
If a PDF is intended to be accessible for decades into the future, it should be converted to a recognised PDF/A standard such as PDF/A-2B using Adobe Acrobat or an equivalent.
Other PDFs may as well be left in their original format, which should ensure their accessibility for at least the next 20 years or more.
Timestamps on files and folders are important, and can be used for many different purposes, from sorting files to find the most recent, to providing evidence in court. Each file (and directory) in APFS has four separate timestamps you can use:
Created, termed in APFS create_time, gives “the time that this record was created”.
Modified, mod_time, “the time that this record was last modified”.
Last opened, access_time, “the time that this record was last accessed”.
Attributes Modified, change_time, “the time that this record’s attributes were last modified”.
Although the Finder only displays those to the nearest second, the macOS API readily provides fractions of a second, commonly resolved to milliseconds, and the raw values are saved as nanoseconds since 00:00 UTC on 1 January 1970.
The first three are those most commonly used, although the last can be relevant in backups in particular. If you want to see which file in a folder is the oldest there, look for the oldest time Created. If you want to know which was most recently changed, look for the latest Modified time.
Where you must be careful is in interpreting those dates, as it’s easy to make assumptions that may not always work. The first confounding factor is that files can change without updating the Last opened time.
Apple’s APFS reference states that access_time is updated according to the behaviour set by that volume’s APFS_FEATURE_STRICTATIME setting. “If this flag is set, the access_time field of j_inode_val_t is updated every time the file is read. Otherwise, that field is updated when the file is read, but only if its value is prior to the timestamp stored in the mod_time field.”
Does APFS in macOS currently set the APFS_FEATURE_STRICTATIME for its volumes?
You can see how that works in a simple demonstration. Create a new text file in TextEdit and add a line or two of text to it, then save it. In the Finder, Created, Modified and Last opened timestamps will now all give the same time and date. Leaving that file open in TextEdit, wait a couple of minutes, then add another line to the file and save it again. In the Finder, the Modified time will be updated, but not the Last opened time, because the file hasn’t been opened and read again. Close the file, wait another couple of minutes, and open it again. You should see its Last opened time update, indicating that APFS_FEATURE_STRICTATIME is set for that volume.
My example is even more extreme. According to these timestamps, this file was Created on 13 July, and hasn’t been opened since. However, it was modified without being read on 23 September. If it’s opened and read now, it’s Last opened time will be updated whatever the APFS_FEATURE_STRICTATIME setting.
There’s another confounding factor that makes this even less reliable: QuickLook. Although its thumbnails and previews are constructed using file data, that access doesn’t affect either the Modified or Last opened timestamps, and opening and reading a QuickLook Preview isn’t recorded anywhere in a document’s attributes. So it could be extremely misleading to assume that a file hasn’t been viewed just because its Last opened timestamp hasn’t changed.
If you do want to use the timestamps on files or folders, it’s essential to know their limitations and behaviours, otherwise you could draw the wrong conclusions.