Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Supporting HTML-like labels #2

Open
kchanqvq opened this issue May 24, 2022 · 2 comments
Open

Supporting HTML-like labels #2

kchanqvq opened this issue May 24, 2022 · 2 comments

Comments

@kchanqvq
Copy link

The relevant section of the grammar specification can be found at the newest https://www.graphviz.org/doc/info/lang.html:

An ID is one of the following:

Any string of alphabetic ([a-zA-Z\200-\377]) characters, underscores ('_') or digits([0-9]), not beginning with a digit;
a numeral [-]?(.[0-9]⁺ | [0-9]⁺(.[0-9]*)? );
any double-quoted string ("...") possibly containing escaped quotes (")¹;
an HTML string (<...>).

I think we just need to update format-id, but I'm a bit unsure about what's the best interface. E.g. how to tell if the user intend a string to be printed as double-quoted string or HTML string?

@jingtaozf
Copy link
Owner

jingtaozf commented May 28, 2022

@BlueFlo0d Thanks for your note.
I think we can check the type of id, it can be an atom or cons, and if it is cons, the car can be the ID type (for example, :single-quote, :double-quote, :html, etc).

A pull request to support a full feature ID is very welcome.
https://www.graphviz.org/doc/info/lang.html

@kchanqvq
Copy link
Author

Re using type of id: yes it makes sense! And such syntax is very Lispy, I like it.

Apologies for the delayed response, I recall last time I was working on this, I tried to use spinneret (an HTML generator in Lisp) so user can write the HTML using S-expr. It was a disaster — Graphviz turns out to require a “fake” HTML that differs from standard HTML in subtle ways (e.g. use of quoting)… maybe for now we could just let user pass in a raw HTML string and output it verbatim. To support full S-expr we'd need to implement this grammar as well, which could be a future goal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants