You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking into this it's a bit annoying; we really would want to do strikethrough run-by-run, since the position and width of the strikethrough depends on the font, unlike underline, which uses the same style or each line.
My inclination is to not invest too much in this right now, and we can revisit for a future cycle.
we need to pick a strikethrough position. This can be a heuristic; I would start by trying 50% of the font's reported x-height.
we need to decide how to handle lines with multiple runs of different fonts or different sizes. Since we don't paint run-by-run, we will have to just pick a single position, and it will not look right if fonts have different heights, but I think that's okay for now; so I would just go with the first font in the region?
(actually, maybe we can keep track of this per run? we know the offsets of the runs, and we're drawing ourselves, so this should be doable? but I don't mind if we keep things simple for now)
we need to pick a stroke width. I don't have any insight here. There is CTFontGetUnderlineThickness which might be a good proxy, but we could also just pick some number, either absolute or relative to point size, and go with that.
we need to store the stroke information for a given layout object ourselves, inside the object. I would try to store this as a Rc<[Line]>, with coordinates relative the origin of the layout. (we may also want to store color and stroke thickness?)
after painting the layout, we iterate the strikethrough lines and paint those overtop.
I'm not sure about any of this; it's just my best guess for how it should work.
See #299. For coregraphics https://www.cocoanetics.com/2011/01/befriending-core-text/ has some useful details.
The text was updated successfully, but these errors were encountered: