Column allocation doesn't take filler into account

[howardjones]

I have a keyboard where the top row has a large gap in it: http://www.keyboard-layout-editor.com/#/gists/8c20b446f56a42b79fa6ec21ffdee3db

After adding a bunch of prints, I can see that SET-UP is correctly put in col 0, but the next arrow key is put in col 1 even though it's 9 spaces to the right. The layout actually fails due to too many columns anyway, but if it didn't the resulting "grid" would be horrible to lay out. If a key has the f field, that should be added to the running col for a row.

(also, a --verbose option would be really useful!)

[howardjones]

I realised I misread the KLE file. The 'f' is a specific filler component. The klepcbgen Key() object actually has the right x_unit value, but should do something different to assign columns. Maybe map int(x_unit) to column in advance? Perhaps not, my keyboard would have 21 columns instead of 18 then.

    col is 0, x is 1.75
  Placing key ð at row 0
    col is 1, x is 12.5
  Placing key ð at row 0
    col is 2, x is 13.5```

[jeroen94704]

Indeed, the row/column assignment is a bit of a compromise between maximizing the number of keys and ease of routing. An earlier version did as you suggest and assigned columns based on x-coordinate until I realized this increased the number of required columns unnecessarily, as you also note. So I sacrificed some ease of routing to support more keyboard layouts, which in your case means some awkward routing. Ultimately, with 25 pins, any layout with up to 156 keys could theoretically be supported, but this would probably result in even more nightmarish routing. I could make that an option for the brave though :).