Hello,
I need to report a couple issues in the BETA that we’ve noticed here:
The RHINO internal PDF creater (“Save PDF” while printing) seems to have a problem with line weights in details. They show correctly on screen but then print all the same in the PDF. I am particularly struggling with lines that have dashes and arrow heads all printing the same size regardless of line weight. I had to dig in the the advanced settings to revert to Adobe’s PDF printer to get the line weights to print correctly.
Along with the printing issue I have to click into and back out of each viewport before printing, otherwise the viewports won’t refresh and the edges of clipped surfaces will not appear.
This may also be related to a refresh issue, but additionally, text with functions in them (to say look up the view name or page number) won’t refresh when printing multiple pages. They will just print the values for the current page. for example I have 5 pages and the current page is #3. If I start a print job then all the page numbers on every page will print 3 instead of their actual page number.
Multi-line Rich Text seems to have a problem now in the latest build. If I save a document with multi-line text, only the last line is saved. All the other lines are replaced with blanks. So I’ll have three rows of blank lines and then the fourth and last row of text will show up when I reopen a document.
Randomly while working in paperspace, if I click into a viewport, dimensions will randomly fly off into space. If I zoom out then I can seem them far off from the page in a random part of the screen.
Sorry for the dump, but these are all issues that we have been fighting with today.
Hi Ian - thanks, I’ll check these. I believe #4 is fixed in the latest beta. Can you provide a simple example of #5 if you have one? Just exporting the wayward dimension and the thing it is dimensioning may be enough.
Hi Pascal,
Thats great to hear #4 is already fixed.
Unfortunately #5 is completely random and not repeatable. We’ve seen it occur in multiple drawings, but there is no clear pattern that causes the issue. the only common thread is that they are dimensions in paperspace that fly away randomly (usually only one random dimension per error) when you click into the viewport.
Sorry I can’t provide a nice simple model to show the error.
Hi Ian - so far this works here - what does the setting look like in the print dialog for line weights and line types?
Can you make a file that has one or two of these that prints incorrectly for you and post it here? There are multiple variables, it seems to me, I’d like to print exactly what you have.
Pascal,
I’ve attached an example drawing with two curves with different line weights. I’ve also attached the resulting PDF outputs with their printer settings. As the PDF shows, the Rhino PDF creator makes the line weights the same size while the Adobe PDF creator correctly prints the line weights differently.
Pascal,
I did have #5 happen to me again yesterday, but I can’t seem to make a small drawing that can recreate the error. Nor can I get my drawing to repeat the error. In this latest case I was manipulating linear dimensions that used the same reference point in a detail view. the Linear dimensions were in paperspace and when I moved one of the ends of the first linear dimension, the second dimension’s end flew off into the far reaches of the screen. I had to zoom way out to find the other end.
I’ll update you if I can make any more observations of the issue.
Pascal,
But if I go into the Detail, the detail print widths are 0.13 and 0.19 for the Thinner and Thicker layers respectively. Does the Rhino PDF creator only look at the ‘print widths’ and not the ‘detail print widths’?
Hi Ian - I see, - well… here I do get a difference in the print, albeit not a very big one, between .13 and .19. It’s more noticeable if you scale the line widths in the print dialog-
Pascal,
I can confirm that changing the line width scale does make the arrow heads and line weights show up. Is there a reason that the Adobe PDF creator shows the arrow heads and line weights without having to scale up the line weights, but I need to scale up for the Rhino PDF creator to have them show up? I don’t think scaling up the line weights is the right answer because then all of our other standard line widths get screwed up. And printing to any other device would result in incorrect line weights.
Hi Ian - it just looks buggy to me at the moment… the difference in width is not very large and we may just not be getting that fine-grained. I’ll get this on the heap. https://mcneel.myjetbrains.com/youtrack/issue/RH-43344
Hi Ian,
I’m currently working on this bug. I believe you can currently work around the issue by bumping the DPI up from 300 to 600 with the PDF printer.
What if you bump the DPI to 1200? Exposing this setting in the print dialog is kind of dumb with respect to vector output and really shouldn’t have much of an effect on file size
Steve,
Still no dice. The arrow heads get less fuzzy but they are the same size regardless of line weight.
This may be unrelated but I’ll offer it just in case. Depending upon the level of zoom the arrow heads on the screen in the viewport display all the same size. If I zoom in far enough then they display correctly, but zoomed out to see the entire page the arrow heads are all huge and all the same size.
Are you testing with the simple “two arrowhead” lines 3dm that you posted earlier in this thread? I’m just trying to make sure I am looking at the same thing as you are.
Sorry,
I was looking back at the drawing I’ve been working with. I should have stayed with the simplified model.
Using the simple drawing, the curves are printed in Vector format. And yes increasing the DPI does increase the Arrowhead size so that they display correctly.
Given this fact it appears that my drawing uses a view style that forces the detail view to be rastered, because the arrows in that view are fuzzy and don’t change size.
