search

julianandrews / sgf-render

Sgf Rendering CLI written in Rust
MIT License
34 stars 8 forks source link

Add support for custom position labels #17

Closed julianandrews closed 1 month ago

julianandrews commented 3 years ago

It would be nice to have a way to specify the labels to use.

Implementation should be easy, but the CLI UI design is a little tricky. I think I probably want independent flags for the --x-labels and --y-labels but I'm not sure what they should look like.

Ideally, I'd like to support

Besides figuring out what an argument that allows that would look like, I also have to worry about label length. Options:

That second option is definitely a lot more work, and finicky (since SVG 1.1 text rendering isn't the most graceful), so at least for the first version of this, I'm thinking to limit labels to one character.

This should be easy enough to implement once I decide how to answer these questions, but I'm not really happy with any of the UI options I can think of.

This is split off from #12.

julianandrews commented 1 month ago

While looking into #43 I re-evaluated the problem and came up with some alternative approaches here. One relatively easy approach that could work is to have a small handful of pre-programmed label sets that can be selected. So instead of the default labels you could choose SGF style labels (where it users a-z and A-Z without skipping 'I'), or Japanese labels (where it uses the standard Japanese characters - are those even supported by the current font?).

This is a less general approach, but would make it easy to support the more common labeling options, and wouldn't be incompatible with more complex options down the line.

On the other hand, I've also realized that customizing the labels as an SVG post-processing step shouldn't be too complicated, and maybe in the interest of keeping the tool simple and general, I should just make that the officially recommended approach.

julianandrews commented 1 month ago

Having had some time to reflect, I think I've decided that this is a niche enough use case that it's not worth the added UI complexity. If someone really wants to fiddle with the board labels it's not hard to modify the SVG directly. All the board labels are text elements under the #board-labels group.

In the interest of keeping things clean and simple, I'm closing this issue.

I might re-evaluate if someone comes along with an actual use case, but at least as long as I suspect no one has any use for the feature, I'm not really inclined to change this.