Support for {marquee} about geomtextpath HOT 2 OPEN

Do you propose this would be as a replacement for or an addition to the current parsing method we have? If there is a particular feature we wish to add such as breaking up strings into substrings, might it be better to implement that within our own framework than absorb an extra dependency? That particular feature does not seem an insurmountable challenge. On the other hand, we could probably simplify our own code substantially while improving its feature set by switching to marquee.

Interestingly, marquee uses a custom C++ tokenizer and parser stack to process the markdown, very similar to the mechanism I have used myself for pdf parsing, and close to what I envisaged we could write when rich text support was first discussed back in #39. I think we had decided against it because compiled code would be too bothersome to maintain. I'm glad a more feature-filled version is available to use now (and maintained by someone else!)

from geomtextpath.

For now, I'll propose this as an addition to the current rich text parsing and maybe start gradually deprecating the current method over time. I'm willing to put {marquee} into the suggested packages in order to not maintain a parser. If {gridtext} had exported their parser, I think I had preferred to use that too; but since they didn't, we had to copy it. I'm still convinced that I wouldn't be able to maintain a C++ parser :p

I'll have to figure out exactly how it'll work but my initial feel for this feature would be that we could pass e.g. richtext = marquee::classic_style() (or another style set) and then {geomtextpath} would know to use marquee parsing.

from geomtextpath.