However almost every “circle” you can see in printed media (and most purely digital ones) are not, in fact, circles. Why is this?
Since roughly the mid 80s all “high quality” print jobs have been done either in PostScript or, nowadays almost exclusively, in PDF. They use the same basic drawing model, which does not have a primitive for circles (or circle arcs). The only primitives they have are straight line segments, rectangles and Bézier curves. None of these can be used to express a circle accurately. You can only do an approximation of a circle but it is always slightly eccentric. The only way to create a proper circle is to have a raster image like the one above.
Shouldn’t be that big of a deal, right? I’m sure nobody is using PDF for anything that would require the kind of precision needed for a perfect circle, like CAD drawings for laser cutters and similar machinery. Right?
Again one might ask whether this has any practical impact. For this case, again, probably not. But did you know that one of the cases PDF is being considered (and, based on Internet rumors, is already being used) is as an interchange format for CAD drawings? Now it suddenly starts mattering. If you have any component where getting a really accurate circle shape is vital (like pistons and their holes), suddenly all your components are slightly misshaped. Which would not be fun.
This is why we can’t have nice things.
That’s actually right, no one uses PDF for high precision specifications that will be manufactured. CNC, laser cutters and the like all use GCODE, which has an arc primitive.
Many CAD tools dont’ even bother to generate arcs in GCODE though… for example pretty much no 3d printer slicer software generates arcs that I am aware of (you can use a post processor to do so though).
Also my PCB cad doesn’t use arcs in gcode (KiCAD) the latest version might not sure … but I know prior versions did not and used line segment approximations for everything.
That specific model mentioned in the article is primarily a laser engraver. It accepts Corel DRAW! files, Adobe Illustrator, Autocad, SVG, and many others, including PDF and BMP files. You probably wouldn’t be using it for high-precision manufacturing.
That’s the understatement of the century. We occasionally need CAD drawings of some of our products sent to us by the former manufacturer so we can make our own (we are licensed by them to do so and we can request any IP that’s covered by our license), and they would always send a rasterized PDF with chonky lines and indecipherable text. Once we finally got them to understand we needed the PLT files we were able to properly convert use them in our equipment.
PDF serves many great purposes but CAD is not and will never be one of them.
For many things, the fake fine segmented circle is better than the device’s capabilities. YMMV of course.
Isn’t “arc” is a built in function of the basic postscript language taking the following arguments, for a circle I think closepath option is required should you wish to set a fill for an object.
centerx, centery, radius, startangle, endangle arc closepath
There are many versions of PDF, from bare bones to full blown scientific grade technical standards, so I’m not sure what to make of the article.
Also, most raster images generated from vectors come out of a RIP that starts off with an intermediate postscript or EPS artwork before generating 1-Bit TIF or similar.
Since you used the term RIP, I will leave my comment here.
The real danger in using something like PDF as an interchange format in a professional setting is that there are so many systems and applications that can generate PDF with output varying wildly in quality and content. If you can accept PDF, people are going to send you all kinds of crazy PDF documents and what your CNC machine, extrusion line, or 3D printer do with that PDF may not be what you want.
To use PDF for CAD will likely require specifying a subset or specific application of the PDF standard that ensures easier interchange between systems operating on CAD data. This had to be done in the printing and pre-press industries for example with the PDF/X standards. It is not that the PDF format itself was too limited ( actually kind of the opposite ). PDF/X standards generate “normal” PDF files. Simply, the standards describe what you MUST NOT do and what you MUST do in your PDF file to be PDF/X compliant.
https://www.prepressure.com/pdf/basics/pdfx-4
IMO, a solution exists, at least from the mathematical standpoint. Take a look at the paper below (1990).
The problem with PostScript reminds me the problem with X protocol – virtually no one understands it
while there is too much legacy.
https://www.sciencedirect.com/science/article/abs/pii/016783969090019N
We provide a surprisingly simple cubic Bézier curve which gives a very accurate approximation to a segment of a circle. Joining the Bézier segments we obtain an approximation to the circle with continuous tangent and curvature. For 45° segments the error is approximately 2·10-6, and in general the approximation is sixth order accurate.
Rational Bézier curves are capable to precisely represent all conics (including circles and ellipses.)
“Again one might ask whether this has any practical impact. For this case, again, probably not. But did you know that one of the cases PDF is being considered (and, based on Internet rumors, is already being used) is as an interchange format for CAD drawings? Now it suddenly starts mattering. If you have any component where getting a really accurate circle shape is vital (like pistons and their holes), suddenly all your components are slightly misshaped. Which would not be fun.”
Just to be clear:
Drawings in engineering can be done as freehand sketch.
The actual shape is communicated through the dimensioning.
2D contours are exchanged as DXF, 3D shapes as STEP or IGES.
Fun fact: STEP is the biggest undertaking that the ISO ever tackled.
I have never really gotten deep with PDF but I used PostScript pretty extensively in a past life and I thought these things were the same between them.
In PostScript, you can describe a shape mathematically. For example, a circle in the middle of the page would be described by x squared plus y squared equaling the square of the radius of the circle required ( where x and y represent the distance from center along the horizontal and vertical axis ). This formula generates a perfect circle to within the capabilities of the hardware it is being imaged on. On a computer, the “final” image output will obviously be a raster image where every pixel has a coordinate which means ( depending on resolution ) the circle may look “jagged” but it will still be perfectly proportionate ( circular ) and not “oblong” as the article states. If the final form is more analog ( describing where ink will appear on a printing press for example ), this jaggedness is likely to smooth out and the shape rendered will look very circular indeed even at high magnification.
Perhaps PDF works differently but what the author in this article is saying sounds wrong to me. In fact, it sounds more likely that he is talking about something inherent in the PDF output generated by some kind of tool he is using to create his PDFs. If the software you are using to ask for a circle does not understand circles, then what it asks the PDF to generate may in fact be a combination of bezier curves that do not represent a true circle. That would be a limitation of the source software though and not PDF as a format. Again, this speculation is based on what I know about PostScript and assuming that it applies to PDF as well.
There is a real difference with things like PDF and PostScript between what gets generated by different programs. One of the reason that Macs dominated in pre-press and desktop publishing was that the PostScript generated by Macs was of substantially higher quality than the PostScript generated by the driver in Microsoft Windows. If you were going to use Windows in a professional PostScript workflow, you generally installed a PostScript driver from Adobe. Things are much the same in the PDF world and we have all experienced the differences in PDF output between programs ( for one thing, I am sure we have all seen PDFs that are 10 times the size as one that it is visually identical to – on a computer screen at least ). PDF was designed to address some of the problems that PostScript had as document exchange format but, at its heart, the two are fairly similar.
If I am correct, PDF could in fact be a high enough quality format for interchange of things like CAD drawings. That may still be a bad idea of course. For example, it feels like problems like missing or misinterpreting something that leads to incorrect absolute scale would be easy with PDF. However, I doubt that the reason that PDF would be unsuitable is because it cannot represent circles correctly. The burden would be on the CAD software representing circles, or whatever else is required, correctly in the PDF to begin with. It would not surprise me at all though if this required the PDF generation in CAD software to be more advanced in some ways than the PDF generation in the Microsoft Windows printing subsystem or applications meant more for artistic expression. Again though, that is not a limitation in the format itself.
@tanishaj
Of course we can’t know what if implied, but it’s always been the case in prepress that the file acceptance is qualified by the operations software, and that is the purpose of preflight and other equivalent checks/functions. Of course in professional prepress and print you have contract proofs, that otherwise qualify omissions and errors. It stops clients from complaining that the file they sent with 84 spot colours doesn’t match the CMYK! So I don’t see it as a big deal for CAD operators to have to parse PDF thoroughly before accepting it but it won’t solve problems as you correctly point out.
As for bitmaps being round, well it all depends on scale you observe it at, and we know in print all circle bitmaps are built on the same grid used for halftone screening / vignettes, which determines how a whole image / page is rendered, all are cartesian in nature, I don’t know of any vignette / screening algorithms that use polar coordinate systems, maybe they exist in security printing.
As for rendering circles, the article seems to be missing the point on the concept of tolerances completely. For my day to day I manage a department that renders 3D structures using laser at resolutions down to 1um, we don’t use polar coordinates and the basic system or coordinates is cartesian. Yet even rendering at 1 micron resolution we regularly have end users telling us we got the size or spacing wrong by 500 microns or more, only to later find that they have no concept of what is constraint based modelling and they had laid out various components by eye rather than using numerical arrays or patterns.