Thank you for taking the time to reply, Ian. I’m glad to see the related GitHub issues you had opened. I hadn’t seen the metrics related ones in my earlier research.

My initial despair was because when studying the current API, it appeared to be a design decision to hide the low level text engine API. And if it is a design decision, then opening a GitHub issue wasn’t likely to help. I’m glad to know now that the Flutter team is open to it, even if (like #224) it is a “Stretch Goal”, that is, something not likely to be worked on in the coming year.

My thinking is, if you open up more of the low level API, we can fix many of our own problems. We wouldn’t have to open GitHub issues for every feature request and then wait for it to someday be implemented. Taking text on a path as an example, I think it is great that it is on the list of things to add. I assume, though, that it will probably be added as a thin dart wrapper method that calls the underlying LibText engine, where the real work is done. If developers had access to more of the engine (whether it is a specific Skia call to write text on a path, or just a general ability to measure and layout glyphs), then we could write our own package to do it. Later, Flutter could add official support as time permits, perhaps even borrowing from user created packages.