Added Labels element

[philippjfr]

Adds a Labels element type for vectorized drawing of labels and text. Also adds an emoji clustering dataset (~1 kB in size).

• Addresses Add support for arbitrary unicode labels #819 and Add a vectorized Text Element #1837
• Add unit tests
• Add reference notebooks
• Add demo notebooks
• Update examples using an NdOverlay of Text elements.
• Add xoffset and yoffset options to make usage as labels easier.

[jlstevens]

I realize this is still WIP but just as a reminder, I would use this PR to add a warning to hv.Text in this PR to say that it will eventually be deprecated.

[philippjfr]

I realize this is still WIP but just as a reminder, I would use this PR to add a warning to hv.Text in this PR to say that it will eventually be deprecated.

I don't necessarily think we have to deprecate Text, Labels and Text are independently useful for different purposes.

[jbednar]

The new docs for Labels make it clear how Labels has uses beyond what is supported for Text. If Text has uses not well supported by Labels, presumably that should be made clear now in the docs for Text?

[philippjfr]

Really a matter of convenience, if you want a single label: hv.Text(0, 0, 'Some text') is a lot simpler and more obvious than hv.Labels([(0, 0, 'Some Text')]). I have no strong opinion but I do feel immediately deprecating Text is premature.

[philippjfr]

Ready to review/merge.

[jlstevens]

Please use the table that is consistent with all the other element notebooks...

[philippjfr]

That does not format nicely in JupyterLab, all notebooks should be converted to this format. It looks nicer too and gets rid of all the horrible HTML.

[jlstevens]

In that case it should be fixed in a separate PR. Not by mixing different markup.

[philippjfr]

I've used the new format in all the recently added elements, no point reverting those. Happy to follow up this PR by updating all existing reference notebooks (although that should probably wait until your metadata PR is merged).

[jlstevens]

Ok. Sounds good.

[jlstevens]

It isn't really an annotation type given that it inherits from chart.Points.

[philippjfr]

True although that's mostly an implementation detail, I can probably get it to inherit from Dataset and Annotation instead.

[philippjfr]

Nevermind, not a good idea due to the custom Annotation.clone

[philippjfr]

Still shouldn't inherit from Points though.

[jlstevens]

I'm not suggesting changing the implementation, just fixing the docstring. Frankly, I see this kind of element as being halfway between a chart and an annotation type.

[jlstevens]

Still shouldn't inherit from Points though.

Agreed. But I assume it will have to inherit from some sort of Chart.

[philippjfr]

Dataset+ Element2D is the standard inheritance for something like this. At some point we should probably revisit these baseclasses, e.g. I think Scatter should be a Chart type for instance while Points shouldn't. In my mind Chart describes the 0-1D case of independent vs. dependent dimensions (e.g. Scatter, Curve, Area, Bars etc.), while we've never come up with a baseclass for the 2D space concept that encompasses Points, Path, VectorField etc.

[jlstevens]

Makes sense - maybe it could be called Chart2D or something. Anyway, I suggest filing an issue with this suggestion if there isn't one already.

[jlstevens]

Implementation looks fine other than few comments I've made above. I still think having so many uses of the word label is annoying but I don't have a better suggestion (don't particularly like MultiText for example). Anyway, happy to merge once my comments are addressed.

[philippjfr]

Ready to merge.

[jlstevens]

Looks good. Merging.

[jbednar]

Really a matter of convenience, if you want a single label: hv.Text(0, 0, 'Some text') is a lot simpler and more obvious than hv.Labels([(0, 0, 'Some Text')]). I have no strong opinion but I do feel immediately deprecating Text is premature.

It seems like it would be confusing and ambiguous if hv.Labels() accepted that same signature? If so, then should hv.Text(*a) just become a macro that returns hv.Labels([*a])? I guess the main implication of that would be for options, which would then need to be set on Labels instead of Text. Hmm.

[philippjfr]

I guess the main implication of that would be for options, which would then need to be set on Labels instead of Text. Hmm.

We do have a mechanism for this which is an operation+Compositor, which would look something like this:

class text_to_labels(operation):

    def _process(self, element, key=None):
        params = hv.util.get_param_values(element)
        return Labels([(element.x, element.y,  element.text)], **params)

Compositor.register(Compositor("Text", text_to_labels, None,
                               'data', transfer_options=True,
                               transfer_parameters=True,
                               output_type=Labels))

[jbednar]

@philippjfr, that sounds like a reasonable approach. hv.Text can then be introduced as a simple convenience wrapper for Labels...

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.