# Preflight checks Inspect the source, build log, PDF, references, accessibility signals, and submission risks before a document leaves your hands. A successful compile only proves that a PDF was made. It does not prove that every citation resolved, the reading order makes sense, the submission archive is clean, or the file carries the accessibility structure it claims. Preflight brings those questions into one local review. Open the **shield** in the project rail, choose the checks that fit the document, and run one check while fixing a problem or the full set before submission. ![Oleafly's Preflight panel. Select the checks you need, run one from its row, or run all enabled checks from the bottom button.](https://cdn.oleafly.com/images/screenshots/desktop/docs/preflight-checks-dark-window-v2.png#view=0,45,344,689) ## Six independent checks ### Compile & layout Reads the latest build log and PDF for failed builds, unresolved citations and references, rerun warnings, missing glyphs, overfull boxes, clipped text, duplicate PDF destinations, and mixed page sizes. ### Submission readiness Applies a selected publication profile to the project. It checks stable requirements around the document class, abstract and keywords, figure formats, embedded fonts, PDF restrictions, captions, portable names, and source-package clutter. ### ATS readiness Extracts a resume much like an applicant tracking system would. It reports contact fields, expected sections, and layouts that can scramble reading order. ### Accessibility Checks source and PDF signals around tagging, alternative text, language and title metadata, viewer settings, headings, tables, links, reading order, selectable text, bookmarks where useful, and very small text. ### References & assets Finds missing files, unresolved citations and cross-references, duplicate labels and DOIs, incomplete bibliography entries, and uncited references when the complete project is available. ### Privacy & blind review Looks for credentials, private keys, sensitive files, draft notes, internal comments, acknowledgements, author fields, and identity metadata that may break a blind review. ## Read the certainty, not only the color Every result explains how Oleafly reached it: - **Verified** means the app observed direct evidence in the source, log, project, or PDF. - **Advisory** means a documented heuristic found something a person should inspect. - **Manual** names a check the files cannot settle safely. A missing input never becomes a pass. Source-only findings remain partial until a current PDF exists. ## Choose a publication profile Use the general publication, arXiv, IEEE, ACM, journal, or thesis profile that best matches the destination. Profiles cover requirements stable enough to check automatically. Then open the current venue instructions. Page limits, margins, file-size caps, anonymization rules, and naming conventions change too often for a generic profile to decide them. ## See what another reader receives **What the reader sees** extracts the PDF text page by page. Use it to catch a two-column paper read across the page, a missing icon-font phone number, a caption in the wrong place, or a page with no selectable text. For resumes, **What a parser extracted** shows the name, email, phone, links, and standard sections the ATS simulation could recover. These views are evidence, not a substitute for testing with the real submission portal, screen reader, or parser used by your audience. ## PDF/UA and accessibility: the honest boundary Oleafly checks the part of PDF/UA-1 that it can read from the file. Findings cite PDF/UA-1, PDF/UA-2 where it differs, Matterhorn Protocol checkpoints, and WCAG 2.2 PDF techniques. The report covers machine-readable signals such as: - a tag tree that contains real content; - alternative text on figures and formulas; - header cells in tables; - heading progression; - document language and XMP title; - the viewer preference that displays the title; - link descriptions and suspicious untagged content; - whether a declared PDF/UA-1 claim is backed by the file. The panel reports how many of 106 machine-checkable PDF/UA-1 rules were verified. It also tells you when a rule could not be read or did not apply. An unchecked rule is not counted as a pass. :::caution[Preflight does not certify PDF/UA] This is a subset check, not a conformance statement. Oleafly cannot decide whether alternative text is meaningful, reading order makes sense to a person, color contrast is sufficient, or the document works well with a reader's assistive technology. For a formal conformance result, validate the final file with veraPDF or PAC 2024 and complete a human review. ::: ## Prepare a tagged PDF LaTeX tagging depends on the document class, packages, engine, and TeX Live version. Preflight checks the effective main document and the preamble files it loads before offering preparation. 1. Run **Accessibility** on the current PDF and read the findings. 2. Open **Accessible export**. 3. Check the class and package compatibility report. An incompatible class blocks preparation; a partly compatible or unknown package appears as a warning. 4. Choose **Prepare for accessible export** and review every proposed source change. 5. Replace each generated alternative-text placeholder with a meaningful description and add the document title when requested. 6. Compile with pdfLaTeX or LuaLaTeX from TeX Live 2025 or newer. Accessible math needs LuaLaTeX. 7. Run Accessibility again, inspect the reader view, then validate the final PDF outside Oleafly when conformance matters. Preparation can add or update `\DocumentMetadata` with language, PDF/UA-2 intent, and tagging; declare a first table-header row; add visible placeholders for missing figure alternatives; and add `unicode-math` when the chosen engine needs it. It shows the changes before applying them. The bundled Tectonic engine cannot create a tag tree. **Compile tagged and verify** uses an available system TeX distribution or Oleafly's managed TinyTeX. You can also compile the prepared source with your own current toolchain. :::note[Compatibility can be the blocker] Preflight uses the LaTeX Project's published tagging-status data. Unsupported classes are blocked, partly supported classes are marked with a caution, and packages not present in the data are treated as unknown rather than assumed safe. `enumitem` is currently blocked because it cannot be loaded in the tagged workflow. ::: See [LaTeX engines & packages](/docs/latex-engines/) for TinyTeX, package status, and the security boundary around system TeX. ## A practical final pass 1. Compile the exact source you intend to submit. 2. Run all relevant Preflight checks. 3. Fix verified findings and investigate advisories. 4. Complete every manual item against the current venue guide. 5. Read the final PDF from first page to last, including references and appendices. 6. Open the exported file and source archive from their saved locations. 7. Use the destination's own validator before the deadline. Preflight reduces avoidable surprises. Acceptance, accessibility, and scientific correctness still require the author, the venue, and the people who will use the document.