Is there any way with racket/draw to convert a piece of text to a dc-path%, or is that just fundamentally impossible (either due to how Cairo works or because it just isn’t exposed through the Racket API)?

dc-path% has a text-outline method. Is that what you’re looking for?

Aha, thanks! Not sure how I missed that.

@mflatt Is it intentional that the draw-rectangle method of dc<%> aligns its coordinates when drawing the stroke but not when drawing the fill? And if so, why? (If no, I can open a PR to fix it, but based on the way the code is structured, it seems intended.)

Maybe I’m not looking at the same place, but I think it does align for the fill. Both cairo_rectangle calls use ax and ay.

Oh, the width and height are not aligned for the fill… I’m not immediately sure

I’m looking at this line here, which seems to align neither coordinate: https://github.com/racket/draw/blob/3d4642cda1e1afb681fda8016a1ae3cea503b026/draw-lib/racket/draw/private/dc.rkt#L1224

Maybe it gets overridden somewhere else that I’m not looking at, though.

No, I’m misreading the code. Probably because ax is bound outside the first draw_rectangle, I read the x and ax.

It does seem like those should be aligned according to the docs, but it also does look intentional. And I agree about other methods. Just for reference, let me see what the older code did…

It seems like some of the drawing functions take care not to align the fill coordinates, but others don’t (e.g. draw-polygon), and I’m not sure why.

Looking at the git history, it looks like that code’s been there since it was first added in this commit: https://github.com/racket/draw/commit/b2f8e97e10dc0e515ce68d63d43c47aa803e1e96

But maybe there’s some other history prior to that that git doesn’t know about, I don’t know.

The function-like one would display its parameters as #<procedure> #<procedure> though, which isn’t very helpful.

I mean the C++ version, and I see that it did apply alignment. So, probably brush alignments just got lost. I worry about what will happen to existing programs when we change things (back), but it seems like we should try it.

Okay, maybe I’ll give it a try and write some tests, and we can see what happens.

It’s curious, though, that the code appears to be careful about not aligning the coordinates for the fill, even including the comment. But if you don’t know why, then I don’t imagine anyone does.

In case you haven’t discovered it already, you may want to start with tests/racket/draw/draw

I saw it, though it looked intimidating, and I didn’t look at it very closely. :) But I’ll take another look.

@mflatt I am trying to understand this sentence in the documentation for set-smoothing: > For line drawing, coordinates are further shifted based on the pen width and the alignment scale, where the shift corresponds to half of the pen width (reduced to a value such that its multiplication times the alignment scale times two produces an integer). After looking at the code that does this and re-reading, I now understand what it does, but I’m not sure it’s actually the right thing to do. IIUC it means it adds (* 0.5 alignment-scale) to the coordinates when drawing a stroke iff (quotient pen-width alignment-scale) is an odd number, which at first sounds reasonable: it avoids a line being drawn on a “pixel boundary” when the pen width is odd. The problem is that this doesn’t really do the right thing for the 'aligned smoothing mode, since it adjusts x and y, which means that when the line is perfectly horizontal, it can cause the x coordinate to go out of alignment, and vice-versa for the y coordinate when the line is vertical. For lines that are neither perfectly horizontal nor perfectly vertical, it seems like neither adjustment is really right.

Here are some visual aids, blown up with a pixel grid overlaid.

Does the output depend on the pen cap?

Yes, it does. Is the issue that this assumes a 'round cap?

Or, I guess it’s probably actually more relevant for a 'projecting cap.

I think that 'aligned makes only a certain amount of sense. If the current calculation does the right thing for rectangular frames and the broad side of lines, then that’s probably as far as we tried to refine it.

Alright, I guess that’s fine. Though the docs do recommend it: “For most applications that draw to the screen or bitmaps, 'aligned mode is the best choice.” Are you saying that’s not true, or just that there are caveats?

Well, it’s not that other drawing modes are better. But, in the past, we didn’t figure out how to solve all problems with 'aligned.

I see. So maybe it just needs to do something smarter here? I wasn’t thinking about the pen cap, but now that you’ve mentioned it, that makes sense. Maybe it could avoid applying the adjustment when the cap is 'butt except in the obviously-correct cases for perfectly horizontal/vertical lines.

That sounds plausible, though complex. The correct adjustment would depend on the slope of the line, right?

Well, I’m not sure if it makes sense to do any adjustment at all if the line isn’t perfectly horizontal or perfectly vertical (after coordinate alignment), since aliasing will happen, anyway, in those cases. But I guess there could be some way for it to be minimized more generally, which would take into account the slope of the line… but I’d have to think harder about it.

Ok, I agree that it potentially makes sense to special-case horizontal and vertical lines, taking into account the pen cap. To minimize changes, I’d keep the current adjustment in place for other lines.

Alright, I’ll give that a try for now, and if I come up with something better in the meantime then I’ll try that, instead.