Autodesk Revit Quiz: Print Export Troubleshooting
10 questions · exam conditions
0:00
Print Export TroubleshootingQuestion 1 of 10

A Revit sheet is exported to PDF at the correct size. Measuring within the PDF confirms that the drawing scale is accurate. However, the paper copy produced from the PDF is smaller because the PDF viewer's print dialog is set to Fit.

Where should the scaling problem be corrected?

In Revit, by enlarging the title block before exporting another PDF.
In Revit, by assigning a larger scale to each sheet viewport.
In the PDF viewer, by printing at Actual Size or 100%100\%.
In the PDF viewer, by increasing output resolution without changing page sizing.
← Back to quizzes

Autodesk Revit Quiz

Autodesk Revit Quiz: Print Export Troubleshooting

Practice Print Export Troubleshooting in Autodesk Revit with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Print Export Troubleshooting, giving you a quick way to practice the rules, question types, and explanations that matter most for Autodesk Revit.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A Revit sheet is exported to PDF at the correct size. Measuring within the PDF confirms that the drawing scale is accurate. However, the paper copy produced from the PDF is smaller because the PDF viewer's print dialog is set to Fit.

Where should the scaling problem be corrected?

  1. In Revit, by enlarging the title block before exporting another PDF.
  2. In Revit, by assigning a larger scale to each sheet viewport.
  3. In the PDF viewer, by printing at Actual Size or 100%100\%. (correct answer)
  4. In the PDF viewer, by increasing output resolution without changing page sizing.
Explanation: When troubleshooting a scaling problem in print workflows, your first step is to identify where in the chain the distortion is introduced. The question tells you the PDF itself is correct — measurements inside the PDF confirm accurate scale — so the problem exists entirely in the print step, not in Revit. Because the PDF is already accurate, C is the correct fix: changing the PDF viewer's print setting from Fit to Actual Size (or 100%100\%) tells the printer to output the file at its true dimensions without any resizing. "Fit" automatically shrinks or enlarges the page to fill the printer's imageable area, which is exactly what's causing the smaller paper copy. Choice A is wrong because enlarging the title block in Revit would corrupt the drawing's geometry and annotation — it doesn't address the print dialog setting, and it would produce an incorrectly sized PDF to begin with. Choice B is similarly misguided: changing viewport scales in Revit alters what the drawing represents, not how it prints. You'd end up with a different drawing, not a correctly printed one. Choice D is a trap — output resolution controls image sharpness (DPI), not page sizing. Increasing resolution has no effect on whether the page is scaled to fit the paper; those are entirely separate settings. A useful rule of thumb: always verify at which stage in your workflow the error occurs before making any changes. If the digital file is confirmed correct, the fix lives in the output settings — never go back and alter the source document unnecessarily.

Question 2

A vector PDF appears to lose several very fine lines when viewed as a full page on a laptop. When the PDF is magnified, the lines become visible, and a test print shows the intended lineweight hierarchy.

What is the best conclusion before modifying the Revit model?

  1. The lineweight mapping is invalid and should be increased for all fine-line categories.
  2. The apparent omission is a PDF display artifact at the current screen zoom. (correct answer)
  3. The sheet was exported at the wrong scale and requires Fit to Page.
  4. The fine lines were rasterized and require a lower output resolution.
