Display Variable Names Better in LaTeX

[samm82]

Variable names with "words" (like "offset") shouldn't be displayed in italics and with proper kerning in LaTeX (using \mathit{} or \text{}), possibly using a new constructor for Symbol.

[samm82]

What other "phrases" should be displayed like this? "max" and "min" jump out at me. @smiths

[samm82]

Also, is the HTML display OK?

[JacquesCarette]

To get this right, we will indeed need to change Symbol to have some kind of "word" constructor that says that something is a 'thing' instead of a variable.
We might need more than one -- to me land and target are quite different in kind than max and min.

[samm82]

You mentioned on a commit that we should be capturing semantic information; what information should we be capturing and how?

[JacquesCarette]

Shoot, it has now been too long, and I don't remember -- and the commit wasn't linked!

[samm82]

b7582bb#commitcomment-34128032

[JacquesCarette]

Thanks, that helped.

The idea is to find a common theme to the subscript. land and target are domain "objects" (for example). min and max are (abbreviations for) specific concepts. At other times, the subscript is the name of a variable (quantity) of interest.

In the first two cases, I think we want to display those in Romain, while in the latter, in the usual Math font.

If I had to take a guess, I'd say that the separation is that the land and max cases are tied to pure concepts, while the latter are tied to quantities. But we'd need more examples to figure out a better classification scheme.

[smiths]

I like the idea of @JacquesCarette to decide the formatting based on the semantic information, but I think we shouldn't invent any rules. We should follow the standard typographic conventions, as summarized at:

https://en.wikipedia.org/wiki/Typographical_conventions_in_mathematical_formulae

These rules say that italic font is used for variables and upright font for everything else. This rule applies for subscripts and superscripts as well. The example at Wikipedia is $h_\text{i}$ for initial height. The $h$ is in italics because it is a variable. The i is in non-italic font because it is a designation, not a variable. On the other hand $h_i$ is used for one instance from a sequence of heights. In this case both the $h$ and the $i$ are variable.

By these rules, I think land, target, min and max would all be in non-italic font. I wouldn't say Roman, since that is not part of the convention. I would just say non-italic. If the subscript is a variable, then we would use an italic font.

My original motive for asking @samm82 to create this issue was simply to get the subscripts (and superscripts) to look better. The default spacing, where LaTeX thinks it is multiplying a bunch of single letter variables, is distracting.

[JacquesCarette]

Good find - we should indeed go with those rules.

[samm82]

How would we differentiate between a variable and a non variable? Rename the Roman constructor to Upright? Roman was meant for symbols that should be upright, but apparently "roman" is the wrong name for them. My original thought was to assume that any single character would be italic and everything else would be upright, but the example on Wikipedia shows that the same single character can be a variable and a non-variable.

[JacquesCarette]

Neither Roman nor Upright are correct - the problem is not one of display, it is one of semantics. We need to differentiation (roughly) between Variable and Symbol (or Name or Label) at a higher level. And that will trigger a later difference in display.

[samm82]

I think ShortHands should use Var, and then if we need a Label, we'd built it, correct?

[samm82]

Should ShortHands have a short hand for Var and Label, or should it not be used at all? @JacquesCarette

[smiths]

Neither Roman nor Upright are correct - the problem is not one of display, it is one of semantics. We need to differentiation (roughly) between Variable and Symbol (or Name or Label) at a higher level. And that will trigger a later difference in display.

I definitely agree with @JacquesCarette's comment from above. Some symbols are variable, and some are not. That is the distinction that matters. We do not want to impose Roman font, since someone may use another font for their equations. What we want is to put whatever font it is in italic mode, when the symbol is a variable. This would only be done at the point of display.

@JacquesCarette is better to answer your question, but I have a suspicion that we do not currently have the semantic information that we need in Drasil equations. We might know that some things are variables, but I'm pretty sure that for some of the labels that we use for subscripts, we don't really know. I do not know the best approach here, but my instinct is that the default for subscripts and superscripts is that they are usually not variables.

[JacquesCarette]

I don't understand your "Should ShortHands have ..." question. Can you provide some examples for context?

[samm82]

Before, ShortHands had every letter as Atomic, which just meant "display this character". Now, letters can be Variables or Labels, as mentioned above by @smiths from Wikipedia:

The example at Wikipedia is $h_\text{i}$ for initial height. The $h$ is in italics because it is a variable. The i is in non-italic font because it is a designation, not a variable. On the other hand $h_i$ is used for one instance from a sequence of heights. In this case both the $h$ and the $i$ are variable.

Should ShortHands define each letter as a Variable, as a Label, or have a version of each, like below?

varLK = Variable "k"
labLK = Label "k"

I'm wondering if this is related to the "hardcoding" you mentioned in this comment, @JacquesCarette.

[JacquesCarette]

I totally didn't get that ShortHands was referring to a file... a full path would have helped.

I think we only want short-hands for single-letter variables. Labels should be application-specific names, and should not occur in drasil-lang at all.

In particular, "x, y, z" from that comment might be defined in drasil-data along with where we define Cartesian coordinates, but not deeper than that.

[samm82]

Should I just define the symbols themselves, or should I define the helper functions to add them as a subscript? If so, would utils be a good place for them?

[JacquesCarette]

Defining the 3 symbols x, y, z might go in data-drasil under Physics.3DCoordinates or something. They shouldn't be 'too global'. I'm still not sure about special functions for adding them. I think we'll want to take a more global view of this first.

[samm82]

For now, until we think about this more, would it be OK for me to just move the helper functions (subX, etc.) to Quantities.Physics?

[JacquesCarette]

That would already be better, yes.

[samm82]

I think there's an issue where the symbols are being printed through pExpr instead of symbol. I just realized this now, the code for Label in pExpr doesn't actually use \\text:

symbol :: L.Symbol -> String
symbol (L.Variable s) = s
symbol (L.Label s)    = s

but the code for Label (which I think I erroneously added the case for) does:

pExpr :: Expr -> D
...
pExpr (Row [x])      = br $ pExpr x -- FIXME: Hack needed for symbols with multiple subscripts, etc.
pExpr (Row l)        = foldl1 (<>) (map pExpr l)
pExpr (Ident s)      = pure . text $ s
pExpr (Label s)      = command "text" s

where Row functions as Concat (I think).

[samm82]

Found the cause; this function in Printing.Import converts Symbols (from -lang) to Expr (from -printers). Is this desired? My guess is not. @JacquesCarette

symbol :: Symbol -> P.Expr

[JacquesCarette]

Where does that code in your message (i.e. the listings for symbol and pExpr come from? Unfortunately, depending on the file, a similarly named routine will have a different purpose, and that purpose will let me know whether these changes are correct or not.

Printing.Import is supposed to convert from the stuff in -lang to the data-structures in -printers. So at that level, everything is as expected. And P.Expr has font information in it, so if the translation is done correctly, it should all be fine.

So could you give a concrete example of something in an example that is somehow coming out 'wrong', because of the above code? Your report is too incomplete (i.e. there's too much information that's still in your head instead of in the report) for me to really understand the real problem you're seeing.

[samm82]

Sorry for the lack of information. This is definitely a different issue than this one, so I created one here: #1756. Let me know there if you need anything else 😊