Vector PDF prints dashed linetypes as continuous

[badileanu (Razvan Badileanu)]

I noticed an issue when printing a Layout to PDF using Vector Output.

Dashed linetypes display correctly in both Model Space and Layout, but they are printed as continuous lines in the resulting PDF.

Steps to reproduce:

1. Create a curve and assign the standard Dashed linetype.
2. Create a Layout / Detail where the dashed line displays correctly.
3. Print using Rhino PDF → Vector Output.
4. Use Match viewport display for linetypes.

Dashed linetypes display correctly in the Layout, but become continuous when printing with Rhino PDF → Vector Output.

Match viewport display is enabled.

The same Layout prints correctly with Raster Output.

This happens with regular Rhino curves as well as VisualARQ grid axes.

Layout — expected:

I attached the PDF generated with Rhino PDF

I can reproduce the same issue in both Rhino 8 and Rhino 9 WIP.

Is this a known issue with vector printing?

Page 5.pdf (757.4 KB)

[wim (Wim Dekeyser)]

Hi Razvan -

@badileanu

Steps to reproduce:

1. Create a curve and assign the standard Dashed linetype.
2. Create a Layout / Detail where the dashed line displays correctly.
3. Print using Rhino PDF → Vector Output.
4. Use Match viewport display for linetypes.

Following these steps, I see this:

Which results in this PDF:

Please always post your SystemInfo data and a 3dm file that can be used to troubleshoot.
-wim

[badileanu (Razvan Badileanu)]

Hi Wim,
I found the difference between your test and mine.
With Linetype Scale = 1, the PDF output works correctly here as well. However, at that value the standard Dashed linetype is not usable at the size of the geometry in my drawing — the pattern is simply too large.

I therefore need to reduce the Linetype Scale for the dashed line to display normally.
The problem is that with smaller Linetype Scale values, the linetype displays correctly in the viewport and also in Print Preview, but the resulting Rhino PDF – Vector Output becomes continuous.

opening scheduler.3dm (634.3 KB)

Summary

Rhino 8 SR35 2026-9-8 (Rhino 8, 8.35.26251.13001, Git hash:master @ 3645d710f50175d8ebcf404aded5b042a481c23e)
License type: Commercial, build 2026-09-08
License details: Cloud Zoo

Windows 11 (10.0.26200 SR0.0) or greater (Physical RAM: 15GB)
.NET 8.0.20

Computer platform: LAPTOP - Plugged in [97% battery remaining]

Non-hybrid graphics configuration.
Primary display and OpenGL: NVIDIA GeForce RTX 4060 Laptop GPU (NVidia) Memory: 8GB, Driver date: 7-22-2026 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 610.88

Integrated accelerated graphics device with 4 adapter port(s)

• Windows Main Display is laptop’s integrated screen or built-in port
  Primary OpenGL: NVIDIA GeForce RTX 4060 Laptop GPU (NVidia) Memory: 8GB, Driver date: 7-22-2026 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 610.88

Integrated accelerated graphics device with 4 adapter port(s)

• Windows Main Display is laptop’s integrated screen or built-in port

Secondary graphics devices.
AMD Radeon 780M Graphics (AMD) Memory: 1GB, Driver date: 12-5-2023 (M-D-Y).

Integrated accelerated graphics device with 10 adapter port(s)

• This device is not being used

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
GPU Tessellation is: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 3.3

Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High

Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 7-22-2026
Driver Version: 32.0.16.1088
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 8188 MB

Rhino plugins that do not ship with Rhino
C:\Program Files\Rhino 8\Plug-ins\Tibidabo\VisualARQ.rhp “VisualARQ”
C:\Program Files\Rhino 8\Plug-ins\Tibidabo\Tibidabo.rhp “Tibidabo”

Rhino plugins that ship with Rhino
C:\Program Files\Rhino 8\Plug-ins\Commands.rhp “Commands” 8.35.26251.13001
C:\Program Files\Rhino 8\Plug-ins\WebBrowser.rhp “WebBrowser”
C:\Program Files\Rhino 8\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 8\Plug-ins\RhinoScript.rhp “RhinoScript”
C:\Program Files\Rhino 8\Plug-ins\IdleProcessor.rhp “IdleProcessor”
C:\Program Files\Rhino 8\Plug-ins\RhinoRenderCycles.rhp “Rhino Render” 8.35.26251.13001
C:\Program Files\Rhino 8\Plug-ins\RhinoRender.rhp “Legacy Rhino Render”
C:\Program Files\Rhino 8\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 8.35.26251.13001
C:\Program Files\Rhino 8\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 8\Plug-ins\MeshCommands.rhp “MeshCommands” 8.35.26251.13001
C:\Program Files\Rhino 8\Plug-ins\IronPython\RhinoDLR_Python.rhp “IronPython” 8.35.26251.13001
C:\Program Files\Rhino 8\Plug-ins\RhinoCycles.rhp “RhinoCycles” 8.35.26251.13001
C:\Program Files\Rhino 8\Plug-ins\Grasshopper\GrasshopperPlugin.rhp “Grasshopper” 8.35.26251.13001
C:\Program Files\Rhino 8\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 8.35.26251.13001
C:\Program Files\Rhino 8\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 8\Plug-ins\Displacement.rhp “Displacement”
C:\Program Files\Rhino 8\Plug-ins\SectionTools.rhp “SectionTools”

[djnelson75]

