Crashing Rhino while printing layout to pdf through acrobat pdf printer

Hi guys, Finally using the Beta for production and I end up with a file that repeatably crashes Rhino when I try to print a layout to pdf.
To whom and where do you want it uploaded?

It happens for me too, but after being patient for 5 minutes rhino responds again.

Well, I get a windows pop up telling me that rhino has stopped working:
(And Rhino disappears, so no need to wait :wink: )

I saved the file as V5 and did the printing there and it was ok. Then I saved it in V5 as v5 as well and this file also crashes v6 beta when i try to print it.

Is there a reason you are usin the Adobe PDF printer instead of the PDF printer that ships with Rhino? I’m considering just removing the Adobe PDF option since it has caused so many sporadic unrepeatable crashes over the years. Just curious to see if there is any decent reason to use that printer driver.

1 Like

I guess old habbits is the only reason :slight_smile:
It has worked for many years and should not crash V6.
But I’ll gladly try your PDF printer! I’ll check it out tomorrow.
Where do you want the file uploaded?

As I understand it, the Adobe PDF authoring tools are very sensitive to display driver glitches.
Our PDF printer, PDF995, BullZIP, or any of the Ghostscript based authoring tools, are not nearly as crash prone.

The odd thing is that it prints most of the file in the detail, but not the objects on the layout.

I’ll gladly use the new “printer” but I know that my colleague will forget and use the old, and will loose data as he won’t save before each print… so it should not crash… Be slow and throw an error is ok, but not crash and loose data :slight_smile:

I don’t think that is the case, but I’ve never been able to fix the crash so I am really only guessing. The Adobe PDF printer driver has a “curve smoothing” feature that is on by default and I think that the dense polylines that Rhino can send to the printer driver can cause problems.

I’m pretty inclined to just remove other PDF drivers from the list of available printers. I don’t see any advantage in using an alternate printer driver and those printers don’t benefit from the V6 feature where cubic beziers are generated instead of dense polylines. I would be happy to look at the file that you can repeat crashes with, but if it is anything like my previous attempts over the years I won’t be able to repeat the problem.

Unfortunately at this late stage in the development process, just removing printer drivers from the available list will most likely cause some other unexpected problems. Maybe it is best to just best to do something like rename the Rhino PDF printer from “PDF” to “PDF for Rhino (recommended)”. @brian, do you have any idea on what would be a good action to take?

1 Like

Hmmm. Is it too hard to add an advanced setting that, by default, hides the Adobe PDF printer? Then, if users really need it we can direct them to Tools->Options->Advanced and have them search for EnableAdobePDF and set it to True?

This is not very hard. I would probably just have a setting that hides all PDF printers except the one that ships with Rhino.

1 Like

Logged as RH-42921.

1 Like

(I call the new PDF-printer “Save-PDF” since it is only named PDF and has a save icon instead of a printer icon)

Ok, I now have some reasons:

  1. I can not choose “save PDF” as a printer for my layout:

    (edit. the pulldown dialg closes each time i screengrab, but the save-pdf option is not there :D)

2 FILE SIZE is crazy with your “save-PDF” printer.
image

3 text size is not the same. On your printer it is a tad smaller. (Not crazy-important for documents, but WAY too much if this was to be printed to say lazer-cutting for some production part)

So you still don’t want the crash-file to bugtrack?

Cheers

Looks like I have some bugs to fix to get rid of these “reasons” :slight_smile:

Reported and will try to fix this week
https://mcneel.myjetbrains.com/youtrack/issue/RH-42955

Reported and will try to fix this week
https://mcneel.myjetbrains.com/youtrack/issue/RH-42956

psst… text size has never been exactly the same between what you see on the screen and vector output. Do you use PDF for laser cutting a production part?

I will take a look if you send me the file.

Thanks for reporting these issues. I’ll try to get them fixed before the next Tuesday beta.

1 Like

You should never be surprised with what people use for production… :smiley:
(Oh, and with “production” I mean everything from cardboard models production graphics to lazer cut metal parts)
So and Arial “A” that is 90mm high should be just that :slight_smile:

PDF is a well used format by graphicdesigners and even though one never should (past tense) send files with text (always outline them) that is not the case so much more, as long as you use well known fonts. So users (me included) are not used to double check stuff like this that much any more.

And many lazer cutters are happy with both illustrator and pdf files.

I’ll send the file tomorrow!

I understand and agree with your comments. Was just pointing out that the text has never precisely matched between what you see on the screen and any vector output through printing. This is an ongoing project to try and match with as much precision as possible.

Hi Steve,
Not sure if this makes sense or not, but while you are at it, could you add SVG to the printing - both as setting it as printer on a layout and as a choice when printing. I see that a SaveAs from a layout does that but…

How does this make things better than using SaveAs SVG?

If anything, it makes it more consistent. Why bother adding printing to PDF when SaveAs PDF works just the same…

1 Like

I’ll keep it in mind. This would actually be a rather significant sized project just due to the design of the print dialog. We are rewriting much of the print dialog UI in order to support Mac in the future and this may be much easier to add once the UI rewrite is complete.

2 Likes

RH-42921 and RH-42955 are fixed in the latest BETA