Explanation: When troubleshooting lineweight visibility issues in Revit workflows, always gather all available evidence before making changes to the model. Here, you have three data points: lines disappear at full-page view, lines reappear when zoomed in, and a physical print confirms the lineweights are correct. That pattern points directly to a rendering/display limitation, not a modeling problem. Vector PDFs render lines mathematically, meaning extremely thin lines can fall below the pixel threshold of your screen at low zoom levels — the monitor simply doesn't have enough pixels to represent a sub-pixel-width stroke. When you zoom in, the line occupies more pixels and becomes visible. When you print, the printer's higher DPI resolves those fine strokes without issue. This is the classic PDF display artifact, making B the correct conclusion: the apparent omission is a screen zoom artifact, and no model changes are needed. Choice A is a trap — because the print confirms correct lineweight hierarchy, there is no evidence the lineweight mapping is wrong. Increasing lineweights across categories would actually corrupt your intended hierarchy based on faulty reasoning. Choice C misdiagnoses the problem entirely; export scale affects geometry proportions, not whether thin lines disappear selectively at certain zoom levels. Choice D confuses the issue — the PDF is described as a vector file, so rasterization isn't the cause; rasterization artifacts typically appear as blurry or blocky edges, not missing lines that reappear on zoom. The key strategy here: always check print output before editing the model. On Revit exam questions, when print results match intent but screen display doesn't, the screen is the suspect — not the model.

Question 3

A Revit model is exported to DWG. In the receiving CAD application, every measured object is exactly 25.425.4 times larger than expected, while the geometry remains proportionally correct. View scales and sheet layouts in Revit are correct.

Which issue most likely produced this result?

  1. The Revit sheet was exported using raster rather than vector processing.
  2. The Revit view was exported with Thin Lines temporarily disabled.
  3. The DWG lineweight table uses widths intended for another plot scale.
  4. The export and receiving applications interpret the DWG units differently. (correct answer)
Explanation: When exporting between Revit and CAD applications, the most critical compatibility issue to watch for is unit interpretation. DWG files store raw numeric coordinates but carry no absolute unit enforcement — the receiving application must be told what unit those numbers represent. The telltale clue here is the factor 25.425.4, which is precisely the number of millimeters in one inch. This means one application treated the drawing units as inches while the other treated them as millimeters. Every object appears 25.4×25.4\times too large (or too small) because the geometry is correct proportionally — only the unit label attached to those numbers differs. Answer D is correct: a mismatch between the export unit setting in Revit's DWG Export dialog and the unit assumption in the receiving CAD application produces exactly this scaled-but-proportional distortion. Answer A is wrong because raster vs. vector processing affects image quality and editability, not dimensional scale. A raster export might look pixelated, but it wouldn't cause a precise 25.4×25.4\times size error. Answer B is wrong because Thin Lines is a display toggle that affects on-screen line weight appearance only; it has no effect on exported geometry or dimensions. Answer C is wrong because lineweight tables control how thick lines plot on paper — they don't alter the coordinate values that define object size in model space. As a study tip, remember that any time you see a scale error that equals a clean unit-conversion factor (25.425.4, 304.8304.8, 10001000, etc.), suspect a units mismatch first. Always verify the "Export units" setting in Revit's DWG Export options matches the target CAD application's drawing units.

Question 4

Door lines print correctly in most plan views, but they print unusually heavy in one code plan. Object Styles assigns the correct door lineweight throughout the project. The code plan is controlled by a view template containing several filters.

What should be checked before changing the project-wide door settings?

  1. The DWG layer mapping assigned to the Doors model category.
  2. The printer driver's default paper orientation for the code-plan sheet.
  3. The code plan's view-template and filter graphic overrides for doors. (correct answer)
  4. The raster resolution selected for every printed view in the project.
Explanation: Whenever you see a Revit question about inconsistent graphic display in a specific view, your first instinct should be to investigate what is controlling that view's appearance locally — not project-wide settings. Revit applies a graphic override hierarchy: Object Styles sit at the bottom as the default, but View Templates, Visibility/Graphics overrides, and Filters all sit on top and take priority. In this scenario, Object Styles correctly defines door lineweights everywhere else, which tells you the project-wide setting is fine. The code plan, however, has a View Template with multiple filters. Filters in Revit can override lineweights, colors, and patterns for specific categories or elements matching a rule. If a filter targets doors (or a superset that includes doors) and assigns a heavy lineweight, that override will win — regardless of Object Styles. Checking the View Template's filter overrides, as answer C describes, is exactly the right next step before touching anything project-wide. Answer A is a distractor because DWG layer mapping only affects exported CAD files, not how views print from within Revit. Answer B misleads you toward a hardware/driver explanation, but paper orientation has no effect on lineweight rendering. Answer D points to raster resolution, which affects image quality for rasterized elements, not vector lineweights for model categories like doors. The key study tip: anytime a problem is isolated to one view, suspect local overrides — View Template settings, Visibility/Graphics, or Filters — before assuming a project-wide or hardware cause. Revit's override hierarchy (Filters → VG Overrides → Object Styles) is a frequent exam topic, so memorize the order.