Humm. It seems to be working for me here, unless I am missing something. The lines that you have the linetype scale set to .01 print as dashed and not continuous.

[badileanu (Razvan Badileanu)]

Thanks for testing it. I think there is one important detail that may not be clear from the screenshots:

D01, D02 and D03 are all using the same Dashed linetype.

D01 and D02 have the same linetype scale, while D03 uses a different scale. So D03 is not a Continuous line — it only appears continuous because of the scaling.

In your test, the printed output seems to reproduce what you see in Model Space, but D03 is still a Dashed line even though the dashed pattern is no longer visible.

On my system the situation is even more confusing: the appearance in the Layout/printed output is essentially reversed compared with Model Space.

I also tested both Match pattern definition and Match viewport display, and they produce the same result.

This is what I’m trying to understand: what should I use as the reliable reference when adjusting a linetype — its appearance in Model Space or its appearance in the Layout/printed output?

Resulting PDF output

[djnelson75]

I the reason there is discrepancy between the model space and paper space is because of the units your are using. It looks like model space is set to "printer points’ and your paper space is set to millimeters? To be honest I am not sure how printer point scale in relation to millimeters. If you know what this is the to get the model space to look correct you would set the global model space to that value. Or if you used millimeters for both things I think would be clearer.

[badileanu (Razvan Badileanu)]

Thanks. My Model units are already set to Printer points, as shown below.

I don’t think the unit choice itself explains the discrepancy, though. Printer points and millimeters are simply different units of measurement; changing between them should affect the numerical size/scale, not the consistency of the linetype representation between Model, Layout and the final vector PDF.

[djnelson75]

@badileanu

My Model units are already set to Printer points, as shown below.

No I am saying that I don’t know why they are set to printer points.

@badileanu

Printer points and millimeters are simply different units of measurement; changing between them should affect the numerical size/scale

Linetypes are like annotation objects and get scaled up and down depending on what you are working with. That is what the model linetype scale is for, you set it to match the layout space scale. Say you are drawing a plan that is going be 1:100 in layout space. In order to get the linetypes to show correctly in model space you need to set the model linetype scale to 100.

[djnelson75]

Actually Rhino shows the conversion for printer points to millimeters.

So essentially your detail view is getting scaled down by .327 if you set the model linetype scale to .327 model space will match layout space.

That is why I said if set the model space units to millimeters to match your layout space things will be come clearer. That way you can work in a 1:1 relationship

[badileanu (Razvan Badileanu)]

Thanks again, I understand what you meant now. You were right about the Model linetype scale.

I made a clean test with:

• Model units → millimeters
• Annotation Style → Model space scale = 5
• Linetypes → Model space scale = 5
• Detail → 1:5

With these settings, Model Space gives me the representation I expect for a 1:5 drawing, and the Layout is correct as well.

If I change only the Linetype Model space scale back to 1, the linetype becomes much denser in Model Space, while the Layout remains unchanged.

So I understand how Rhino handles this now.

What I find unnecessarily complicated is having to manually keep these separate Model Space scale settings synchronized.

Why isn’t there a single Model Space representation scale that annotations, linetypes, hatches, etc. can follow by default, while still allowing individual overrides when needed?

[djnelson75]

@badileanu

Why isn’t there a single Model Space representation scale that annotations, linetypes, hatches, etc. can follow by default, while still allowing individual overrides when needed?

I think there was some talk about that in the past, where there was just 1 setting to control annotations, linetypes and hatches, as having to go into each one and change setting is more complicated. I will see if I can dig up that thread.

[badileanu (Razvan Badileanu)]

Thanks! If you can find that thread, I’d be very interested to see it. In the meantime, I went ahead and created a separate wish with a small UI mock-up of what I had in mind:

[A unified Model Space representation scale]

It sounds like we may be talking about the same underlying idea.

[djnelson75]

I found one of them. This was back in 2014, wow I didn’t realize it was that long ago.

Linetype scaling in model space - Rhino / Rhino for Windows - McNeel Forum

[badileanu (Razvan Badileanu)]

Wow, 2014 indeed. Thanks for digging that up!
Interesting to see how long this question has been around.

[badileanu (Razvan Badileanu)]

I did some additional testing and found another, possibly separate, linetype display inconsistency.

With OpenGL 3.3, the same dashed linetype changes significantly depending on the Model Space zoom level, without changing the linetype or any scale settings. At certain zoom levels it matches the Layout representation, but as the zoom changes, the pattern changes as well and can appear almost continuous.

With OpenGL 1.1 / Software Driver (and also OpenGL 2.1), the dashed pattern isn’t displayed in Model Space at all and appears continuous.

In Layout with OpenGL 3.3, the same linetype remains stable and correct regardless of zoom.

This seems to be a separate viewport display issue rather than the original vector PDF issue, but I thought it was worth adding here since it affects the same linetype representation.

Update — I found the cause of the Model Space linetype behavior.

It was related to Linetypes > Model space scale and, more specifically, to how this setting relates to the intended drawing scale.

For example, with a model in meters and a desired representation of 1:50, I need:

• Annotation Model space scale: 0.05
• Hatch Model space scale: 0.05
• Linetype Model space scale: 50

I had assumed these Model Space scale settings followed the same convention.

With the linetype scale set correctly to 50, the linetypes are stable in Model Space and match the 1:50 Layout representation. The VisualARQ guides also display correctly.

So the behavior I reported here was caused by the scale configuration rather than the viewport itself.

I’m leaving this note here in case someone runs into the same issue.