Observed issue
Archicad PDFs often pass layout review and still cause problems after export. Authors and recipients report viewer lag on fill-heavy pages, failed opens, slow printing, large transfers, manual set splitting, and rework. The layout looks fine. The PDF structure may not be. The author often does not know why their own machine struggles.
Symptoms
- Authors and recipients see PDF viewers stutter, drop frames, or hang on specific fill-heavy pages while other sheets in the same file behave normally.
- Print jobs that stall or fail on base office printers. Most sites use general office devices without a Fiery RIP. That does not remove complexity from the PDF.
- Authors or recipients cannot open or print reliably and use Print as Image or partial exports instead.
- Low page count with high megabytes, or small files that still slow review software.
- Sets that pass layout check but degrade in PDF viewers, on portal upload, or when sent externally.
- Repeated re-exports because the file seemed acceptable at publish time but failed in use.
- Manual set splitting after complaints about opening or printing, from inside or outside the office.
Why it is missed
Publishing is checked for sheet content, line weights, views, and title blocks. That checks layout output. It does not check PDF structure.
Common sources of hidden weight:
- Site plans with geometry that exports as dense vector data, often over large surfaces.
- Vector fills across large areas that read cleanly in layout but not in PDF path data.
- Embedded images at higher effective DPI than the output needs.
- Hairline and sub-point edges that are visually fine but numerically heavy.
Without a structural read, the author and recipient both treat the PDF as finished when it is still a stack of drawing operators.
Fills, vectors, and raster
A PDF page is a sequence of drawing instructions, not a single image.
- Raster: embedded bitmaps. Weight follows pixel count and effective DPI on the sheet.
- Vector: paths, lines, curves, fills. Weight follows operator count and path density, not file size alone.
- Fills: solid areas, hatches, and exported geometry can produce many short edges when flattened.
A sheet can look simple in layout and still carry thousands of sub-threshold edges. Path counts and edge-length histograms show this. Layout view does not.
Review and print
PDF viewers do not render every page at equal overhead. Fill-heavy vector pages load GPU and CPU during pan, zoom, and page changes. Authors and recipients report frame drops or freezes on specific sheets while the rest of the set scrolls normally.
The author’s desktop or laptop may struggle with the same file Archicad exported without warning. The layout looked correct. The PDF structure may not be. The author may not connect viewer lag or a failed print to what is inside the file.
Printing adds another layer. Most offices use general base printers without a Fiery RIP. Removing Fiery from the path does not make the PDF simple. Overly complex vector content can still fail, stall, or force Print as Image on office hardware.
Reports on heavy Archicad PDFs:
- One or two pages stall review software while neighbouring sheets in the same file do not.
- Oddly built site plans or large vector fills that look acceptable in layout.
- Authors or recipients cannot print without rasterising the page or exporting images first.
- Hairline and micro-edge content that survives export and adds rendering load.
- High-DPI embedded images add work even when the sheet is A1 or A0 at practical scale.
Archicad can produce a valid layout PDF that is still hard to open, scroll, or print on the author’s machine, a recipient’s, or a base office printer.
Online PDF optimisers
When a file is slow or fails to print, authors and recipients often upload it to a generic online PDF optimiser. Many return a smaller file with little or no report of what changed: which pages were altered, what was rasterised, or what was removed.
They also rarely state clearly what happens to uploaded files: retention period, storage location, or who can access the content. For issued drawing sets, that raises privacy and copyright questions the uploader may not have considered.
A smaller file is not proof of a safe or appropriate fix.
File size vs complexity
File size and rendering overhead are related but not the same.
- A large file may be large because of a few heavy images. That is usually easy to locate.
- A smaller file can still be slow if it carries dense vector operators, hairlines, or sub-point edges across many sheets.
- Page count alone is a weak signal. Per-page path, image, and DPI counts are more useful.
Checking megabytes alone misses files that fail in PDF viewers on modest hardware, whether that hardware belongs to the author or the recipient.
What Archicad does not report
Archicad publishing produces sheet output from the model and layout set. It is not a PDF preflight tool.
The publish dialog does not typically show:
- effective embedded image DPI per sheet,
- path or hairline counts,
- edge-length distribution,
- which pages are likely to stress PDF viewers on external hardware.
That information has to come from a separate review step.
Why per-page counts help
Per-page structure makes it possible to flag sheets before issue rather than after an author or recipient uses Print as Image or an online upload tool.
- Authors can see heavy sheets before publishing, not only after their own viewer lag or a recipient complaint.
- Document control can identify heavy sheets before external issue.
- BIM leads can relate export settings to observed DPI and vector density.
- Recipients spend less time on files that fail to open or print on first pass.
- Optimisation or re-export can target specific pages instead of the whole set.
PDF Analyser
PDF Analyser comes from an existing manual process: export from Archicad, then inspect in Adobe Acrobat and Illustrator to find heavy pages, fills, and images. The beta tool at pdf.vktrs.co (v0.1.0) automates part of that read in the browser.
It reports:
- file size, page count, image count, path count,
- image pixel totals and effective DPI bands,
- vector counts: paths, lines, curves, hairlines,
- sortable per-page breakdown,
- page preview with edge-length and DPI overlays,
- edge-length histograms for sub-point content.
It does not modify, compress, or rewrite the file.
Browser-only
The current beta parses the PDF in the browser. No upload step in the flow tested on 2026-05-20. The file remains on the user’s machine. Results stay in the session until the page is reset or closed.
That keeps the file under the author’s control for the whole inspection process. Free online PDF services rarely disclose what happens to uploaded drawing sets, and their handling of user data is often unclear or unstated.
Optimisation
The analyser reports structure. A VKTRS optimisation tool does not yet exist as an active service; it is a possible next step once enough export and rendering patterns are understood. Inspect first, then decide whether to re-export, simplify the source file, or define a controlled post-processing workflow.
This LOG will be updated as we collect more data on export settings, recipient opening behaviour, and useful default thresholds.