Question 5

A sheet is configured for the correct title-block size, but a printed dimension check shows that the entire sheet is approximately three percent smaller than intended. The Print Setup uses Fit to Page, and the printer is set to the same nominal paper size as the title block.

Which change is most likely to restore the intended physical scale?

  1. Set print zoom to 100%100\% and confirm the matching paper size and orientation. (correct answer)
  2. Increase every viewport scale by approximately three percent before printing the sheet.
  3. Increase the raster resolution while keeping Fit to Page enabled.
  4. Reduce the title-block margins until they match the printer's printable region.
Explanation: When Revit prints a sheet, the Fit to Page setting scales the entire output to fill whatever printable area the printer driver reports — which is always slightly smaller than the nominal paper size due to hardware margins. That shrinkage (commonly 2–4%) is exactly the symptom described here. The fix is to switch from Fit to Page to a fixed 100% zoom, then confirm the paper size and orientation match the title block. At 100%, Revit sends geometry at true scale, and the printer reproduces it without any automatic scaling factor applied. That's why A is correct. Option B is a trap because adjusting viewport scales compensates in the wrong place. Even if you scale viewports up by 3%, Fit to Page will still shrink the entire sheet by the same margin offset — you'd be chasing a moving target and corrupting every annotation and dimension ratio in the model. Option C misunderstands what raster resolution controls. Raster DPI affects print quality (smoothness of curves and gradients), not the physical output size. Raising it while keeping Fit to Page enabled leaves the scaling problem completely untouched. Option D confuses the title-block boundary with the printer's printable region. Shrinking margins in the title block doesn't change how the printer driver reports its printable area, so the Fit to Page calculation remains unchanged and the output is still undersized. Study tip: On Revit print questions, always ask yourself where the scaling decision is made — in the model, in the viewport, or in the print driver. Fit to Page operates at the driver level, so it overrides everything else unless you explicitly set a fixed zoom percentage.

Question 6

A shaded view must be printed using Raster Processing. The physical dimensions of the sheet are correct, but diagonal edges are jagged and closely spaced fine lines merge in the PDF. The category lineweights are known to be correct.

Which adjustment should be tested first?

  1. Change the shaded view to wireframe while retaining its presentation effects.
  2. Increase print zoom and use Fit to Page to restore sheet dimensions.
  3. Reduce all model-category lineweights before producing the next PDF.
  4. Increase raster quality or output resolution without changing print zoom. (correct answer)
Explanation: When Revit prints a shaded view using Raster Processing, the view is essentially rendered as a bitmap image before being embedded in the PDF. The quality of that bitmap — how sharp edges appear and how fine lines are resolved — is controlled by the raster quality / output resolution setting, not by lineweights or zoom level. Whenever you see symptoms like jagged diagonal edges and merging fine lines in a raster-printed PDF, your first diagnostic question should be: "Is the resolution high enough?" Increasing raster quality or DPI (answer D) directly addresses both symptoms. Higher resolution means more pixels per inch, which smooths diagonal edges through finer sampling and gives fine lines enough pixel space to remain distinct rather than collapsing into one another. Crucially, the problem states that sheet dimensions are already correct, so D targets the root cause without disturbing the output size. Answer A is a trap — switching to wireframe removes the shading entirely, which defeats the purpose of the shaded view and doesn't fix a resolution problem. Answer B misunderstands the mechanism: increasing print zoom would enlarge the output beyond the intended sheet size, distorting dimensions, and "Fit to Page" would simply shrink it back down, netting zero improvement in image quality. Answer C is ruled out by the passage itself, which explicitly states that lineweights are known to be correct, so reducing them wastes time and could harm drawing legibility. Study tip: On Revit print-quality questions, always map the symptom to its setting. Jagged/merged raster artifacts → resolution. Wrong sheet size → zoom/fit. Wrong line thickness → lineweight. These are distinct controls with distinct effects.

