Supporting html labels

[drahnr]

Hey, thank you for writing the crate. I am currently working with an svg generation library that makes use of html like labels (https://graphviz.org/doc/info/shapes.html#html) which this crate does not support just yet.

Would you be interested in accepting a PR for support?

[nadavrot]

Thank you for reaching out. This feature is indeed missing. Can you tell me more how you plan to implement this feature?

[drahnr]

My initial idea would be to add < and > as bracket like enclosings, and using the content inbetween as input to either https://crates.io/crates/hard-xml or https://crates.io/crates/xml-rs and defining all supported items manually.
Text is natively supported in SVGs: https://developer.mozilla.org/en-US/docs/Web/SVG/Element/text

Rendering tables is the most tricky part, so I'd punt on that for now, https://tink.uk/accessible-svg-tables/ outlines a path to get there, but it requires a few more moving parts, i.e. how to size the table elements - I am not yet sure if one can avoid to do text and glyph placement to obtain i.e. the width of a column.

[mert-kurttutan]

@nadavrot working on this feature.
But, there is public api that needs to change AttributeList needs to have a new type for its list field Vec<(String, String|HtmlString)>.

How OK are you with this change that introduces API breakage?

[azriel91]

@mert-kurttutan Speaking for myself, I would be very happy to accomodate a breaking change for that functionality.

Also, if I may influence how you build it -- even if the input syntax is html-like, could you design the internal data structure such that, if a future syntax were to take markdown as label input, then the internal model would support the markdown as well.

[mert-kurttutan]

@azriel91 I can definitely do that. The main data structure for this support is the following

#[derive(Debug, Clone)]
pub enum DotString {
    String(String),
    HtmlString(HtmlString)
}

where HtmlString is the html-like text according to specs.
The support for markdown on the side of parser would be to add another variant MarkdownString with its own parser function.

Regarding how the parser would work, we might need another token to indicate that it is markdown, like <htmlstring> is for html. We might do **MarkdownString** for instance.

Of course, we would going with our specs for markdown since there is no official one in dot langauge.

If we want to include this as part of public api, we better make it non-exhaustive enum so that future inclusion of markdown is not an API breaking change.

[azriel91]

Oh yes, I was also thinking the layer beneath -- as in if there's an intermediate representation that both the HtmlString and MarkdownString transform into, then the logic for layout can be shared (e.g. the <table> becomes struct Table, and markdown -> html -> struct Table).

That said, I think I'm just imagining a more complete set of elements taken from HTML, and both HtmlString and MarkdownString fulfilling some portion of them, and if possible including class=".." so they can be styled using CSS instead of SVG attributes.

Anyway that's just imagination; I'd hate to set myself up as "ideas-guy" who didn't actually contribute anything.

[mert-kurttutan]

The idea of IR to support Markdown and HTML sounds nice. My 1st attempt for html is close to the structure of html since there is a precise spec that I could follow.
Let me complete the html first, then I will see how this IR might look like