I was curious, so I looked up arc in the PostScript Language Reference [1]. It contains the following (p. 530):
> The arc is represented internally by one or more cubic Bézier curves (see curveto) approximating the required shape. This is done with sufficient accuracy to produce a faithful rendition of the required arc. However, a program that reads the constructed path using pathforall will encounter curveto segments where arcs were specified originally.
> The arc is represented internally by one or more cubic Bézier curves…
But that's a rendering implementation detail, no? Isn't the precision and accuracy of any digital or physical manifestation of a circle limited by implementation details and physics?
Yes, but as the article notes, there are applications where you need a circle way more precise than one approximated by just a few Bezier curves. Although you could argue that any finite precision can be achieved by simply using more Bezier curves.
"The only primitives they have are straight line segments, rectangles and Bézier curves. The only way to create a proper circle is to have a raster image like the one above."
Is this really an accurate conclusion? Just because there are no primitives for a circle – postscript is still a programming language so you can also plot a proper circle with trigonometry?
Yes, but as someone else commented the arc is internally based on bézier curves. How accurate thee circle would be by plotting is probably dependent on the trigonometric table built in to the postscript interpreter, but at least it would be mathematically possible to make an accurate circle where it's actually not even possible to express a perfect circle with bézier curves.
In theory you could, when you were converting from PS to G-Code NOT emulate the arc with bezier curves, but convert them into g-code circles. This would likely cause the laser cutter to cut something that looked SLIGHTLY different than the rendered PDF. But anyone who's worked in the field long enough knows that WYSIWYG is a lie (albeit a very useful lie.)
Don't get me wrong. I'm not questioning the usefulness of béziers. I'm questioning the authors notion that postscript inherently is incapable of expressing accurate circles just because the language don't have built in primitives for them. :)
That appears to be a rendering/conversion artifact since PDF also supports 360° arcs. My question is, mathematically, is a 360° arc not a circle? (I understand that once a circle is rendered or physically manifested, it's an approximation.)
Do have a reference for PDF supporting circular arcs? I'm looking at the PDF reference manual and do not see it under list of path construction operators.
> Do have a reference for PDF supporting circular arcs?
No, I could've sworn PDFs supported arcs but I was wrong. :) So when rendering/converting PostScript to PDF, circles/360° arcs must be converted to béziers.
Also, I'd wager that you could get something closer to a circle with a naive bezier implementation than with a naive raster implementation, as long as you were willing to spend as much resources on storing curve nodes as you would on raster data. I mean, it's not like a rastered circle would make a good wheel either considering that technically every line on it is orthogonal.
I was under the impression that the postscript in a pdf isn't a programming language. It is pre-executed so that only drawing primitives remain. But I could be wrong.
Lathes do circles all the time. But it would be difficult to rotate either the head or the bed around an arbitrary axis in order to print a proper circle.
I don't know what you were trying to imply and I have no dog in this fight. But there are definitely fundamental differences between additive vs subtractive technologies, 2-axis vs 3-axis or multi-axis machining, and more niche machine-controlled manufacturing technologies, as well as very real differences behind the driving algorithms of most 3d printers/CNC machines vs most commercial laser cutters. (3d printers and other CNC tools have a pedigree stretching back to the original g-code developed in the 50s whereas laser cutters/engravers descend from more modern laser and inkjet printing technologies developed in the late 70s and 80s.)
CNC and 3d printing typically use G-code, which has dedicated arc commands (G2, G3), and the laser cutter in the article uses PDF, which (apparently) does not, and is the main point of the article.
Of course any physical machine is only making an approximation of a circle (even a lathe doesn't turn perfectly round, there is no such thing), but at least for CNC and 3d printing you can specify a perfect circle. In PDF you can't.
(Yes, it is also true that a typical 3d print comes from an STL file, which can only specify triangles, so STL files also can only specify approximations of circles. But it is still true that most 3d printers run G-code, not PDF.)
The PDF format was intended to be an explicit per page device independant description of text, line path, and image layout subject to clipping with no "program running" elements to it.
It followed PostScript which was a programming language that was intended to be directly undertood and runnable by Postscript enabled printers.
Postscript could easily do the job here, it had "arc" drawing primitives that described circles (both full and partial).
The 'failure' of Postscript was that as a programming languge a bad .ps job could crash a printer and a 1,500 page .ps document had to be internally fully rendered just to print out page 73 only (potentially code on any 'page' could loop back or forward and generate image elements on any page).
As a not-quite PostScript simplified 'other' the PDF formal languaage spec only allows the drawing of lines and 'curves' and curves are explicitly 3rd order bezier splines.
See: Path Operators (Page 95)
Portable Document Format Reference Manual (230 pages)
> This is a laser cutter that takes its "print jobs" as a PDF file and uses its vector drawing commands to drive the cutting head. This means that it is impossible to use it to print a wheel. You'd need to attach the output to a lathe and sand it down to be round so it actually functions as a wheel rather than as a vibration source.
Respectfully, I don't think you're limited by the PDF format if you're talking about a laser cutter. And... Circular motion doesn't spring forth naturally from gantry CNC laser cutters -- they're rectilinear in design. It's circles not existing all the way down.
Using it as a CAD format with inherent fundamental shapes missing seems kind of funny, though.
Epilog claims (up to) 1200dpi resolution. Another comment mentioned the "standard bezier curve representation" is accurate to 0.03%. This means errors should start being observable with a circle as small as 3in. These are probably wildly optimistic assumptions, but it's still 10x smaller than the bed of their largest unit, and there's nothing to stop people from creating arcs of circles with radii even bigger than that!
Observable is pushing it. Technically observable, sure, but ~1dpi misplaced is… unlikely to be noticeable.
Plus, if that level of accuracy is required simply adding more nodes improves accuracy exponentially.
Not least, the “standard” approximation really should be updated in software, as modern 4-node approximations are down to 0.005%, almost an order of magnitude better.
Oh, I completely agree! "Observable" is pushing the limits of the word past absurdity. 1200dpi would put the resolution of the system at just twice the wavelength of their laser. I feel like that's about the limit of what's possible due to physics [citation needed]. I'm fairly confident their actual performance is less.
Last time I used one, Epilog’s software was pretty terrible. It seemed to designed around a workflow in which you either design your cuts in CorelDraw and then print to a Windows print driver.
I sincerely hope that the upcoming Windows third-party print driver deprecation kills this.
(Also, what’s wrong with them? Even ignoring cost, I would rather have a Chinese printer that had a publicly known control interface and supported Lightburn than a “nice” American laser printer that was only operable with bad proprietary software.)
The 1200DPI resolution is for engraving using rasterization, so, not really the same thing.
When you're cutting things on a laser, there's myriad sources of error. Odds are the optical path isn't completely square, so there's some cross coupling between axes. There's drive belts. The laser is often pulsed. There's taper.
The shape is there. postscript(and I assume PDF) has an arc primitive. however it is rasterized(drawn) in the reference implementation using bezier curves.
Now the postscript to servo control program(g-code?) interpreter might use the same bezier curve approximation, but it might not. I think if it were a formal complaint they would have to positively assert that their machined circles are following an inferior profile rather than just assume they are.
g-code sort of sucks as a language. It is very primitive. I always thought it would be cool to have a postscript dialect that supported more than two axis to use as a low level language on computer driven machine tools.
PDF for CAD is silly. The problem is that laser cutters tend to take 2D vector image data as input, rather than G-Code like real CNC machines. You can definitely express a circular path in G-Code, and you expect a milling machine to cut one accurate to the precision of the mechanical parts of the machine. But laser cutter software is to some extent derived from printer technology. You can raster scan a picture onto a surface with a laser cutter.
Agreed. PDF for CAD has its place, but its place is shop drawings read by humans, not as a machine interchange format. Many laser cutters will accept other vector formats, like DXF, which do have precise representation for circles.
DXF seems to be reasonably common for laser cutters. It at least supports arcs!
I don't think many laser cutters use raster scanning, though. That's going to leave some really nasty artifacts. You really want to cut continuous lines like, well, lines.
I think the OP's concern was that they couldn't upload G-Code, they could only upload PDFs. And because PDFs don't encode circles, a mechanistic translation to G-Code can't convert it into a G-Code circle, only a curve that emulates a circle.
So... you know... note to self... when designing a laser cutter, allow the user to upload G-Code.
This is true for almost every machine tool I've ever used (CNC mills, 3d printers, CNC plasma cutting, & water jet), but every laser cutter I've ever used (and I've used the kind that runs on 3-phase power and has no safety enclosure) speaks some variant of PCL. The one exception being a $300 home-brew tabletop laser running the aforementioned LaserGrbl...
That said, apart from a handful of misconfigurations, I've never had a problem getting any of them to cut out nice circles.
> The only way to create a proper circle is to have a raster image like the one above.
facepalm. A raster image can't express a circle either - it's also just an approximation.
Same thing with a printout, for that matter. Maybe you could claim some kind of radial plotter is a true circle, but even there we're talking about pigment being absorbed along individual paper fibers.
In reality, all the mathematical shapes are just abstractions to be approximated.
You completely missed his point. Pick a DPI, make a raster circle - it's accurate to the DPI you pick. Now use a Bezier to make that circle (and rasterize it to that DPI). It's not accurate to that DPI.
I don't see the conceptual difference between approximating a circle as a set of raster points, and approximating a circle as a Bezier curve. Also, it was the author's choice to frame the article in edgy universal terms "Circles do not exist" rather than something like a more pedestrian "Circles don't exist in PDF".
Neither rectangular pixels nor Bezier curves are bases capable of perfectly/natively representing a circle. Either one can approximate a circle to within some arbitrarily chosen amount of error, based on increasing the number of pixels or the number of Bezier curve segments.
For a given circle and DPI, one can figure out the minimum number of Bezier curves necessary to represent the circle such that rendering those Bezier curves out to pixels will get you the exact same result as having rendered the circle in pixels directly.
But the mathematical inaccuracy is caused by the limitations of compressing an abstract concept on a finite field (of a different base abstraction). So no, it doesn't seem like your wacky analogy at all.
No, the Bézier inaccuracy has nothing to do with rasterization. Did you even read the article?
They're saying that your arc for your circle will be incorrect before it's ever put into a concrete implementation. In other words, there's a base level inaccuracy and then your rasterization brings a whole new, different inaccuracy into play.
So yes, my "wacky analogy" is exactly apropos here.
You seem to be asserting some categorical difference between Bezier curves and pixels, likely because most output devices work in terms of pixels. But they're actually both just drawing primitives, and neither one is capable of representing perfect circles.
> the Bézier inaccuracy has nothing to do with rasterization
Obviously, because rasterization refers to pixels and has nothing to do with Bezier curves. On the other hand, that inaccuracy has everything to do with Bezierization.
> there's a base level inaccuracy and then your rasterization brings a whole new, different inaccuracy into play.
Yes, stacking two inexact transformations will result in more inaccuracy than a single one.
Since you seem to be attached to your analogy - it's more like a person making the argument that humans can't fly unassisted, while showing a picture of a pig as an example of flying, and I'm pointing out that pigs can't fly either.
Time Cube's ineffable Truth.
'Cubeless Word' is not Truth.
Word justifies all human evil.
Time Cube is a test for Truth.
Circle measure is slop bucket.
Drawings for parts should have tolerances called out. I did mechanical inspection for a manufacturer for several summers. Every dimension had a plus/minus value listed. Holes and screw threads had go/no-go gauges
Using PDF as a standard (for anything) is insane. I mean it was nice before Adobe backpedaled and tried to milk it for everything and now the format is anything but portable.
if being off by 3 units on a 10,000 unit circle actually matters, you have stricter requirements than most industry bodies. If you're fabricating parts that have tolerances measured in 1/10th of a thou, the machines you use absolutely don't ask for PDF, they ingest proper control code.
It absolutely matters. The type of fit you get between a shaft and a hole differs on the order of 5 - 10 microns [1]. A micron is 0.01% of a cm so 0.03% can consume a large portion of your tolerance budget.
For example, you can make a shaft that fits in a hole like a spring because it can slide freely but air can't get out and you can shave a few microns off and it will sink into the hole at a controlled rate. This is all easily achievable in a home machine shop on a manual lathe. With Wire EDM, you can achieve even tighter tolerances and it would be perfectly possible to generate a part that could fit but could not spin because of the PDF error.
It doesn't matter. The error is 0.03% only with one of the most simplistic approximations of 1 Bézier curve per quarter circle. Bump this to 2 or 4 curves, and the error drops to 4.0e-6 or 6.2e-8 (https://pomax.github.io/bezierinfo/#circles_cubic)
You are going to have a really hard time finding an industrial application where a 6.2e-8 error matters.
In fact, check this out: the Epilog Fusion M2 40 laser machine that the author chooses to picture as the problem instance can engrave a circle of at most 28-inch diameter, and has a resolution of 1200 dpi. Therefore two (gasp!) Bézier curves per quarter circle offers far more precision (4.0e-6) than this machine's error (1/1200/28 = 3.0e-5).
Edit: or take the world's roundest object: a sphere made out of a single crystal of silicon-28 atoms, with a roundness delta of less than 50 nanometres over a 93.6 mm diameter (https://www.heason.com/news-media/technical-blog-archive/wor...) This is an error of 5.3e-7. Four puny Bézier curves per quarter circle (6.2e-8) are more perfect than this sphere.
That's the answer to a different question. I was just pointing out that, in most industrial applications, 0.03% tolerances are rarely seen but in the specific question of circular dimensions, it's a pretty common requirement.
And while it's possible to approximate with higher bezier curves, PDFs are auto generated with software libraries and it's going to be non-trivial to dive into the guts of a library of a library of a library and tweak the logic for generating circles for this one specific type of application.
When we're talking about a CO2 laser, the errors from taper, variations in laser power, rigidity, trueness of optical path, etc, etc, far exceed 0.03%.
If you want a circle that's better than a 0.03% tolerance, odds are you're not making it by tracing a circular path in g-code, but instead using something like a lathe.
> And while it's possible to approximate with higher bezier curves, PDFs are auto generated with software libraries and it's going to be non-trivial to dive into the guts of a library of a library of a library and tweak the logic for generating circles for this one specific type of application.
A lot of work on CO2 lasers you do with something like Coreldraw or Inkscape. You absolutely can pick the number of vertices with some slight work.
Lasers are a bit weird in that most of their work is for signmaking. Most end-user use cases are closer to a printer than that of a typical CNC machine. Indeed, it can be annoying to take something from CAD to lasers that want PDF, because you can end up with things like the resultant PDF not joining lines together properly into one shape and the laser "stopping" on each vertex. You end up pretty carefully picking tools and processes for this flow. Ideally you figure out how to give the laser a dxf...
>For example, you can make a shaft that fits in a hole like a spring because it can slide freely but air can't get out and you can shave a few microns off and it will sink into the hole at a controlled rate. This is all easily achievable in a home machine shop on a manual lathe.
I can tell from this statement that you do not have a home machine shop with a manual lathe. Home machine shops most certainly do ~not~ typically (or easily) achieve micron accuracy.
In the category "using your hammer to screw in a rivet", you don't machine a shaft with a laser-cutter. As you point out: you use a lathe.
For "circular" work that you do use a laser cutter for, 0.03% tolerances are below the variance you get from the cutter itself. Expecting higher precision from the cutter that is somehow "messed up" by the deviation from the standard Bezier approximation of a circle, when the machine you're using can't give you that precision is using that proverbial hammer.
Of course, if that's really all you have access to (first of all: what are you even doing? look into buying a second hand lathe, or have everyone pitch in so your hobby space can buy one, they'll set you back less than a thousand bucks) the laser cutting is step one, you're not done after cutting, and you know you're not done after cutting because you know laser cutters are not high-precision machining tools like lathes or mills. You cut slightly oversized, and then you clean up the part and machine it down to final dimensions until your micrometer says you're within tolerance.
Or they could stick with binary and introduce a name for 1/1024th of an inch. Borrow a meme from the “almost SI” prefixes kibi, mebi, gibi etc., and call it a mibi, perhaps? ;-)
They are IEC prefixes, complementary to the SI prefixes, and they only are defined for positive exponents.
kibi : ki : 2^10
mebi : Mi : 2^20
gibi : Gi : 2^30
tebi : Ti : 2^40
...
Conveniently, these numbers are fairly close to 10^3, 10^6, 10^9, and 10^12 respectively (but with increasing error: 2^40 is almost 10% larger than 10^12, whereas 2^10 is only 2.4% larger than 10^3).
This leads to a lot of conflation, mess, and misreporting by vendors and OS authors. Windows is an egregious example. A 1 TB (terabyte, 10^12) disk is reported in Windows as 931.7 GB. It ought to be 931.7 GiB, which is what Linux does. macOS uses the correct number but SI prefixes, so 1 TB is reported as 1 TB.
Electronics manufacturing uses both with about equal frequency, often without unit names attached, and it's confusing as all hell, at least as a hobbyist. E.g. a 0603 footprint can mean 0.6×0.3 mm or 60×30 mils.
Because at the time of the invention and adoption of this term of this term in the late 1850s, the metric system didn’t have widespread adoption at all. The treaty of the meter wasn’t until 1875.
So the metric system and decimalization of the inch are roughly contemporaneous and “just use this othe, also brand new system” isn’t an obvious choice at that point.
I think the real question is... Why is such a unit still being used? I was under the impression that any serious ultra-precise CAD and machining was done in milli, micro, and nanometres. I thought pretty much any serious science or engineering had been metricated...
But then again I shouldn't be surprised; Americans measure the volume of lakes in 'acre-feet'...
I don't think you can represent arbitrary data in a pdf AND have pdf viewers actually render it. If the pdf format screws precision (and I'm not surprised it does, it screws paragraphs and often only contains metadata to reconstruct lines of text), it should not be used as a data interchange format.
Pdf is for print and human eyeballs. It's brilliant for those 2 things and not much else.
> I don't think you can represent arbitrary data in a pdf AND have pdf viewers actually render it.
You can have both in parallel, and have the editing software regenerate the rendered form from the source data form when anything changes. It’s not completely uncommon to use PDFs as a data carrier that way.
If I was dead set on using pdf as an interchange format, I'd make the standard that the pdf content was a drawing of the data and then also embed a better representation of the data. So a well formed file can be previewed with any pdf reader, but no problems with data quality when you go to use it for something.
Of course the drawing could then be out of step with the data, but so what.
If a Bézier-based circles with four nodes are too rough, I suppose a circle with 16 or 24 or 128 nodes can be made smooth enough to exceed the laser cutter's margin of error.
If you want to produce a highly regular circle in Inkscape, draw a polygon with many nodes (say, 24), convert it to path, then make all nodes smooth and symmetric.
Like floating point errors, the representation can (in theory) be as precise as we like but that's not something most users are willing/able to adjust.
The actual formula is O(n^6) scaling, and for circles it's very easy to achieve that. So a circle divided into 16ths has 4096 times less error than one in quarters and one made of 128 nodes is a (binary) billion times better.
This is true for curve fitting of arbitrary curves, not just circles, though arbitrary curve fitting is a bit tricky (it requires solving quartic equations). I personally think you can take this as evidence that cubic Béziers are "good enough" for all practical tasks requiring curve representation, though for specific applications there might be other representations that work better.
The article was about postscript, but the comment I was replying to was about how to approximate a circle in Inkscape, so I suggested a better approach.
The first "better" approximation, while having a better "max distance" (0.019608% vs 0.027253%), has a _worse_ span between min and max (0.039216% vs 0.027253%), which probably matters for some applications.
I thought his point was that the forms are memories of the divine because the material world does not provide such forms. You leave the cave when you stop being dominated by your senses and use your reason to apprehend universals.
But I don't think that is right. He argued that matter existed in a relation of participation in the forms, that making such things like shadows or approximations of ideas. Aristotle deployed the third man argument to attack this notion. Plato conceded his view was problematic.
Greek, yes (owning to their paganism, which had trouble dealing with existence; it is not possible to conceptualize existence), but we see very deep insights in the medieval period, most notably in Thomas Aquinas. In the 20th century, we saw a particular brand of Thomism called existential Thomism that emphasized and expounded on Thomas' understanding of existence to help better appreciate it.
But I am not certain that is your criticism, or that this applies here? Platonism posits a third realm of ideas, one which Aristotle denies and attacks (and which Plato acknowledged), instead locating universals in things and in the intellect that grasps them. However, you can restore a kind of realm of ideas by interpreting it as (the mind of) God. So, universals exist in all three cases, though the manner in which they exist varies (e.g., in things as concrete instantiations, vs. in the human intellect as concepts abstracted from the concrete).
That we can conceive of mathematical ideals like perfect circles that are never actually realized or encountered in the concrete, physical world (even if it is the case that they are possible in principle, in practice we arguably never encounter such things) suggests something very interesting about the nature of the human intellect.
And, in fact, even if they did exist physically, the very fact that the concept or predicate of Circularity exists in the intellect (and this concept must be Circularity as such or else we could not speak of circular things) and applies to many things despite their diversity, also suggests something about the intellect, namely, that it is not physical, as the physical is always concrete, instantiated, singular, this-and-not-that, not ideal.
If you play the game Quake 3 Arena, which was, I think, the first game to use bezier curves in 3d rendering, so that a column or arch could dynamically adjust how many polygons are used depending on view distance, the columns are visibly not round!
Not something most people notice unless they are looking for it.
And these days GPUs have programmable tessellation shaders so they can semi-automatically make up more geometry as needed.
I remember the Q3A Beziers were advertised as if the game rendered actual Beziers (which would in principle be possible in software but not on hardware… of the day, anyway), rather than just doing dynamic LoD approximation with your bog-standard triangles!
I could be completely incorrect here; but I don't know of a vector display that can do anything but arbitrary lines. Circles are usually rendered with sublinears to the command resolution (and trace runs) you're willing to sacrifice.
An oscillating display can do curves, but only in a wave/ linear sequential fashion.
You're probably right, but I don't think there's any fundamental obstacle to controlling a CRT electron beam to trace arbitrary curves – there's vertical control and horizontal control and you can arbitrarily modulate them over time, can't you?
I didn't say it wasn't theoretically possible, I said there are no (that I know of) concrete implementations of this idea.
Yes, this is theoretically possible. I imagine it wasn't done due to processing limitations during the time vector displays were common; but my limited knowledge in the realm doesn't give me certainty.
> Furthermore, the human vision system is a bit weird and perfect circles look vertically elongated. You have to make them non-circular for people to consider them properly circular.
Does any one have a link to a perfect circle, I'd love to see if it has the proposed effect on me.
How can I distinguish between errors of perception, errors in manufacturing, and errors of perception of the designer who eyeballed circles on a computer screen with non-square pixels?
With a coffee cup, you should be able to take a micrometer (or a piece of string) and verify roundness of the base object to whatever arbitrary precision your heart desires (and your reality will allow).
I don't think I've ever seen a coffee cup that would let me do that. As I said earlier, I don't really trust their roundness, and that's on top of them usually being made of some kind of ceramic and thus having grain.
(Maybe a cheap, single-use plastic cup would be smooth enough and stiff enough and round enough, given the production process.)
Yeah, I don't know what effect he is talking about here. SVG has <circle> which I would assume is normally rasterized to pixel-level accuracy (as opposed to approximated with beziers), so there are lots of "perfect" circles to be found. https://developer.mozilla.org/en-US/docs/Web/SVG/Element/cir...
I very like this kind of blog posts: simple, clear, to the point. I don't need to summarize it myself, I dont need to wonder if the preamble, history, anecdata, midjourney pics and diagrams are really necessary to understand the main topic.
As someone who's spent a decent amount of time writing "output to pdf" routines, I would never in a million years choose pdf as an interchange format for anything at all.
That comic is about what file types people choose to put what types of information (e.g. PDFs don't often get used for memes, and gifs don't often get used for scientific research papers). It's not even trying to make a point about the quality of the file formats themselves.
(I assume when you wrote "most reassuring" you were instead interpreting it as a comic about the file types' ability to accurately hold the information a user wants them to hold, because "reassuring" as pertains to the comic's actual meaning would be completely irrelevant to this topic of whether or not PDF makes a good interchange format.)
Right, I like to joke that pdf is where data goes to die. But management loves them, so we continue making them.
As clarification, once the data goes in to a pdf it is a pain to get out again for further processing. Not impossible, but the format is clearly designed to put shapes on paper. anything more and you have to fight for it.
I doubt that laser takes PDF natively, but probably converts from PDF using a custom print driver on the controlling PC. It is extremely likely this driver can also digest other formats.
>Furthermore, the human vision system is a bit weird and perfect circles look vertically elongated. You have to make them non-circular for people to consider them properly circular.
Just like how cows don’t look like cows on film![0]
I thought the article would go further and posit that Circles do not exist in reality as they are approximations of a mathematical ideal. But the author does present the raster image as a bonafide circle, rather than the approximation that it truly is -- more resolved than others or not. A zoomed in excerpt of the author's rasterized circle approximation clearly shows that scale is key in perception of reified ideals: https://ibb.co/P1KwLDm
I don't think the statement attempted to invalidate the article, there are many gems inside, such as the idea that human perception elongates the vertical axis, etc.
That's true in a sense, but you've got to go way down. At a fine enough level --- say, at the level of atoms --- all material things are granular, and circular or spherical things are built stepwise from material building blocks, as though from pixels. Thus even very "smooth" things are rough and granular.
Further: There are no circular (2D) molecules; nature prefers hexagons and other polygons for that. Even the proton isn't perfectly spherical. Whether the electron and other subatomic particles are perfectly spherical cannot, as yet, be determined. (The electron seemingly has a diameter far below the Planck Length.)
There are no very large circles or spheres, either. All astronomical bodies are somewhat flattened.
So I dare say perfect circles and spheres do not really exist, save as idealized mathematical objects.
I wouldn’t have believed you until I started looking into how spheres are made with various materials. All of them require immense amounts of iterations from rough cutting to polishing. Generally they are formed by reducing from a larger piece of material, sometimes inflated. It is never a cheap process to make a sphere and against nature is to achieve it. In the collection of gravities the earth and its inhabitants are subject to, straight lines are rare. A perfect sphere demands infinite straight lines of equal length from one point in space and for those to persist over time. A tall order for mere matter. Buckyballs are good enough for me.
But isn't the nature of attractive forces, like gravity, to squish everything into perfect spheres? The matter wants to resist, but that's another topic. The main issue is that pesky rotation - angular momentum is a blemish on the otherwise perfect equations of the cosmos.
Lead shot is typically spherical without any trimming from a larger piece. The traditional method is called a shot tower, and involves dropping molten lead so it forms small drops that cool as they fall, until they impact into a water bath. This works because drops of liquid are spherical below a certain size dependent on the material. The classic depiction of a rain drop is entirely false.
That is: every real, non-theoretical Point must have a size, a resolution; and every non-theoretical straight Line is surely not a true straight line if we zoom far enough down into sub-atomics.
Large black holes are the most spherical things in the relative sense, not in an absolute sense; although more so than pico-black holes, which are not very spherical.
Light cones/the 4d-radii of causality are* perfectly spherical.
>The electron seemingly has a diameter far below the Planck Length
According to what? We have nothing that can measure anything close to that. The standard model doesn't predict any radius on the electron, just defining it as point-like.
> Whether the electron and other subatomic particles are perfectly spherical cannot, as yet, be determined.
How can we ever determine something to be perfectly spherical? Any measurement comes with finite precision, and maybe the thing is actually not a sphere if we measured with more precision?
All measurements we have done on the electric dipole moment of the electron suggests that it could be zero. (The standard model predicts it to be non-zero, but very very very small.) This suggests that the charge distribution of the electron is spherical (or very very very close to).
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.
Not really? It's considered as an interchange format, not as the interchange format. If you have CAD/CAM work for parts that need precision machining measured in tenths or less, you're not using machines that accept PDF to begin with.
216 comments
[ 3.1 ms ] story [ 237 ms ] thread> The arc is represented internally by one or more cubic Bézier curves (see curveto) approximating the required shape. This is done with sufficient accuracy to produce a faithful rendition of the required arc. However, a program that reads the constructed path using pathforall will encounter curveto segments where arcs were specified originally.
[1] https://www.adobe.com/jp/print/postscript/pdfs/PLRM.pdf
But that's a rendering implementation detail, no? Isn't the precision and accuracy of any digital or physical manifestation of a circle limited by implementation details and physics?
Don't be so irrational.
https://factmyth.com/factoids/there-are-no-straight-lines-or...
Is this really an accurate conclusion? Just because there are no primitives for a circle – postscript is still a programming language so you can also plot a proper circle with trigonometry?
Is a 360° arc not a circle?
No, I could've sworn PDFs supported arcs but I was wrong. :) So when rendering/converting PostScript to PDF, circles/360° arcs must be converted to béziers.
Lathes do circles all the time. But it would be difficult to rotate either the head or the bed around an arbitrary axis in order to print a proper circle.
Thanks for your efforts.
Of course any physical machine is only making an approximation of a circle (even a lathe doesn't turn perfectly round, there is no such thing), but at least for CNC and 3d printing you can specify a perfect circle. In PDF you can't.
(Yes, it is also true that a typical 3d print comes from an STL file, which can only specify triangles, so STL files also can only specify approximations of circles. But it is still true that most 3d printers run G-code, not PDF.)
It followed PostScript which was a programming language that was intended to be directly undertood and runnable by Postscript enabled printers.
Postscript could easily do the job here, it had "arc" drawing primitives that described circles (both full and partial).
The 'failure' of Postscript was that as a programming languge a bad .ps job could crash a printer and a 1,500 page .ps document had to be internally fully rendered just to print out page 73 only (potentially code on any 'page' could loop back or forward and generate image elements on any page).
As a not-quite PostScript simplified 'other' the PDF formal languaage spec only allows the drawing of lines and 'curves' and curves are explicitly 3rd order bezier splines.
See: Path Operators (Page 95)
Portable Document Format Reference Manual (230 pages)
https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandard...
You don’t have to look for long on YouTube to find videos showing lathe tolerances of ten mil or lower.
And things like bearing races, where imperfections are a common failure mode, are turned for polishing if nothing else.
Respectfully, I don't think you're limited by the PDF format if you're talking about a laser cutter. And... Circular motion doesn't spring forth naturally from gantry CNC laser cutters -- they're rectilinear in design. It's circles not existing all the way down.
Using it as a CAD format with inherent fundamental shapes missing seems kind of funny, though.
Plus, if that level of accuracy is required simply adding more nodes improves accuracy exponentially.
Not least, the “standard” approximation really should be updated in software, as modern 4-node approximations are down to 0.005%, almost an order of magnitude better.
If you got a machine that's accurate to 1200 dpi presumably you want 1200 dpi and not 600.
If all the lines were off, then yes, kinda. Ish.
According to another comment, it actually improves at O(n^6).
I sincerely hope that the upcoming Windows third-party print driver deprecation kills this.
(Also, what’s wrong with them? Even ignoring cost, I would rather have a Chinese printer that had a publicly known control interface and supported Lightburn than a “nice” American laser printer that was only operable with bad proprietary software.)
When you're cutting things on a laser, there's myriad sources of error. Odds are the optical path isn't completely square, so there's some cross coupling between axes. There's drive belts. The laser is often pulsed. There's taper.
Now the postscript to servo control program(g-code?) interpreter might use the same bezier curve approximation, but it might not. I think if it were a formal complaint they would have to positively assert that their machined circles are following an inferior profile rather than just assume they are.
g-code sort of sucks as a language. It is very primitive. I always thought it would be cool to have a postscript dialect that supported more than two axis to use as a low level language on computer driven machine tools.
I don't think many laser cutters use raster scanning, though. That's going to leave some really nasty artifacts. You really want to cut continuous lines like, well, lines.
G codes in fact have command for arcs.
G02 establishes a mode for clockwise circular arcs. G03 establishes a mode for counter-clockwise circular arcs.
So... you know... note to self... when designing a laser cutter, allow the user to upload G-Code.
That said, apart from a handful of misconfigurations, I've never had a problem getting any of them to cut out nice circles.
facepalm. A raster image can't express a circle either - it's also just an approximation.
Same thing with a printout, for that matter. Maybe you could claim some kind of radial plotter is a true circle, but even there we're talking about pigment being absorbed along individual paper fibers.
In reality, all the mathematical shapes are just abstractions to be approximated.
One approximates the circle to the limit of the chosen resultion, the other simply has an error. A small error, but an error nontheless.
For a given circle and DPI, one can figure out the minimum number of Bezier curves necessary to represent the circle such that rendering those Bezier curves out to pixels will get you the exact same result as having rendered the circle in pixels directly.
You're not wrong, but it's like someone showing proof that a person can't fly unassisted and then responding with "well dogs can't meow".
They're saying that your arc for your circle will be incorrect before it's ever put into a concrete implementation. In other words, there's a base level inaccuracy and then your rasterization brings a whole new, different inaccuracy into play.
So yes, my "wacky analogy" is exactly apropos here.
> the Bézier inaccuracy has nothing to do with rasterization
Obviously, because rasterization refers to pixels and has nothing to do with Bezier curves. On the other hand, that inaccuracy has everything to do with Bezierization.
> there's a base level inaccuracy and then your rasterization brings a whole new, different inaccuracy into play.
Yes, stacking two inexact transformations will result in more inaccuracy than a single one.
Since you seem to be attached to your analogy - it's more like a person making the argument that humans can't fly unassisted, while showing a picture of a pig as an example of flying, and I'm pointing out that pigs can't fly either.
> "This is why you're taking less field work? Because you're reading 'On Circles, Volume 12'?"
> "I wrote it."
> "Unsurprising."
> "I have to rewrite it. All twelve volumes [...] our physics framework was completely wrong!"
> "Even about, like, circles?"
> Ikora turns to look Chalco in the eye. "Especially about circles."
[0] https://www.ishtar-collective.net/entries/vesper-of-radius
The human eye is not capable of seeing the difference, and, as the OP mentioned, most people can't accurately eyeball a perfect circle anyway.
This post shows the math behind that, and then shows that it could be made even better with a few different choices.
https://spencermortensen.com/articles/bezier-circle/
P.S. of course, a display intended for the human eye has much looser tolerances than a gear or wheel.
1. PDF is to become a standard CAD interchange format.
2. Using PDF where 0.03% matters is insane.
3. If CAD requires 0.03% tolerance, then using PDF as a standard CAD interchange format is insane.
I would imagine you generally want arbitrary precision for CAD.
I cannot imagine a CAD system that can't symbolically represent what is actually desired. The model and its spec should be one and the same.
Approximations also open the door to different precision versions. Not helpful when different parts from different sources need to be consistent.
Models that approximate/vary from the ideal spec, created intentionally to match manufacturing limitations, are ok.
For laser cutting, I prefer to use SVG, as it's easier to generate. I had not really thought about precision, but SVG can represent circles directly.
Al you need to fix this is use rational Beziers - same thing but with weighted control points.
STEP files will remain the standard for CAD.
Then it is settled, we'll use .TTF as our CAD interchange format.
For example, you can make a shaft that fits in a hole like a spring because it can slide freely but air can't get out and you can shave a few microns off and it will sink into the hole at a controlled rate. This is all easily achievable in a home machine shop on a manual lathe. With Wire EDM, you can achieve even tighter tolerances and it would be perfectly possible to generate a part that could fit but could not spin because of the PDF error.
[1] https://en.wikipedia.org/wiki/Interference_fit
You are going to have a really hard time finding an industrial application where a 6.2e-8 error matters.
In fact, check this out: the Epilog Fusion M2 40 laser machine that the author chooses to picture as the problem instance can engrave a circle of at most 28-inch diameter, and has a resolution of 1200 dpi. Therefore two (gasp!) Bézier curves per quarter circle offers far more precision (4.0e-6) than this machine's error (1/1200/28 = 3.0e-5).
Edit: or take the world's roundest object: a sphere made out of a single crystal of silicon-28 atoms, with a roundness delta of less than 50 nanometres over a 93.6 mm diameter (https://www.heason.com/news-media/technical-blog-archive/wor...) This is an error of 5.3e-7. Four puny Bézier curves per quarter circle (6.2e-8) are more perfect than this sphere.
And while it's possible to approximate with higher bezier curves, PDFs are auto generated with software libraries and it's going to be non-trivial to dive into the guts of a library of a library of a library and tweak the logic for generating circles for this one specific type of application.
If you want a circle that's better than a 0.03% tolerance, odds are you're not making it by tracing a circular path in g-code, but instead using something like a lathe.
> And while it's possible to approximate with higher bezier curves, PDFs are auto generated with software libraries and it's going to be non-trivial to dive into the guts of a library of a library of a library and tweak the logic for generating circles for this one specific type of application.
A lot of work on CO2 lasers you do with something like Coreldraw or Inkscape. You absolutely can pick the number of vertices with some slight work.
Lasers are a bit weird in that most of their work is for signmaking. Most end-user use cases are closer to a printer than that of a typical CNC machine. Indeed, it can be annoying to take something from CAD to lasers that want PDF, because you can end up with things like the resultant PDF not joining lines together properly into one shape and the laser "stopping" on each vertex. You end up pretty carefully picking tools and processes for this flow. Ideally you figure out how to give the laser a dxf...
I can tell from this statement that you do not have a home machine shop with a manual lathe. Home machine shops most certainly do ~not~ typically (or easily) achieve micron accuracy.
For "circular" work that you do use a laser cutter for, 0.03% tolerances are below the variance you get from the cutter itself. Expecting higher precision from the cutter that is somehow "messed up" by the deviation from the standard Bezier approximation of a circle, when the machine you're using can't give you that precision is using that proverbial hammer.
Of course, if that's really all you have access to (first of all: what are you even doing? look into buying a second hand lathe, or have everyone pitch in so your hobby space can buy one, they'll set you back less than a thousand bucks) the laser cutting is step one, you're not done after cutting, and you know you're not done after cutting because you know laser cutters are not high-precision machining tools like lathes or mills. You cut slightly oversized, and then you clean up the part and machine it down to final dimensions until your micrometer says you're within tolerance.
What is this unit?
https://en.m.wikipedia.org/wiki/Thousandth_of_an_inch
A 1/10th of a thou is 1/10000th of an inch, or 2.54 micrometers. It's insanely small.
Why, America... At that point, if it's inventing new units to decimalise USC units, why not just use micrometres?
This leads to a lot of conflation, mess, and misreporting by vendors and OS authors. Windows is an egregious example. A 1 TB (terabyte, 10^12) disk is reported in Windows as 931.7 GB. It ought to be 931.7 GiB, which is what Linux does. macOS uses the correct number but SI prefixes, so 1 TB is reported as 1 TB.
https://eepower.com/resistor-guide/resistor-standards-and-co...
So the metric system and decimalization of the inch are roughly contemporaneous and “just use this othe, also brand new system” isn’t an obvious choice at that point.
I think the real question is... Why is such a unit still being used? I was under the impression that any serious ultra-precise CAD and machining was done in milli, micro, and nanometres. I thought pretty much any serious science or engineering had been metricated...
But then again I shouldn't be surprised; Americans measure the volume of lakes in 'acre-feet'...
Don't try to logic how Americans measure things.
Hopefully anyway.
Pdf is for print and human eyeballs. It's brilliant for those 2 things and not much else.
You can have both in parallel, and have the editing software regenerate the rendered form from the source data form when anything changes. It’s not completely uncommon to use PDFs as a data carrier that way.
Of course the drawing could then be out of step with the data, but so what.
If you want to produce a highly regular circle in Inkscape, draw a polygon with many nodes (say, 24), convert it to path, then make all nodes smooth and symmetric.
This is true for curve fitting of arbitrary curves, not just circles, though arbitrary curve fitting is a bit tricky (it requires solving quartic equations). I personally think you can take this as evidence that cubic Béziers are "good enough" for all practical tasks requiring curve representation, though for specific applications there might be other representations that work better.
When you print to PDF, the circle will have to be approximated, which is what the article is talking about.
https://lessonstream.com/the-story-of-mr-os-circle/
But I don't think that is right. He argued that matter existed in a relation of participation in the forms, that making such things like shadows or approximations of ideas. Aristotle deployed the third man argument to attack this notion. Plato conceded his view was problematic.
But I am not certain that is your criticism, or that this applies here? Platonism posits a third realm of ideas, one which Aristotle denies and attacks (and which Plato acknowledged), instead locating universals in things and in the intellect that grasps them. However, you can restore a kind of realm of ideas by interpreting it as (the mind of) God. So, universals exist in all three cases, though the manner in which they exist varies (e.g., in things as concrete instantiations, vs. in the human intellect as concepts abstracted from the concrete).
A spinning movement has to be a perfect circle, no?
And, in fact, even if they did exist physically, the very fact that the concept or predicate of Circularity exists in the intellect (and this concept must be Circularity as such or else we could not speak of circular things) and applies to many things despite their diversity, also suggests something about the intellect, namely, that it is not physical, as the physical is always concrete, instantiated, singular, this-and-not-that, not ideal.
Not something most people notice unless they are looking for it.
I remember the Q3A Beziers were advertised as if the game rendered actual Beziers (which would in principle be possible in software but not on hardware… of the day, anyway), rather than just doing dynamic LoD approximation with your bog-standard triangles!
An oscillating display can do curves, but only in a wave/ linear sequential fashion.
Yes, this is theoretically possible. I imagine it wasn't done due to processing limitations during the time vector displays were common; but my limited knowledge in the realm doesn't give me certainty.
Does any one have a link to a perfect circle, I'd love to see if it has the proposed effect on me.
(Maybe a cheap, single-use plastic cup would be smooth enough and stiff enough and round enough, given the production process.)
https://xkcd.com/1301/
What would you put at the top?
.PS is pretty fancy, although, just because it is probably saying “this is basically a PDF but from the olden days.”
(I assume when you wrote "most reassuring" you were instead interpreting it as a comic about the file types' ability to accurately hold the information a user wants them to hold, because "reassuring" as pertains to the comic's actual meaning would be completely irrelevant to this topic of whether or not PDF makes a good interchange format.)
As clarification, once the data goes in to a pdf it is a pain to get out again for further processing. Not impossible, but the format is clearly designed to put shapes on paper. anything more and you have to fight for it.
Just like how cows don’t look like cows on film![0]
[0] https://www.youtube.com/watch?v=KbkNul4wQH0
EDIT: apologies for the tone; came off very snide on second read.
Further: There are no circular (2D) molecules; nature prefers hexagons and other polygons for that. Even the proton isn't perfectly spherical. Whether the electron and other subatomic particles are perfectly spherical cannot, as yet, be determined. (The electron seemingly has a diameter far below the Planck Length.)
There are no very large circles or spheres, either. All astronomical bodies are somewhat flattened.
So I dare say perfect circles and spheres do not really exist, save as idealized mathematical objects.
That is: every real, non-theoretical Point must have a size, a resolution; and every non-theoretical straight Line is surely not a true straight line if we zoom far enough down into sub-atomics.
What about them?
Light cones/the 4d-radii of causality are* perfectly spherical.
According to what? We have nothing that can measure anything close to that. The standard model doesn't predict any radius on the electron, just defining it as point-like.
> Whether the electron and other subatomic particles are perfectly spherical cannot, as yet, be determined.
How can we ever determine something to be perfectly spherical? Any measurement comes with finite precision, and maybe the thing is actually not a sphere if we measured with more precision?
All measurements we have done on the electric dipole moment of the electron suggests that it could be zero. (The standard model predicts it to be non-zero, but very very very small.) This suggests that the charge distribution of the electron is spherical (or very very very close to).