Question 7

Section and elevation markers are visible on a sheet in Revit but are missing from a PDF created through the Print command. The affected markers reference views that have not been placed on sheets. Other annotations print normally.

Which print setting is the most likely cause?

  1. Hide Unreferenced View Tags is enabled in the print setup. (correct answer)
  2. Hide Crop Boundaries is enabled in the print setup.
  3. Replace Halftone with Thin Lines is enabled for the printer.
  4. Raster Processing is enabled for the selected sheet views.
Explanation: When you see a Revit print question where specific annotation types are missing but others print fine, your first instinct should be to look for a print setup option that targets that specific category of annotation — not a global display or rendering setting. Revit's print setup includes an option called Hide Unreferenced View Tags. When enabled, this setting suppresses section markers, elevation markers, callouts, and other view reference tags only if the view they reference has not been placed on a sheet. This matches the scenario exactly: the markers reference views that haven't been placed on sheets, and they disappear in print while other annotations remain visible. That points directly to option A as the culprit. Option B, Hide Crop Boundaries, controls whether the dashed crop region boundary appears in print — it has no effect on section or elevation markers whatsoever. Option C, Replace Halftone with Thin Lines, is a graphics override that converts halftone elements to thin lines; it doesn't selectively hide view tags. Option D, Raster Processing, changes how the print engine renders the sheet (vector vs. raster) and can affect image quality or certain linework, but it does not filter annotations based on whether their referenced views are on sheets. The diagnostic clue in this question is the phrase "reference views that have not been placed on sheets." That language maps directly to the word "Unreferenced" in the setting name. On the Revit exam, when a question describes missing annotations tied to a sheet-placement condition, immediately think of the Hide Unreferenced View Tags setting in Print Setup.

Question 8

A floor plan displays all model edges with the same thin appearance while Thin Lines is enabled. After printing, walls have the expected heavy outlines, but casework lines are still lighter than required.

Which action most directly corrects the casework lineweights in the printed output?

  1. Disable Thin Lines and print again using the existing view settings.
  2. Increase the casework category lineweight in Object Styles or Visibility/Graphics. (correct answer)
  3. Change the print color setting from black lines to grayscale output.
  4. Increase the raster quality while retaining the current category settings.
Explanation: When troubleshooting lineweight problems in Revit, you need to distinguish between display behavior and print behavior. Thin Lines is a display-only toggle that overrides how lines appear on screen — it has no effect on printed output. This is a critical distinction the exam loves to test. Since the walls printed correctly but casework did not, the problem is clearly category-specific lineweight settings. In Revit, each category (walls, casework, furniture, etc.) has its own lineweight assignments controlled through Object Styles (Manage tab → Object Styles) or overridden per-view through Visibility/Graphics (VG shortcut). Increasing the lineweight value assigned to the casework category in either location directly controls how thick those lines appear in print. That makes B the correct action — it targets the exact setting responsible for the output discrepancy. A is wrong because disabling Thin Lines only changes the screen display, not the underlying category lineweights. The printed result would be identical since Thin Lines never affected printing to begin with. C is a trap — switching from black to grayscale changes color mapping, not lineweight thickness. Lighter casework lines would still be thin regardless of the color mode. D increasing raster quality improves image resolution for elements like hatching or images, but it does not reassign lineweight values to any category; casework would remain the same weight at higher resolution. A useful rule of thumb: if the problem is display only, think Thin Lines or View Templates; if the problem is print output, think Object Styles and Visibility/Graphics overrides.

