In case it's relevant, here is the result of the search:

Here's another one of those ‘if I knew Python better I'd know the answer already' questions, probably, but: what is this error message telling me, exactly?

@gferreira Thanks, Gustavo! I don't know how I've managed to go nearly four years without knowing this—I feel like I've used this method in the past to restore a reference. Lesson learned.

a = 1
b = [(a, a), (a + 1, a + 1)]

d = 1
g = b
print('original:', b, 'new, pending:', g)
c = [0, 1]
for n in c:
    g[n] = (g[n][0] - d, g[n][1] - d)
print('original:', b, 'new:', g)

returns:

original: [(1, 1), (2, 2)] new, pending: [(1, 1), (2, 2)]
original: [(0, 0), (1, 1)] new: [(0, 0), (1, 1)]

What is going on here? Why does changing g also change b?

@frederik Thanks (and thanks for opening this over in the GitHub repo). I'll give it a try later today. Speed isn't a factor in this case because I'm generating static diagrams.

I've been using DrawBot to generate diagrams—specifically, Boolean diagrams of categories with fuzzy boundaries—and I would love to see both linear and radial gradients incorporate an alpha channel.

I thought after I posted that pens would be part of a more elegant solution—my problem reminded me of some things Just has shown me, and I recall pens coming up in that conversation.

The fix I did find was to create a function that creates and returns a new path from the uncorrected path contour by contour and segment by segment, correcting points as needed by rounding to the nearest implied-grid increment. But now that classes are out I'll take the time to learn about pens (finally).

I'd still like to figure out why I was having the problem in the first place. At 1000pt the glyphs in Kast, my font I've been working with, are all exactly 692pt wide. With the proper linespacing and every other line offset 346pt (the width of the <space> glyph) all the points in adjacent glyphs horizontally and vertically should match exactly to allow me to combine their paths seamlessly.

Looking at the errors—maybe I'll put the analyses up in another post, I saved my test code—I felt like there was something about the formatted string that was introducing systematic misalignment, and removeOverlap() was also doing some math that threw off some points in the combined paths.

For reasons I can explain in detail if needed, I'd like to edit the oncurve points of a BezierPath before drawing the path, checking each point in turn to make sure its coordinates fall on an implied alignment grid and correcting it as needed.

Two methods that apparently don't work are:

for pt in path.onCurvePoints:
     if test(pt[0]) == Fail or test(pt[1]) == Fail:
          pt = (correctedCoordinate, correctedCoordinate)

and

for pt in range(len(path.onCurvePoints)):
     if test(path.onCurvePoints[pt][0]) == Fail or 
          test(path.onCurvePoints[pt][1]) == Fail:
          path.onCurvePoints[pt] = (correctedCoordinate, 
               correctedCoordinate)

Good to know, thanks. But that means that default linespacing = fontSize + 1?

,Here's something interesting I found while writing code to generate the dimensions of a canvas based on the amount and size of the text I want to set in a square-ish field on the canvas.

fontFamily = 'kast_4_a'
fontStyle = 'top_0'
fSize = 1000
test_string = FormattedString()
test_string.append('a', fontSize = fSize, font = fontFamily + '-%s' %fontStyle)
print(test_string.size())

yields the following:

<NSSize width=692.0 height=1001.0>

I can confirm that DrawBot's size() returns a height of any fontSize + 1.

I was hoping to use the size of the text box to calculate the height of the canvas, but now I have to adjust that it seems. What's happening here?