rluetzner / chordimagegenerator Goto Github PK

Since .Net 6.0 the System.Drawing library is Windows-only. For now it works when we build the project with Docker (for whatever reason that is), but it will stop working eventually.

To make this truly platform independent, we should replace System.Drawing with a platform independent library.

I've seen a bunch of options in this StackOverflow answer. I've already looked at a few of these. While there are options that try to bridge the gap between System.Drawing and these newer libraries, none of them seem to support the Bitmap/Graphic algorithm we're using right now to generate the image.

I think in the end, it'll be the best to rewrite the code step by step (e.g. method by method) and compare the new image to the one generated with that part from the old code.

I think we should go with ImageSharp. The API is completely different, but seems pretty intuitive and I like that it's all native .Net code. Although it's a mixed license, Chord Generator falls into the open source category, so we can freely use this library.

Here is a +2 chord that I'm cutting and pasting from an old tab that I did:

I tried to create the same chord today; and, while it allows me to type the + symbol in the box, to name the chord, this is how it ends up appearing:

In addition to trying the + symbol on my keyboard, I even tried alt code 43 (which is the + symbol) as a "work around" but that didn't solve the problem either.

I think a bug was introduced when enabling the barre option. Previously, if I used this fret position: x46464, it would generate this chord image:

Now, enabling the full barre draws this:

And disabling it, it draws this:

I believe the 6th fret notes should not be drawn as a barre, since in this case it would mean the 3rd string would also be pressed on the 6th fret which is not intended.

This is a very special use case. For complicated chords like this one

, one could expect the barre to extend over the whole fretboard, similar to the F chord:

.

Alas, I'm pretty sure I've seen both versions used in songbooks. To stay backwards compatible, this should be made optional.

There's an issue regarding the optics of the chords in size 1 (which is what I use); and, that's the look of the X above the strings (that are not to be played).

If you'll observe the chords above, notice you can easily read the X on the low E string of the A+2 chord (which came from an old tab). Note on the A 2 chord, that I created today, the X now appears as a dot. Is this a font issue that can be easily addressed? I think you'll agree the A+2 x's are easier to read, right?

Here's an example for F#13b9 (on size 2):

It's even worse on size 1:

I think ideally, size should refer to the fretboard and give an upper limit for the font size. If the text is too long however, it should shrink to fit neatly on top of the fretboard.