Question 9

A presentation view contains transparency and shadows. Model edges export correctly using Vector Processing, but several of the visual effects are absent or inconsistent in the PDF. Exact sheet dimensions must remain unchanged.

What is the most appropriate troubleshooting step?

  1. Switch to Raster Processing and verify the output at the required resolution. (correct answer)
  2. Enable Thin Lines before printing and retain Vector Processing for the view.
  3. Use Fit to Page so the PDF driver can include all visual effects.
  4. Increase model-category lineweights before printing with Vector Processing again.
Explanation: When troubleshooting PDF export quality in Revit, you need to understand the fundamental difference between Vector and Raster Processing. Vector Processing converts geometry into mathematical lines, which is excellent for crisp edges and precise dimensions — but it cannot accurately render visual effects that depend on pixel-level blending, such as transparency and shadows. Raster Processing, by contrast, converts the entire view into a pixel image, preserving those complex visual effects at whatever resolution you specify. Since the passage describes missing transparency and shadows — classic limitations of Vector Processing — switching to Raster Processing (answer A) directly addresses the root cause. The key qualifier is "verify the output at the required resolution," because raster output quality depends on DPI settings; choosing an appropriate resolution ensures the sheet dimensions remain accurate without scaling distortion. Answer B misses the point entirely. Enabling Thin Lines affects how lineweights display on screen during modeling and is irrelevant to PDF export fidelity. Keeping Vector Processing doesn't solve the transparency and shadow problem — it perpetuates it. Answer C introduces a dangerous error: using Fit to Page rescales the sheet to fill the paper, which the question explicitly forbids since exact sheet dimensions must remain unchanged. It also wouldn't restore missing visual effects. Answer D is a red herring. Increasing lineweights adjusts line thickness but has no bearing on transparency or shadow rendering. Running Vector Processing again with heavier lines still won't produce the missing effects. Your study tip: memorize this rule — Vector Processing = precise lines, no complex effects; Raster Processing = visual richness, resolution-dependent. Exam questions often pair a visual-quality complaint with a processing-mode fix.

Question 10

A floor plan has clearly differentiated lineweights when printed from Revit. After export to DWG, the recipient reports that all layers display and plot with nearly the same line width. Category-to-layer assignments are otherwise correct.

Which setting should be reviewed first in Revit?

  1. The lineweight mapping in the active DWG export setup. (correct answer)
  2. The linetype pattern definitions in the active DWG export setup.
  3. The coordinate origin option in the active DWG export setup.
  4. The color mapping method in the active DWG export setup.
Explanation: When exporting from Revit to DWG, lineweights don't transfer automatically — Revit must explicitly map its internal lineweight numbers (1–16) to DWG pen weights or line widths. This mapping lives inside the DWG export setup, and when it's misconfigured, everything collapses to a nearly uniform line width on the recipient's end, even though the original Revit views look perfectly differentiated. That's exactly the symptom described here. A is correct because the lineweight mapping table within the DWG export setup controls how Revit's lineweight numbers translate into the numeric line widths stored in the exported DWG file. If this table isn't configured — or if all entries default to the same value — every layer will carry the same plot width, regardless of what category it belongs to. B is wrong because linetype pattern definitions control dash-dot sequences and spacing, not line thickness. Mismatched linetypes would cause dashed lines to appear solid, not uniform widths across all layers. C is wrong because the coordinate origin option governs how the geometry is positioned in the DWG coordinate space. It has no bearing on visual weight or line width whatsoever. D is wrong because the color mapping method determines how Revit's colors translate to DWG color indices (ACI numbers). While color-dependent plotting can affect pen width in legacy CAD workflows, the question specifies that layer assignments are already correct and the symptom is width uniformity — pointing directly to the lineweight mapping, not color. As a study tip: in DWG export troubleshooting questions, match the symptom to the setting. Uniform line widths → lineweight mapping; wrong dash patterns → linetype definitions; geometry misplacement → origin settings.