On Sat, Jan 01, 2022 at 03:13:15PM -0700, Karl Berry wrote: > I found an inconsistency in the HTML output in the output for @key, > depending on whether it was in @kbd or not. It would be slanted only > if inside @kbd. > > Certainly that was an intentional feature, not a random "inconsistency". > > Maybe @key should use the same font as @kbd, rather than always the > upright font, which seems to be what you've implemented now? > > This relates to @kbdinputstyle. rms instigated that "different font" > (slanted for typewriter) for @kbd, back in 1997. See ChangeLog.46 and > texinfo.texi for that. The stuff about @key should be in the ChangeLogs too.
I'm not surprised the issue goes back a long way. As far as @kbdinputstyle is discussed in the manual it doesn't say exactly what the effect on @key is, only for @kbd. There seemed to be a general feeling in the 2018 discussion I linked to that consistently unslanted fonts are good for @key. I imagine the effect of @kbdinputstyle would continue for the rest of the contents of a @kbd command, but not have the effect on @key commands which were inside. I found this old ChangeLog entry: Sun Jan 28 21:14:46 1996 Richard Stallman <[email protected]> * texinfo.tex (\key, \kbdfoo): Use \ttsl unconditionally. (\setkeyfont): Definition deleted. but since then @key has stopped being unconditionally slanted (I didn't find out when this was). > > If/Since you are going to undo all that, fine by me, but I suggest > 1) to be sure and update the manual with whatever users are supposed to > do to get , and > 2) it would seem strange to me for HTML and PDF/DVI output to behave > differently, which is what you seem to have implemented. Or maybe not, > I can't really tell. I hadn't checked the PDF/DVI output, but doing so, I see the output had been consistent with what was being done in HTML. I propose that this is also changed for PDF/DVI output to unslant @key inside @kbd.
