Symbol display in new system

[danbalogh]

I'm moving the discussion of symbol display to a new topic from #421 .

Symbol display content

The desired display is as follows, in decreasing order of priority. This summary supersedes all previous discussions of symbol display (point 4 was slightly different in #421 , but otherwise this is the same as before).

1. display the mapping. This is the preferred display.
2. if and only if mapping is not available (because no ref on the g, token not found, or no mapping for the token), display the name. This is for symbols for which we chose not to create a mapping equivalent.
3. if and only if neither mapping nor name are available (because no ref on the g, or token not found), display the content of the <g>. This is the fallback option for cases where somebody did not care to add a reference to the authority file, or when they used an incorrect token.
4. if and only if neither of the above three are available (because the g is empty), display the default placeholder corresponding to the value of @type. This is the legacy option for symbols encoded according to old rules (or incorrectly). The default placeholders are:

• symbol (or no explicit @type): * (asterisk)
• punctuation: . (full stop)
• connector: § (section sign)
• ideogram: @ (at sign)

The current display seems to display * whenever neither mapping nor name are available. See the attached screenshot. (I don't seem to have write access to the test folder so instead of the gaiji test file I used one of my own editions as a scratchboard)

Cases where the display is not what is desired have a comment highlighted in yellow.

Symbol display tooltips

I'm happy with the tooltips as they are now. @arlogriffiths , if you want to test them, you can click the link to my scratchboard edition above and see what tooltips show.

Symbol display styling

I'm happy with the angle brackets added when the name of a symbol is displayed, because they are copy-pasteable, so symbol names won't be mistaken for text when the displayed text is copied to another environment.
I have a feeling that we may need to highlight symbols more, perhaps with a background colour. I'm not sure if this is necessary and not sure what would be best, so suggestions are welcome. Two main reasons for this feeling. 1: some of the symbol displays will be very small (e.g. the default placeholder . as well as some of the present mapping characters) and highlighting them may make the end user more aware that they are not just a flyspeck but something that may be worth pointing the mouse at. 2: some of the mapping characters may be mistaken for something else. In particular, mappings for circle symbols are identical or similar to the display of binding holes. This might be eliminated by changing the binding hole display (e.g. to "◌" (U+25CC) Dotted Circle or to "⍜" (U+235C) APL Functional Symbol Circle Underbar)) or, if unavoidable, changing the circle symbol mapping to something else. But other unforeseen resemblances may come up later, so it would probably best to disambiguate symbols in some visible way. Ideas?

[michaelnmmeyer]

The current display seems to display * whenever neither mapping nor name are available.

This is because, when @ref is not supplied, it defaults to unclassified, which has the mapping * in the authority file. If you set a non-empty @ref with some invalid reference, you will see that the contents of <g> is displayed.

[danbalogh]

Okay, I see. But we need a solution, not an explanation. We could delete the mapping for unclassified, but then it still has a name. Would deleting both the mapping and the name lead to a solution, or would it only cause more problems? If the latter, how to achieve the desired display?

[michaelnmmeyer]

What makes the most sense to me would be to remove the whole unclassified record from the authority list.

[danbalogh]

If we removed that entry from the authority list, would it still be possible for the tooltip associated with symbols encoded without @ref to show something along the lines of the present "unclassified glyph – a glyph that has not been classified, usually because it is indistinct, or because no visual documentation is available"? If yes, then I think we should go ahead and remove it. In fact, if the tooltip can revert to a default, it would be best to include the @type in this tooltip, i.e. "unclassified punctuation mark", "unclassified connector mark" etc. defaulting to "unclassified symbol" when there is no @type. If this can be done, then let's go this way. There is no need for "usually because it is indistinct, or because no visual documentation is available" in the tooltip.

[michaelnmmeyer]

I have removed unclassified from the taxonomy. The processing code is finished (and this also applies to images).

[danbalogh]

OK, thanks. I'm still seeing asterisks and the old tooltips in my test file and your gaiji test file, but I assume it just takes time for the processing code to trickle through, so I'll check back later.

I don't understand what you mean about images.

[michaelnmmeyer]

For images, I mean that I finished the rendering stuff to display images within a separate section that can be folded up/down.

[arlogriffiths]

Only responding to this for now:

Symbol display styling

I'm happy with the angle brackets added when the name of a symbol is displayed, [...]

I am happy too!

I have a feeling that we may need to highlight symbols more, perhaps with a background colour. I'm not sure if this is necessary and not sure what would be best, so suggestions are welcome. Two main reasons for this feeling. 1: some of the symbol displays will be very small (e.g. the default placeholder . as well as some of the present mapping characters) and highlighting them may make the end user more aware that they are not just a flyspeck but something that may be worth pointing the mouse at. 2: some of the mapping characters may be mistaken for something else. In particular, mappings for circle symbols are identical or similar to the display of binding holes. This might be eliminated by changing the binding hole display (e.g. to "◌" (U+25CC) Dotted Circle or to "⍜" (U+235C) APL Functional Symbol Circle Underbar)) or, if unavoidable, changing the circle symbol mapping to something else. But other unforeseen resemblances may come up later, so it would probably best to disambiguate symbols in some visible way. Ideas?

I recommend limiting display formating to what we have now (the purple color), and waiting with further fiddling until the whole system is fully operational.

If Ø isn't yet taken, it might be an option for binding-hole.

[danbalogh]

@michaelnmmeyer : great, I'll test the image thing at some point. However, I still see asterisks in each case where there is no ref, while what we want is a placeholder depending on @type as per item 4 in the opening post.

@arlogriffiths : then let's keep styling as is for now and come back to it only if found necessary. In that case modifying the binding hole display would probably be a good idea. Ø is not taken afaik; I slightly prefer ⍜ because it alludes to the underscore=space equivalence, but it is probably not widely supported by fonts.

[danbalogh]

@michaelnmmeyer re images: I don't see a folder project-documentation/website/glyphs/. Where shall we store our images? I'd like to upload some for testing.

[michaelnmmeyer]

@danbalogh You can create a folder "glyphs" and put there the images.