Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pixels per cm #11

Open
iandoug opened this issue Oct 30, 2016 · 4 comments
Open

pixels per cm #11

iandoug opened this issue Oct 30, 2016 · 4 comments

Comments

@iandoug
Copy link
Contributor

iandoug commented Oct 30, 2016

Hi Patrick

A question about your pixels per cm for the different layouts:

KB.keyMap.standard.s683_225.pixelsPerCm = 26.315789;
KB.keyMap.european.s683_225.pixelsPerCm = 26.315789;
KB.keyMap.ergodox.s683_225.pixelsPerCm = 25.7894732;//26.315789;

Why is the ergodox one different?

While I have your attention, what does s683_225 mean? It's been puzzling us :-)

Thanks, Ian

@patorjk
Copy link
Owner

patorjk commented Oct 31, 2016

The units for the keymaps are in pixels and they need to be converted to centimeters. 683_225 represents the width and height of the layout ("s" is for "size"). Originally I was going to allow for different Key Maps, and these maps could re-use the coordesponding Key Sets. However, over time s683_225 became the default Key Map for everything, and even though the dimensions are meaningless for Ergodox layouts, it uses it so the underlying app doesn't have to change the variable for Key Map size.

Also, it doesn't really make since to define a new Key Map if just the size of the layout is changing, since you can just scale things. In the beginning I just didn't want to lock myself into particular maps for the various layouts, so I thought adding a subparameter would allow me to easily change things later. Naming the map after it's size was probably not a great idea, but I couldn't think of anything better at the time.

@iandoug
Copy link
Contributor Author

iandoug commented Oct 31, 2016

Hi Patrick

Thanks. I did suspect that 683_225 was an earlier dimension that just got carried forward.

Can you maybe advise why the pixels per cm is different for Ergodox?

Also I see on the standard layouts the keys are flush with each other, while on the Ergodox there is a narrow gap between keys. Won't this affect distance calculations (and hence score?)

thanks, Ian

@patorjk
Copy link
Owner

patorjk commented Oct 31, 2016

It's due to the key size, spacing, and measurements I did for the layout. You'll notice the keys are slightly smaller on the Ergodox layouts, so the pixels per cm value is also slightly lower.

@iandoug
Copy link
Contributor Author

iandoug commented Oct 31, 2016

Ah.
Okay, we're doing a slightly different form factor and were not sure what to use. However we're basing it off the standard layout so I guess that would also be the correct pixels/cm to use.

Also I'm building a meta-site that uses the scores from your program to compare layouts, I was worried I would have to redo all my Ergodox scores... :-)

Long discussion starts here: http://www.shenafu.com/smf/index.php?topic=89.0
You'll need to register to see the attachments.

My site (work in progress) is at http://www.keyboard-design.com
Relevant section for you would be Best Layouts.

We had some discussion about layouts using AltGr for punctuation (see issue #10), and how your scoring handles them. It was one of the drivers behind Den developing an alternative scoring model.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants