Initial commit for geomtextpath

[AllanCameron]

The initial version of geomtextpath with rudimentary docs and functionality is here! This version passes CRAN checks.

I have put copious comments in the code, including a couple of TODO sections that might be good places to start.

There are a few thoughts that occurred to me that we might wish to consider.

1. There are no tests currently. How do we unit test when visual inspection of the output is required?
2. What other geoms might usefully benefit from curved text?
3. It would be nice to include a polar coord that has curved axis text & titles.
4. It is going to be difficult to think of all the use cases and edge cases. How do we beta test?
5. How will we know / decide when to submit to CRAN?

[teunbrand]

Hi Allan,

This is great, nice to see the readme got updated with clear examples and such!
As for your points, here are some of my thoughts.

There are no tests currently. How do we unit test when visual inspection of the output is required?

We might be able to use the {vdiffr} package for testing visual output. But we might include some more basic tests to validate that individual components (helper functions) are working and then use a visual test to see that everything integrates as intended.

What other geoms might usefully benefit from curved text?

If the main function is text on a path, it would be quite easy to extend it to the case of geom_line() and geom_spoke(), which are essentially just reparametrised geom_path()s. In addition, we could include a polygon version (that would be a simple adjustment of an open path to a closed polygon).

It would be nice to include a polar coord that has curved axis text & titles.

I agree, it would be nice if we would have a guide for this along with a coord_polar() version that accepts custom guides.

It is going to be difficult to think of all the use cases and edge cases. How do we beta test?

At some point when we're happy with the code, we might submit the repo to the ggplot2 extension gallery, which hopefully triggers a few people to test and report back any problems they experience. Additionally, we might post about it in a blog post or on twitter to increase visibility. I don't think we should defensively code against all edge cases, just the ones you might reasonably run into.

How will we know / decide when to submit to CRAN?

I don't know this for sure either, but lets say when we're both happy with how everything works, have got automated checks in place, we've let people play with the functions and given some time to report any problems? We might also still write a vignette or build a pkgdown site for people to visit.

I'll have a more detailed look of the code later in the day!

[AllanCameron]

This thread was to discuss details of the initial commit and anticipate problems early-on. Specific issues have now been moved to the appropriate thread to keep development focused on these.