Community
Participate
Working Groups
First I would like to thank you for the nice product that you are developing here. I'm in the process of testing ZEST and assessing its capabilities to see if it has all the features we need and if it will incorporate in our product correctly. Hopefully dot2zest is out there and makes zest a good candidate. The only missing piece right now, is the ability to specify HTML labels in the dot language as we have some graphs that needs this to render correctly. I would like to know if there's any plan to integrate those ? If not can you please give some hints on the efforts needed to do such integration. Thanks
(In reply to comment #0) Adding support for HTML-like labels would probably not be trivial, but I agree it would be a very useful feature. It would basically involve two things: First, our DOT grammar would need to support the special syntax for HTML-like labels in the DOT language (see http://www.graphviz.org/doc/info/shapes.html#html). Second, when the Zest graph is generated from the DOT input, the very flexible layout possibilities of the HTML-like labels (in particular tables) would have to be mapped to custom figures (see http://eclipsesource.com/blogs/2009/03/20/just-in-time-for-eclipsecon-custom-figures-in-zest/). Michael, I CC'ed you in case you have time and would like to implement the grammar part.
See also bug 337640 for record syntax (would require the same custom figures).
*** Bug 372815 has been marked as a duplicate of this bug. ***
At EclipseCon Europe 2014, Sebastian Zarnekow has demonstrated what can be done to embed parsers for other Xtext languages into a host Xtext language (https://www.eclipsecon.org/europe2014/session/xtext-polyglot-world). The demo example showed how a regular expression Xtext-language was integrated into a javascript Xtext language. I am not sure, but maybe the same mechanism should/would be required here.
As far as I understand from a brief look into the docs, html labels are delimited by '<' and '>' which makes a nice terminal if (and only if) the '<' is not used somewhere else in the dot syntax. If '<' is used somewhere else, too, you'll have to provide a real grammar for the HTML stuff. But given that only a subset of HTML seems to be supported, I'd rather provide a real grammar for that - possibly a generic version that does not enumerate the valid HTML tags/attributes but uses only IDs. Content assist / validation could be customized and the syntax wouldn't be polluted with keywords.
(In reply to Sebastian Zarnekow from comment #5) > As far as I understand from a brief look into the docs, html labels are > delimited by '<' and '>' which makes a nice terminal if (and only if) the > '<' is not used somewhere else in the dot syntax. If '<' is used somewhere > else, too, you'll have to provide a real grammar for the HTML stuff. But > given that only a subset of HTML seems to be supported, I'd rather provide a > real grammar for that - possibly a generic version that does not enumerate > the valid HTML tags/attributes but uses only IDs. Content assist / > validation could be customized and the syntax wouldn't be polluted with > keywords. Thanks for your comment, Sebastian. Unfortunately, I have to admit that I don't fully get your point. As far as I can see, '<' is not used somewhere else in the DOT language (only '>' is used within the '->' edge operator). That should make it a 'nice' terminal. But we would have to specify a terminal rule to properly parse it in any case, wouldn't we? So I don't really understand what you mean with 'nice' terminal. And what do you mean with 'real grammar'? Would that be an integrated standalone grammar as outlined in your polyglot example? Or would it mean an augmentation of the already existing grammar with additional parser rules?
(In reply to Alexander Nyßen from comment #6) > [..] > As far as I can see, '<' is not used somewhere else in the DOT language > (only '>' is used within the '->' edge operator). That should make it a > 'nice' terminal. But we would have to specify a terminal rule to properly > parse it in any case, wouldn't we? So I don't really understand what you > mean with 'nice' terminal. Yes, you would have to specify a terminal rule, that calls itself recursively, e.g. smth like (incomplete pseudo code): GraphizID: ID | '<' (!'<'|GraphizID)* '>'; The problem with that approach is that the lexer does not do any nice error recovery so it is likely to cause a bad user experience with broken input files. > > And what do you mean with 'real grammar'? Would that be an integrated > standalone grammar as outlined in your polyglot example? Or would it mean an > augmentation of the already existing grammar with additional parser rules? By real grammar I was refering to a data type rule for the ID. This would allow the parse to handle the ID and that will do error correction and all the nice gimmicks.
We already have such an ID rule in our grammar: http://git.eclipse.org/c/gef/org.eclipse.gef4.git/tree/org.eclipse.gef4.dot/src/org/eclipse/gef4/internal/dot/parser/Dot.xtext So your recommendation would be to enhance the existing grammar to properly handle html-like label IDs?
Yes, I'd recommend that. The HTML stuff shouldn't hardcode all the allowed tags but rather use just plain IDs. I'd go with customized content assist and validation to keep the grammar simple. Giving it another thought, if you wouldn't use a data type rule but a plain parser rule, you could use cross references for the closing tags. The customizing would be even simpler. From the top of my head, this could be smth like the following grammar snippet: NodeID: PlainID | HtmlID; PlainID: value=NodeIDImpl; NodeIDImpl: /* what currently is node id */; HtmlID: '<' html=HtmlTag '>' HtmlTag: '<' name=ID attributes+=Attribute* (shortCut?='/' '>' | '>' children+=HtmlTag* '<' '/' closes=[HtmlTag] /* always itself */ '>');
I have taken a look at the grammar side of this issue and fear that we may need to introduce a custom lexer to handle this properly, because the dot primitives and the XML tag/attribute names and attribute values might result in conflicting terminals. I will try to investigate this further but am not sure whether this is something that can resolve for 1.0.0 (Neon).
I make some progress here. Parsing of HTML strings should now be possible in the DOT host grammar: - Created a custom lexer which corretly handles tokenizing for HTML strings. - Adjusted DOT parser to handle HTML strings. - Added sample graph with HTML-like lables to parser tests. Next, we will have to add a value converter for them (see bug #507413) and we have to enable parsing of HTML within label attributes.
Adding attribute parser for lblString is the next thing that is required here: bug #508830.
I pushed the following changes to origin/master: [321775] Improve the syntax highlighting of DOT HtmlLabel sub-grammar. - Extend the DotHighlightingConfiguration with different style definitions for each html element: htmlTagStyle(), htmlAttributeNameStyle(), htmlAttributeEqualSignStyle(), htmlAttributeValueStyle(), htmlContentStyle(), htmlCommentStyle(). - Implement DOT HTMLLabel highlighting logic in the DotHtmlLabelSemanticHighlightingCalculator. - Modify the DotSemanticHighlightingCalculator to make use of the DotHtmlLabelSemanticHighlightingCalculator (via a general DotSubgrammarHighlighter implementation). - Implement corresponding DotHighlighting and DotHighlightingCalculator test cases.
I pushed the following changes to origin/master: - Extend the DotHtmlLabelProposalProvider to provide content assistant support for the tag names and their attributes. - Implement corresponding content assistant test cases.
The following changes are published on the origin/R5_0_0_maintenance and origin/master branches: [321775] Allow parsing Dot Html-Like-Label comments in Html tags. - Modify the DotHtmlLabel grammar to send the HTML_COMMENT elements nested in a HtmlTag to the hidden channel. - Implement corresponding DotHtmlLabelTests parser/validation test cases. Example1: <TABLE> <!-- HTML comment--> <TR> <TD>left</TD> </TR> </TABLE> Example2: <TABLE> <TR> <TD> left <!-- HTML comment 1 --> <!-- HTML comment 2 --> right <!-- HTML comment 3 --> </TD> </TR> </TABLE>
The following changes are published on the origin/R5_0_0_maintenance and origin/master branches: [321775] Improve Dot Html-Label attribute value validation support. - Extend the DotHtmlLabelJavaValidator by attribute value validation rules. - Implement corresponding validation test cases.
The following changes are published on the origin/R5_0_0_maintenance and origin/master branches: [321775] Improve Dot Html-Like-Label folding support. - Provide a custom DotFoldingRegionProvider where the folding regions for the dot HTML-Like-Label attribute value are computed as well. - Modify the Dot HTML-Like_Label folding not to calculate the folding regions for html content elements containing only whitespaces. - Implement corresponding DotFoldingTests test cases.
The following changes are published on the origin/R5_0_0_maintenance and origin/master branches: [321775] Improve Dot Html-Like-Label outline view support. - Extend the GenerateDot.mwe2 workflow to generate labeling/outline API for the DotHtmlLabel.xtext sub-grammar. - Provide implementation for the DotHtmlLabelLabelProvider and DotHtmlLabelOutlineTreeProvider classes. - Provide html_tag.png and html_text.png icons used by the outline view. - Modify the DotLabelProvider and the DotOutlineTreeProvider to consider the DotHtmlLabelLabelProvider and the DotthmlLabeloutlineTreeProvider implementations when creating the outline view. - Implement corresponding DotOutlineViewTests test cases.
We should note that when the shape "record" or "Mrecord" is set, mixing HTML label and record shape is possible. We would need to check how ports are named in this situation. (i.e. double use of '<' and '>'.) At the moment this behaviour seems almost undocumented - but could be inferred from the documentation at http://www.graphviz.org/doc/info/shapes.html#html > Although HTML labels are not, strictly speaking, a shape, they can be viewed as > a generalization of the record shapes described above. In particular, if a node > has set its shape attribute to none or plaintext, the HTML label will be the > node's shape. On the other hand, if the node has any other shape (except point), > the HTML label will be embedded within the node the same way an ordinary label > would be. An example would be: graph { struct3 [label=<{<TABLE><TR><TD>HTML label</TD></TR></TABLE>|{<B>but </B>|this works just fine}}> shape=record]; }
The current grammar allows an HTML label <<TABLE>...</TABLE><TABLE>...</TABLE>...> > HtmlLabel: (parts+=HtmlContent)*; This is not permitted by the graphviz grammar (and results in a syntax error in Graphviz). > label : text > | table I.e. there can't be text and table or multiple tables in one label.
Hello Zoey, thanks for the hint. I pushed the following changes on the origin/R5_0_0_maintenance and origin/master branches to address the issue you have been described: [321775] Add checkSiblingsAreValid() DOT Html-Label validation rule. - Ensure that the DOT Editor reports validation failures in case of invalid HTML siblings: the graphviz DOT HTML-Like Label grammar does not allow text and table or multiple tables on the same (root or nested) level. - Implement corresponding DotValidatorTests and DotHtmlLabelTests test cases.
I pushed the following changes to origin/master: [321775] Improve the Dot HTML-Like Labels grammar definition. - Allow double quoted text in DOT HTML-Like Labels text (no tag mode). - Allow single quoted attribute values in DOT HTML-Like Labels tags (tag mode).
I pushed the following changes to origin/master: [321775] Improve the Dot html label validation/content assistant. - Allow the html <TABLE> tag inside the <B>, <I>, <O>, <U> tags. - Implement corresponding test cases.
GitHub Pull Request 14 created by [prggz] https://github.com/eclipse/gef/pull/14
Thanks for your contribution, Zoey! I merged your Pull Request into the origin/master branch.
Regarding the align/valign tags, I have oppened issue https://gitlab.com/graphviz/graphviz/issues/1393 as the documentation is inadequate and behaviour appears unintuitive/unexpected (if consistent), especially for the attributes set in combination with width/height settings on table tags.
GitHub Pull Request 20 created by [prggz] https://github.com/eclipse/gef/pull/20
GitHub Pull Request 21 created by [prggz] https://github.com/eclipse/gef/pull/21
Thanks Zoey, I merged your Pull Request into origin/master.
GitHub Pull Request 23 created by [prggz] https://github.com/eclipse/gef/pull/23
GitHub Pull Request 24 created by [prggz] https://github.com/eclipse/gef/pull/24
GitHub Pull Request 25 created by [prggz] https://github.com/eclipse/gef/pull/25
Created attachment 276185 [details] Visual representation of HTML-table colspan issue We currently experience an issue with rendering of tables with multiple cells that use colspan. The width calculations are currently run using layout bounds of the gridpane. These calculations do not result in the right results in this case (the extra width of spanning cells is accounted for more than once, hence making the node too large). I have not found a solution to this and or whether this originates from our code. I have analysed the issue and provided a pdf file which visualises and explains the problem.
Created attachment 276186 [details] Simplified example with two colspan values Related to attachment 276185 [details] and comment #33. This dot file should be able to show the issue if opened in DOT Graph view. Issue encountered running Windows 10 and Oracle jre 1.8.0_171.
GitHub Pull Request 27 created by [prggz] https://github.com/eclipse/gef/pull/27
GitHub Pull Request 29 created by [prggz] https://github.com/eclipse/gef/pull/29
I currently identified some differences when rendering DOT Graphs containing HTML-like labels. Please find the attached graphgenerator.png screenshot and the attached graphgenerator.dot file.
Created attachment 280378 [details] screenshot representing the differences betwenn Graphviz and GEF DOT rendering
Created attachment 280379 [details] graphgenerator.dot file
Hi Tamas, Thank you for the comment and the attachment. In the picture, I see three main issues: 1. The node size calculation for HTML-like labels is not ideal, which is why there is free space between the arrows beginning and the labels. This is being worked on. 2. There is an issue with Padding (probably related to the above), this is marked as TODO in the relevant source file. 3. There is an issue with alignment of centered headings. There is a TODO for cell alignment, which is not fully implemented. This is also because in this instance, graphviz itself appears to contain a bug (see comment #26). It could also be related to comment #34. Currently, there is a implementation to rework HTML-like label visualization (not the JavaFX node that is displayed) being worked on. This is to include all occurrences of HTML-like labels and not just Node Labels. This also includes a solution for surrounding shapes and revised size calculations. We should reinvestigate issue 1 at that point. Issue 2 is open. I would suggest issue 3 should be revisited after the implementation changes above have been merged into master, as there has been some changes to the classes and I would rather not introduce changes in the old code. There is some indication though, that it may not fix soon. Is there any other issue that I am missing?
Note to future self: We need to adapt/check unquotedValueForAttr method in HtmlJavaFxNode to also consider quoting using ''.
I pushed a commit fixing the issue (see comment #41 directly above) regarding single quotes in Html Like Label visualization. [321775] Fix handling of single quotes in HtmlLabel visualization -fix DotHTMLLabelJavaFxNode.unquotedValueForAttr(HtmlAttr) Signed-off-by: zprigge <zprigge@itemis.com> Bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=321775
Yesterday, I pushed the following changes to the master branch. [321775] Rework Ui Visualization of Html-like labels -create new DotHTMLEdgeLabelPart to display HTML-like node tail/head/external labels -create new DotHTMLNodeLabelPart to display HTML-like node external labels -create new DotHTMLNodePart to display HTML-like node labels -adapt DotNodePart.java to differentiate between HTML-like and other node labels -register in DotContentPartFactory -create new DotProperties to include all DotProperties including new HTML-like label properties -rework Dot2ZestAttributesConverter to consider styled texts and include relevant html-like label dot properties, no longer treat html-like label as node shape -add new TODO in Dot2ZestGraphCopier (Clusters) -change HTML color calculation to use Color instead of String (DotColorUtil) -adapt DotHTMLLabelJavaFxNode, split FontStyleContainer and TagStyleContainer into seperate classes -create DotNoneShape and include/use in DotPolygonBasedNodeShapes -adapt Dot2ZestEdgeAttributesConversionTest -adapt Dot2ZestGraphCopierTest -adapt Dot2ZestNodeAttributesConversionTest Signed-off-by: zprigge <zprigge@itemis.com> Bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=321775
I will resolve this as fixed in 5.3.1 (2020-09), since most of the functionality already have been implemented. Further improvements should come in separate Bugzilla tickets.
