rushsteve1
commented
3 years ago Switching the crossword-empty-position-char to █ "full block" seems to fix this issue for me
Other block characters: https://en.wikipedia.org/wiki/Block_Elements
Closed rushsteve1 closed 3 years ago
rushsteve1
commented
3 years ago Switching the crossword-empty-position-char to █ "full block" seems to fix this issue for me
Other block characters: https://en.wikipedia.org/wiki/Block_Elements
Boruch-Baum
commented
3 years ago Of the fonts you listed, I have access to 'noto mono' and can't reproduce this, trying sizes 9, 10, 11, 12, 13, and 15. For future reference:
Thanks for the update with your personal work-around, but I'd like to investigate this a bit further because monospace should always be mono-space. Also, I don't explicitly require or check for a mono-space font, so that's a bug.
rushsteve1
commented
3 years ago It happens in GUI Emacs on KDE Plasma 5.20.5 on X11, compositor doesn't change anything. I tried all fonts at 14pt.
I think the bug might be caused by not considering ▦ to be monospaced since it comes from the Geometric Symbols Unicode block, though the issue seems specific to the Crosshatched Square as the ■ Black Square symbol lines up just fine.
I think the best solution might be to replace Crosshatched Square with either Full Block or Black Square or similar.
Personally I think Full Block without the pipe characters | would look a lot like a real crossword puzzle.
Boruch-Baum
commented
3 years ago On 2021-01-19 10:17, Steven vanZyl wrote:
It happens in GUI Emacs on KDE Plasma 5.20.5 on X11, compositor doesn't change anything. I tried all fonts at 14pt.
What terminal emulator are you using? Konsole?
...
Personally I think Full Block without the pipe characters | would look a lot like a real crossword puzzle.
When I try scoping this out, I find that the lack of a pipe character makes it difficult to accurately visually assess or count the length of across clues, especially as they get long. Also, it makes the geometry seem too narrow for its height (see example below). Then, once I use a pipe character between squares, it migrates to the top and bottom border lines, ans makes sense to apply to the first and last columns. Any ideas or feedback on that?
Below is an experiment with 'Full block' for the un-writable squares, and uni-code 'black small square' for the writable squares. The idea here is to introduce some form of 'light' 80% thatch block that would replace writable squares when they are not written (ie. their initial state, and anytime after that they are filled with a 'space' character.
With that, I get something like:
█████████████████
█▪▪▪▪█▪▪▪▪▪█▪▪▪▪█
█▪▪▪▪█▪▪▪▪▪█▪▪▪▪█
█▪▪▪▪█▪▪▪▪▪▪▪▪▪▪█
█▪▪▪▪██▪▪▪▪▪█▪▪▪█
█▪▪▪▪█▪▪▪█▪▪▪▪███
████▪▪▪▪▪██▪▪▪▪▪█
█▪▪▪█▪▪▪▪█▪▪▪▪▪▪█
█▪▪▪▪▪▪▪█▪▪▪▪▪▪▪█
█▪▪▪▪▪▪█▪▪▪▪█▪▪▪█
███▪▪▪██▪▪▪▪▪████
█▪▪▪▪▪▪█▪▪▪█▪▪▪▪█
█▪▪▪█▪▪▪▪▪██▪▪▪▪█
█▪▪▪▪▪▪▪▪▪▪█▪▪▪▪█
█▪▪▪▪█▪▪▪▪▪█▪▪▪▪█
█▪▪▪▪█▪▪▪▪▪█▪▪▪▪█
█████████████████It's easier for counting clue lengths till six characters, but has lost its look for a square geometry (it's a 15 x 15 grid).
-- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
rushsteve1
commented
3 years ago I'm not using any terminal emulator. This is just Emacs running in GUI mode.
You could replace the pipe characters with Full Block in the black regions, and spaces or something in the white regions. I'm not really sure what the best option is, I just thought it might look nice.
Boruch-Baum
commented
3 years ago On 2021-01-21 11:50, Steven vanZyl wrote:
I'm not using any terminal emulator. This is just Emacs running in GUI mode.
Got it.
You could replace the pipe characters with Full Block in the black regions, and spaces or something in the white regions. I'm not really sure what the best option is, I just thought it might look nice.
Okay. I'll close this issue, but will continue to play with options and be open to further suggestions.
Also, I made a commit this morning or last night that improves visibility by colorizing the grid, so if you update your code either via MELPA or github, you'll have another defcustom that might improve your experience.
Regards,
-- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
This appears to be some kind of font issue, but I've tried with Noto Mono, IBM Sans Mono, and Source Code Pro and it always looks like this:
The same puzzle pasted into a GitHub code block
OS: OpenSUSE Tumbleweed Emacs Version: 27.1