RFD: Formatting of chords #informational #needinfo

Johan Vromans

In a response to issue #13, user rustianimal wrote the following comment:

This is an incredibly powerful thing to have. In Graphic User Interfaces, designing a system to work effectively for the eyes is extremely important. When we read, we do not read the individual characters in a word, but the outline shape of the word. This is critical to speed reading where people are specifically taught to ignore vowels and many other characters and focus on the shape of words. In fact it is possible to take out pretty much all vowels and quite a lot of other characters and still make perfect sense of the sentence.

To prove the point, convert the whole of the above paragraph to capitals and then try to read it. This is exactly what the chord shapes in the current version of ChordPro are like. If you have any form of reading difficultly (as I have), it is almost impossible to distinguish the chords from the lyric, even when using colour. What makes an absolutely MASSIVE difference using superscript and subscript in the chord description as has been the case on sheet music for decades.

It is time that ChordPro got itself up to date and became supportive of those with visual and learning impairments by putting the tools in place to support them. I would propose the not just the options described above, but to also allow substations such as ^4 instead of 'sus' and to subscript 'm' and 'M' for minor or major chords.

Supporting standard html methods for this would enable would open up the versatility of the ChordPro standard to allow custom chord conversions to assist those like me who NEED this kind of formatting to be able to play in a live context. Without this functionality, there is no option but for me to stick with traditional paper and ink.

I took the liberty to use rustianimal's comment as a starting point for a new discussion. Please participate.

Points to consider:

  • Currently, you can put anything you like between the [...] pairs. It will be rendered using the style associated with chords. People use this for annotations like [Coda] and [Rit.]. Only when it is required to know the chord the content between [...] is interpreted: for transposition and to look up the chord diagram for printing. Straightforward tools will happily transpose Coda to Doda; that's not what we want.
    As of ChordPro version 6 a leading asterisk can be used to tell ChordPro that this is not a chord, e.g. [*Coda].

  • When you want to fancy-format a chord, you need to know what the chord is. This restricts the usable chords to built-in and user defined chords.

  • As for the formatting, there are no officially accepted standards. Personally I'd stick to the de facto standard defined in Standardized Chord Symbol Notation (Brandt,Carl & Roemer, Clinton).

  • Whatever standard is used, people will want to override this, so the actual formatting must be user definable. I assume this is what rustianimal means with “Supporting standard html methods for this”.

I'd like to hear your comments.


I want to use ChordPro for Kite Tuning stuff ( and that means I need to add ups and downs to names, as in vII^m7 "down two up-minor seven". So, I don't actually want in that case for `^` to get used to mean superscript since I need it to mean "up" now!

I like the idea of having a markup for superscript but I don't know what I'd want it to be.

Graham Smith

Couldn't this be handled in a similar way to 'regular expressions' -- for example '\n' is a tab-space whereas '\\n' is a backslash followed by an 'n'. That would be a good way to go as the '^' character is very definitely seen as a character related to superscript -- maths, spreadsheets, compose key sequences, etc. -- just as the '_' character is related to subscript. Just a thought.
FWIW, Musescore (full blown notation under GNU) offers superscripting chord symbols via a style (jazz).

Johan Vromans

There are several ways to approach this. This is already possible:

{define A<sup>7</sup> base-fret 1 frets 0 2 2 2 3 0 }

This is [A<sup>7</sup>]super!

It is just tedious and clumsy... So we're going to need an additional item in the config file, for example:

    "chords" : [
	{ "name"    : "A7",
	  "base"    :  1,
	  "frets"   : [ -1,0,2,0,2,0 ],
	  "fingers" : [  0,0,1,0,3,0 ],
	  "display" : "A<sup>7</sup>"

Even though the full markup language (see can be used here I think <sup>, <sub> and <small> will already be sufficient to display all conceivable chords. Thoughts?