That would be one way to interpret the request😀 I would like to better understand what the problem is and what a proposed solution is.
Hi,
Sorry for the bad questioning.
Today we print a drawing to a PDF. Afterwards we open it up in Adobe and add interactive fields for production to fill in. I think it’s called “PDF forms” in adobe. we use it for FAI (first protocol inspections) there production control meassuering the product and report it in PDF systems.
Hope this helps, thanks in advance!
I doubt we will directly add this feature. That said, we added SDK access so the PDFs can be created from .NET plug-ins or python scripts. Upon creating the PDFs, you can add whatever you want to it by using the libraries that we provide.
1 Like
That sound good enough.
If possible someone will for sure add a script for this later on =)
Thanks Steve for the effort!
I have the same issue. Mo matter what I do it will comes out as lines/wired. Is this isue already solved?
I can repeat this bug and have logged it as something to fix
https://mcneel.myjetbrains.com/youtrack/issue/RH-40377
RH-40377 is fixed in the latest WIP
I noticed that the dimension arrow is still not visible when using Rhino’s built-in save to pdf functionality. Apologies if this has already been reported as a bug. And if it has, please could someone explain the procedure for checking whether a specific bug has been reported.
Thank you
I am not at mc neel
Write at @stevebaer
I’ve checked this now in the current WIP and can repeat that.
Not as far as I can tell. I’ve now created bug report RH-41392.
You could search on YouTrack for open issues with e.g. the keyword PDF:
https://mcneel.myjetbrains.com/youtrack/issues/RH?q=pdf%20State:%20Open
1 Like
I have the same problem:
This is pretty annoying and I can’t use it like this. Instead I use the old/standard export method.
Sadly the pictures (detail with rendered display mode) get tiled up and aren’t stitched together correctly in the final PDF. Nice to see that the new “True PDF Export” option doesn’t have this problem.
Another little thing I noticed is that if you have a detail which has display mode set to “rendered” the whole layout view will lighten up. This is connected to the gamma value in the rendering-tab. The value is set to 2.2 by default. If you set it to 1 the layout page will show correctly again. This affects only the viewport, I think the final PDF is not affected, not quite sure.
Btw, why is the gamma set so damn high by default?!
and now a wish:
the new “true pdf export” doesn’t provide any kind of feedback while exporting. the standard methods show a window with a progress bar. some kind of feedback is necessary because when exporting files with a lot of pages it may not be obvious for some users that rhino hasn’t crashed but is instead working.
another bug when exporting to PDF:
before exporting, sometimes I have to cycle (ctrl+tab) through all the layout tabs, otherwise there is content missing in the final PDF.
and:
at the moment I’m not able to use the new “true pdf export” anyway cause it completely crashes rhino all the time.
Do you have a sample where this crash happens?
Sorry, can’t give u the file. I did send in the error reports.
But after a reboot the crashes were gone, so I can’t reproduce it.
So what about the bugs I mentioned - any chance they’re going to be fixed any time soon?
And also the “true pdf export” doesn’t export the arrow-heads of the dimensions. [EDIT: sometimes]
RH-41392 is fixed in the latest WIP
@stevebaer thanks, nice to see your’re working on it. Still no word regarding the other bugs?
I hope these will be fixed next:
- Messed up text. Ouput in various different font sizes.
- After opening a file, printing layouts to pdf results in blank pages (empty details). Only works if you cycle through all layout pages (old and new export method affected).
- Dimension values stick on the dimension line. There should be space between them.
Getting the text output right is probably the most important thing to fix. I can’t imagine any pdf document that does not make use of text in some way. As soon as you got that fixed, more users can actually start using the new method, which should result in more feedback and bug reports.
This should be fixed in the build released later today
I am currently working on this issue
https://mcneel.myjetbrains.com/youtrack/issue/RH-42397
It won’t be fixed in this week’s release, but probably next week.
Edit: The latest PDF printer seems improved over the previous builds. I’ll test it some more!
It still makes 10x bigger files though.
1 Like
Ok, one issue is that it doesn’t give an error if it CAN NOT print the file.
(And it also doesn’t automatically open the output for inspection, personally I miss that)
Typical scenario:
I print a file and open it in Acrobat to review it, forget to close the file, and then do some adjustments in Rhino and print the file again and choose to overwriting the old file. And I belive everything is OK since Rhino doesn’t throw an error telling me that the original file is locked, so I put it in a mail and send it off to the customer.
2 Likes