The way the PDF exporter is designed, you could write a display conduit to do just this very thing if you get sick of waiting around for me to add the feature😄
Hi Steve, solids are playing up on V5 generated file (Layout and MSpace), the PDF from layout looks good when solid hatching is turned off.
Can you send me a sample file that exhibits this bug?
I’ll send it through to Tech
1 Like
Hi Steve
Attached an example of some very large thicknesses of lines with True PDF Export
Ciao Vittorio
Test_Print_Pdf_Wip.pdf (84.7 KB)
Test_Print_Pdf_Wip.3dm (3.8 MB)
Let me turn that around and ask you how you export to WMF.
I have a simple illustration that I need to get into a Word document:
I select all and call Export. The WMF Export Options box comes up like this:
Side note: I’ve asked for this several time before but perhaps in RH6 the units in the Destination and Margins settings won’t default to inches no matter what? Inches make no sense, yet I have to change this every - single - time.
On with the export.
Destination width and height. I really don’t know. Something like 150 mm to 300 mm in width sounds good so I type 200 mm in width. That leaves me with 200 by 1700 mm.
Hmmm… Are you now expecting me to change the height value a bit and see what happens? Sure, I can do that a few times and will end up where I need. I have found that a faster way is to create the bounding box and get the dimensions. But is that really necessary?
Also, as you can see from the first picture (and also the second), the illustration is not necessarily centered (or even present at all) on the canvas that is being exported. So reducing the height to something that looks to fit is hard at this point.
In the View and Output Scale settings I can position the canvas around the illustration using one of the 3 options. I use the Set - Window option to draw the area that I want to export. This is the ideal tool to determine what is to be exported. The only problem is, that it doesn’t allow me to do anything with the white space above and below.
To me it would make more sense if the order of things were changed:
- You set the view. Viewport and Extents will use the viewport ratio, using a window to set the canvas always the user to change the ratio.
- The scale defaults to 1:1 and this automatically sets the Destination Width & Height. If these get too small in relation to where the output is going to be used, the user can easily change the scale an order of magnitude.
By the way, as reported before, I still have to turn to RH5 to actually export WMF because the WMF format that RH6 produces doesn’t get into Word / PowerPoint.
Hi Vittorio,
This looks correct (I actually think it looks really nice 
). Your “SceneSilhouetteCurves” Layer has a print width of 0.5. The PDF exporter uses the print width for objects/layers to calculate the resulting width. You can adjust how the widths are interpreted in the “Linetypes and Line Widths” section of the PDF export dialog.
First of all, thanks for taking the time to write down all of these comments.
I can see your point with WMF since WMF is typically a somewhat “unit-less” format where it is usually placed in another document for illustrative purposes (Word, Excel, …). In this case, a redesign of the WMF export dialog may be the best solution. Of course, I’m being lazy and trying to reuse as much as possible which is why the WMF export dialog looks just like the print dialog which happens to look just like the PDF export dialog… For WMF, it may be best to just ask for a window area or bounding box and then I can make up all of the other internally needed values.
Yep, it’s been on my list for quite a while. I haven’t focused much on the printing system during V6 development until now (I’ve had my head buried in display rewrite for a long time.)
https://mcneel.myjetbrains.com/youtrack/issue/RH-3300
I’m still not convinced that your WMF workflow would be the best for PDF. It seems like the WMF dialog could definitely be simplified with respect to just selecting a print area and I can make up a true width/height combination that works. PDF seems like it needs to have a drop-down with a large set of pre-canned paper sizes as well as a custom size that you can just set since PDF really is targeted at creating pages of given sizes.
https://mcneel.myjetbrains.com/youtrack/issue/RH-30081
I moved this back to my 6.0 list. Somehow this slipped by me and I didn’t realize it was a regression.
Thanks, Steve, for looking into this!
I agree with you up to a point.
Yes, in 99.9% of the cases, printing to PDF will be to (one of a long list of) known paper sizes with fixed ratios.
As such, WMF might be special.
But consider the odd case where one wants to produce a PDF that either won’t be for print or printed on a perhaps a 36" plotter (I’ve tracked organizational changes at our company for 10+ years and those charts are probably best viewed on screen…).
The same goes for printing to an image file, by the way. (Does anybody actually use that interface to get a PNG out of Rhino??)
In those cases, the user will have a general idea (or very much fixed like in the 36" plotter case) about only ONE of the two dimensions (width and height). With the system that is currently in place, the user either has to resort to some form of trial and error to get to the missing dimension or get dimensions from the model.
So perhaps apart from the pre-canned paper sizes, the custom size could use a system whereby the user draws a rectangle in the model and that rectangle sets the ratio of the output size?
My hope is that the SDK becomes rich enough in this area that ‘unusual’ cases can be dealt with through relatively simple scripts. I’ll keep this case that you are describing in mind while putting the SDK together. It is also a nice way to prototype functionality that can later be integrated into the user interface.
1 Like
Thanks Steve!
Oh, and another wish for PDF export: to be able to append to an existing file. So when an existing name is given, the user is asked to either overwrite or append.
1 Like
(Does anybody actually use that interface to get a PNG out of Rhino??)
I do!
Interesting.
What are the advantages over using -ViewCaptureToFile or rendering to an image file?
And how do you deal with the aspect ratio of the window?
This is a lot like the HP printer drivers work with Office applications - it’s basically a great system. As far as custom papers go, the HP system is sloppy. If you do it, please put your normal high usability standards and programming effort into making the creation of custom paper sizes effortless for the user and easy to add to the drop-down. Maybe remove, too.
Hi Steve,
FWIW
I’m chiming in from a scripters perspective to give some feedback on the type of API functionality I’d likely use.
For exporting layouts to pdf, I imagine passing the layout object would suffice to generate the PDF. So without the need to e.g. specify pagesize as that is already set in the layout and assuming defaults like dpi and various scalings.
However defaults could be overwritten (line thicknesses handling of dots etc etc) and set in the pdf writing object beforehand.
So I’d setup a pdf writing object with customized settings and then pass an array of layouts views to export as pdf.
As for non layout prints I’d need a way to specify the viewpoint to export and pass that to a pdf writing object.
I imaging being able to pass rhino viewport objects to define both perspective and parallel projected views and allow also for 3D planar rectangles to be passed that assume parallel projections through the rectangle with righthand rule normal. These would export geometry only (no shading) much like the current .AI exporter as opposed to with viewport objects where it’s displaymode is leading for the type of export (bitmap or lines/hatches etc)
Size/scale for the exports would by default be realworld but can be overwritten again in de pdf writing object to be a fixed “paper size” and/or scale. To mimic a physical printer than can “scale to fit”.
So much for my initial thoughts on this.
Thanks
-Willem
Here is how you would export every layout page to a PDF in python
import Rhino
import scriptcontext as sc
import rhinoscriptsyntax as rs
filename = rs.SaveFileName()
pages = sc.doc.Views.GetPageViews()
pdf = Rhino.FileIO.FilePdf.Create()
dpi = 300
for page in pages:
capture = Rhino.Display.ViewCaptureSettings(page, dpi)
pdf.AddPage(capture)
pdf.Write(filename)
Does that work for you?
The ViewCaptureSettings class is the key here. This is where all of the adjustments will be set for producing a page of output. This same class will be used for the upcoming SVG exporter too.
3 Likes
Hi Steve
That looks straightforward indeed. Im on my phone so I’ll have to check the ViewCaptureSettings class later. Thanks for the swift reply.
-Willem
The ViewCaptureSettings class will get a bunch of properties and functions over time. Right now it is still pretty simple
1 Like
It makes sense that the credits runs out after 20 years of use…