GNOME Bugzilla – Bug 100476
Keycap rendered incorrectly in bold
Last modified: 2004-12-22 21:47:04 UTC
When the keycap tag is used with keycombo, the text is rendered as normal text. This is correct. When the keycap tag is used alone it is displayed in bold. This is in correct.
Created attachment 12788 [details] Test file for comparison of keycombo and keycap
I think the mistake is the keycombo should be bold and the keycap is correctly bolded. The keycombo and keycaps need to be set apart from the text because it is an instruction to the user to press a certain key or sequence of keys. The boldness lets the user easily reference which keys should be pressed. I have also made a test file so the two can be compared side by side.
Created attachment 12789 [details] [review] Patch for yelp-custom.xsl to fix keycombo inconsistency.
I agree, the docbook.org website has it defined as bold too http://docbook.org/tdg/en/html/keycap.html
so just to clarify - *both* should be bold ?
The reason I went for normal formatting rather than bold formatting was because in some places I list many keycombos/keycaps in table format (see Desktop > Basic Skills > Keyboard Skills). In this case, I felt that bolding would be an eyesore. But I don't feel very strongly about it, I see Eric's point too. As long as individual keycaps and keycaps in keycombos are rendered consistently, I'm happy.
The patch suggested by Eric just removes all <keycombo> customization. This customization was there for a reason: it replaces "-" used to join keys by "+", so it becomes, e.g. Alt+F1, not Alt-F1 (at some moment, it was decided that + looks better). I am attaching a different patch which keeps the customization and fixes it so that now <keycap> is bold both in <keycombo> and outisde of it.
Created attachment 14403 [details] [review] patch to fix keycombo tag
Hmm .. which one is the one we want?
We should apply Alexander's patch. As he points out, the custom template changes the default joinchar from "-" to "+". However, this custom template has another difference from nwalsh's template. It effectively only apples templates to the keycombo's grandchildren, bypassing any formatting that the stylesheets would do to tags like keycap. Alexander's patch fixes this. Also, Alexander's patch should be applied regardless of how we want keycaps rendered. The current stylesheet doesn't even allow children of keycombo to hit a template. If we want to override what keycombo children are formatted, we should explicitly override templates for tags like keycap, rather than just preventing them from being processed. Note that if we would like keycombos and keycaps not to be bolded when listed in a table, I can add that customization in while still leaving them bold if they occur inside normal text.
Alexander's patch has been committed to Yelp HEAD and to gnome-docu/gdp/xsl in CVS. Do we want the keycap and keycombo tags to be bolded in tables as well?
Keycap and keycombo tags should be formatted consistently wherever they are located. If keycap and keycombo tags are rendered in bold in body text, then I think they should also be rendered in bold in tables. I think the consistency of how they are rendered is more important than avoiding the minor visual problem of a lot of bold in a table. So I don't think we need to apply the customization that Shaun suggests.
All right, so this can go three ways: - keycap is always bold (current behavior in HEAD) - keycap is never bold - keycap is bold, except when in a table For reference, I'm attaching two patches for the second two cases. However, I think we should stick with the current behavior.
Created attachment 18117 [details] [review] Make keycap bold iff it is not in a table
Created attachment 18118 [details] [review] Make keycap never bold.
Closing on request of Shaun. Thanks.