Print order inconsistency bug

Rhino Rhino for Windows
1

This is a very old bug and it has been reported by others in the past.
The draw order of hatches from display to print is not the same…

Rhino print order inconsistency
Rhino print order inconsistency2058×1156 286 KB

2

There are a few open issues in this regard. This is the closest RH-28917 Print: print order does not always match draw order

3

is this really since 11 years :slight_smile:

4

Draw order has been challenging. There are a few others that are more recent but private due to user info attached.

5

was someone suggesting draw order by layer order?

6

order of the layers does affect draw order

7

so basically if i have the hatches and the lines and I want the lines in front, i should just put the layer of the lines on top of the layer of the hatches and not use bring to front or send to back?

8

With the hatches, linework needs to be sent back.

9

Why not create a menu for printdisplay where one can arrange the layers in the order of display?

10

This also affects SVG export - hatches don’t show in the right order when exporting. Which is actually super annoying because i try again and again to export something consistent and it’s not working…

11

Also the lineweights don’t match display sometimes.

image
image2316×1226 290 KB

12

Because hatches are typically meant to appear behind other drawing elements, I prefer placing them on a separate layer. This makes them easy to select later. If the draw order ends up incorrect, I can simply select all hatches and use SendToBack or SendBackward (as @Japhy mentioned earlier).

The same principle applies to other objects. For example, if you store all your cut lines—which usually have a thicker line weight—on one or more dedicated layers, you can quickly BringToFront or BringForward them whenever needed.

Instead of layers, you could also use named selections.

13

@diff-arch , this is what I also try, but trying 7 times to print something useful is not the right way to go.
Also, in my SVG export there were only hatches, without lines…

14

I understand your frustration, but that’s the way many CAD applications work. In AutoCAD, it’s mostly the same.

15

thank you for undestanding my frustration :sweat_smile: :man_facepalming:

16

Hi Bogdan -

We’d need a 3dm file to be able to troubleshoot this.
-wim

1 Like
17

Thanks for checking!
I just sent an email at tech@mcneel.com , your name is in the title.

SVG export has some serious issues, and it’s a pity because rhino is very good at vector graphics.

18

Hi Bogdan -

For this one, it looks like you’ll need to define the linetype with tapers in document units instead of pixels. You’ll then need to also modify the max width to be what is expected given the size of “paper” that you are printing to.
I’ve put this on the list as RH-94820 Print: Linetype with Taper - Width Issue
but I’m not so sure what the solution would be.
-wim

1 Like
19

Yes indeed! thanks for this explanation, it makes much more sense to consider document units instead of pixels.

I tested, for a 1 to 1 print on an A4 paper. I put the logo at scale, and adjusted the width of the tapered curves in mm. This produces a good PDF print and correct viewport capture.

image
image1952×1077 111 KB