What is a curve? Points along a curve, or a cubic Bezier?

[ramcdona]

In the past, I have accomplished pdfplumber-like work flows by converting my PDF pages to EPS and then hand editing the postscript text file.

From this, I have familiarity with the curve entity being a cubic Bezier curve specified by sets of control points. A brief look at the PDF standard leads me to believe that curve path entities are cubic Beziers.

When I use pdfplumber to access a curve, are those the control points of a cubic Bezier? Or does pdfplumber render the curve and then spit out a selected number of points along the each Bezier?

If the curves are cubic Bezier (4 control points per segment), are the first/last control points of each segment repeated? i.e a series of segments would have 4,3,3,3,... control points. Or is each segment stand-alone, 4,4,4,4,4,... control points.

[jsvine]

"What is a curve?" is a great question, and one that should probably be better-documented in the README — because it's a bit of a misnomer. This library's layout-object-names (char, rect, etc.) come directly from pdfminer.six, its main dependency. You can find an overview of them here. And here is the class definition for a generic curve. The logic in the .paint_path method here informs my current understanding of what ends up a "curve":

• A path is, by default, a curve ...
• Unless it's a single line segment, in which case it becomes a line ...
• And unless it is four line segments that form a rectangle, in which case it becomes a rect.

In sum: Any multi-segment, continuous path that does not form a rectangle is labeled a curve. ("Continuous" because the code above splits non-continuous path definitions into its constituent subpaths.)

I haven't worked much with proper control-pointed Bezier curves, so I unfortunately cannot answer that part of your question authoritatively. But it seems the answer is that typically the points available to pdfplumber (via pdfminer.six) are "points along a curve" rather than the control points.

However, it seems possible that when a PDF defines control points for a path (which does not seem to be the default when drawing simple paths, per the spec), pdfminer.six may intermix those control points with the points-on-path. At least that's my interpretation from eyeballing the code that starts here (where pdfminer.six parses the granular path instructions from the PDF) and here (where it creates the curve objects).

If you dig more into this, I'd be very interested to hear what you learn.

[ramcdona]

Thanks for the pointers, I'll try to dig in a bit.

It seems crazy that the PDF file would ambiguously encode curves. If they're points along a curve, great. If they're Bezier segments, great. There should be some indicator, flag, or change in object type. Don't just leave it up to a reader to guess. I'll find something...

In practice, the 1st and 4th control points of a cubic Bezier segment always lie on a curve. When the curve segment is a straight line, the 2nd and 3rd control points also lie on that line. Consequently, If you take a relatively straight curve and represent it with a large number of Bezier segments, the control points are very close to the line. You would be forgiven for thinking they were just points on a curve.

I always found the use of Bezier curves to be an odd choice for PostScript (where this all comes from in the end). It makes sense for text glyphs I suppose, but for science / engineering type plots (think matplotlib use cases), you generate curves by plotting points along the curve (not a bunch of Bezier segments). If you're going to Bezer-ify that curve, you need some real sophistication to convert between points on a curve and Bezier segments. Placing that burden on every single program that ever writes a PS, EPS, and now PDF file never made sense to me.

As a person who generates technical plots, I don't want my plotting program to smooth my data. If I feed it points along a curve, then I absolutely want it to plot straight line segments connecting those points. Fortunately, this is generally what happens -- all the way through to generated PDF files.

I have found files 'in the wild' with technical charts (presumably created from points on a line) that were represented by Bezier curves in a EPS I wrote from the PDF. So somewhere, someplace, programs make this conversion.

I think I chased it down in matplotlib one time. Deep in the C library that actually does their rendering, they have some magic code for this....

[jsvine]

It seems crazy that the PDF file would ambiguously encode curves.

I may be misunderstanding this comment, but it's not the PDF file that encodes curves ambiguously — path commands, including those that would produce curves, are very precisely defined in the PDF spec. (See section 4.4 of the official reference manual.) Rather, it's pdfminer.six that appears to represent them ambiguously. The PDF spec is huge, and pdfminer.six has done an admirable job wrangling and edge-casing the most-used parts of it, but this seems like an area for potential improvement.

[ramcdona]

Thanks for this comment -- I better understand what you mean.

I'll have to spend some more time with the pdfminer.six algorithm you've pointed to. I briefly looked at it and understood at a top level what it was doing, but I didn't really trace it all.

Paths are made up of PostScript drawing commands. The most common commands are m, l, and c. m is moveto, l is lineto, and c is curveto.

m x1 y1 % Moves the drawing cursor to the coordinates x1 y1
l x2 y2 % Draws a line from the cursor location to x2 y2 and moves the cursor with it.
c x3 y3 x4 y4 x5 y5 % Draws a cubic Bezier curve from the cursor location using points 3,4,5 as the remaining control points.

Most paths start with a single moveto A path can be made up of combinations of lineto and curveto commands.

pdfminer has a clever algorithm to take a complex path made of multiple primitive drawing commands and break it down into parts.

When I first studied it (very briefly), it seemed to recursively break things down looking for moveto as the delimiter. Once a path fragment only had a single leading moveto, it would try to classify what was left.

That said, I never actually saw anything that handled curveto -- it looks like it may only handle single straight line segments, rectangles, and points along a curve....

But, I am probably just missing where it handles curveto and Bezier curves.

Hopefully after some more study, I'll find that pdfminer is doing a reasonable job of things... I'll let you know if I figure anything out.

[jsvine]

Update: This discussion prompted me to take a closer look at the PDF spec re. Bezier curves and pdfminer.six's path-parsing logic. The latter was, indeed, mixing both control points and points-on-curve, so I've updated my .paint_path PR there to address that. The proposed changes would remove control points from the .pts attribute.

I also suggested (in general terms, not code) making the more detailed path data through an LTCurve attribute, so that people can fully recreate Bezier curves if they want to.

[ramcdona]

Thanks for the update. If it were me... (I know it is up to the pdfminer.six team in the end) I would create two separate classes. One for a curve made of points along a curve (piecewise linear) -- an arbitrary combination of mllllllll... ending in l or h. The second for a piecewise cubic Bezier -- an arbitrary combination of mcccccc. The v and y commands can be converted to c commands by explicitly repeating the control points. So, the LTCubic would be able to be treated as if it was a mcccccc series. The hard part here is detecting a situation where a path is made of a mixture of l and c commands. You should be able to detect that by inserting fake m points and split whenever a changeover happens. I suppose some renderers might make different stroking decisions at the blend from one path to the next, but it seems the simple way. The alternative seems to be to pass the l or c commands through to the LTCurve class. It still may be worthwhile simplifying out the v,y commands, but it goes to the next step. I now see what is happening for cases with c,v,y (nothing, they fall through and are treated the same as l). I was so fixated on looking for explicit parsing of c that I didn't consider this case... Thanks, Rob

…

On Sun, Feb 7, 2021 at 11:42 AM Jeremy Singer-Vine ***@***.***> wrote: Update: This discussion prompted me to take a closer look at the PDF spec re. Bezier curves and pdfminer.six's path-parsing logic. The latter was, indeed, mixing both control points and points-on-curve, so I've updated my .paint_path PR there <pdfminer/pdfminer.six#530> to address that. The proposed changes would remove control points from the .pts attribute. I also suggested (in general terms, not code) making the more detailed path data through an LTCurve attribute, so that people can fully recreate Bezier curves if they want to. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#345 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKETQHYCH5GTPK3MRAYMADS53UKBANCNFSM4XEGXIRQ> .