0.1 points will be 0.035mm - that’s pretty fine, I haven’t tested but I wonder if the PDF format has a lower limit for line width sizes given that its original purpose was for printed documents.
The laser I used to work with (Epilog) would switch from vector to raster at line width values above 0.17mm or 0.5 points. I used to assign line widths of 0.01mm to vector curves to sent to the cutter (directly from Rhino, not via PDF) and it worked fine.
My general experience with PDF vector documents is that the precision is horrible - I would never use them to directly fabricate anything accurate.
I tried my own test here with Rhino PDF and Adobe PDF (very old Acrobat though) and the results were both very bad, the RhinoPDF being somewhat worse. The line width sizes are inaccurate relative to the original and seem to increase in specific steps. I have no idea if this is a characteristic of the PDF format itself, the PDF print (export) functions in Rhino, or the import function or all of the above…
The Rhino V7 file below has 24 squares with line widths from 0.01 to 0.24. The Rhino PDF starts at 0.042333 and has the same value all the way up to the square with 0.06, then it jumps to 0.084667 (i.e. the double) for the next 4 up to 0.10, then goes to 0.127, etc.
The Adobe PDF starts somewhat finer at 0.0211667 but exhibits the same “steppiness”, just that the steps are about half the size of those made by Rhino PDF. Therefore there is something being done by Rhino PDF that is different than Adobe PDF and that is not caused by the file format.
thanks for having a look at it.
I can easily create a pdf with Affinity Designer with a line width 0.01 pt.
And as far as i remember also Adobe Illustrator can do it - no longer use it.
Your testfile on a Mac - Export Rhino Pdf - all curves get 0.7 pt width.
(same what I experienced with my initial file - everything below 0.24 mm / 0.7 pt is rounded up)
and thank you for both of you @JimCarruthers
thanks for pointing out the accuracy issue - i am aware of it and totally agree on your concerns regarding it.
But as i teach on 3 different schools - and use another machine in a public fablab, and all the sales-man of Epilog and Trotec tell that a machine is the same as printing … i gave up fighting for a better interface on both sides - the service side and the system administrators on side of the schools.
to be precise, exporting a dxf / and or convert to polyline / arcs is a simple way.
the older / and some latest machines do not interpolate / jerk (german: überschleifen) nicely with polylines - or in general.
for example the controller of trotec SP 500 does not do a nice job regarding this.
Sending HPGL via Serial seams to give best results. But then you don t want to stand in-front of the machine with 20 students ;-( and explain the different workflows.
but back to the main topic.
looks like @pascal rhino pdf does not handle small line widths correct.
a bug (?)
OK, so the problem is not with the PDF format… some work for McNeel then…
Well, for many years we ran our Epilogs exclusively out of Rhino with the Epilog printer driver - no intermediate PDF involved. It works very well. I have a colleague that has a Trotec and they do the same - it is possible that they have to go through Trotec’s intermediate Job Manager to send it to the laser instead of directly as we did with the Epilogs.
We used Rhino as the importing software and specified that the students had to bring in DXF’s as a standard format for their laser work. The DXF’s came from anything from AutoCAD to Vectorworks to ArchiCAD to Rhino.
Yes, in this case it doesn’t matter much, you are not doing precision machining and the accuracy of the PDF is probably much better than the actual laser-cut part can be.