wxHexEditor
wxHexEditor copied to clipboard
EUA
[feature] add option for font selection
Probably due to winapi limitations, if wxHexEditor is run in one locale, but the encoding of a different locale is chosen, text part of hex widget isn't rendered correctly due to missing glyphs.
It's likely irreproducible on Linux, due to gtk+ going through pango.
Can you please send sample file and selected locale and picture of the issue? Also send a picture of proper view, how it need to be looks like. Than I might work on it.
I don't actually pay big attention to text panel but end of the day, all bugs need a fix, if they are easy to kill :D
...I pretty much don't really remember what I was doing while I've filed this - I only have guesses.
I haven't tested if it actually works on Linux, cause I pretty much hate wxWidgets. Though for the above stated reason, I expect it does. The problem was seen in the Windows version run by wine.
IIRC, what I've learned about winapi during my rare contributions to wine, unless going through uniscribe (or whatever that lib is called), Windows while assigning fonts also assigns locale encoding to the font. Standard Windows font selection dialog has a listview with a combobox for that option (again, IIRC).
This likely still kind of works with fonts that have all the glyphs, but most don't - especially in CJK case.
AFAICT, the most simple test would be a text file with Shift-JIS encoding. If wxHexEditor is set to Shift-JIS and run in a Japanese locale, it displays the text properly; if, however, it's run in one of European locales (likely any Windows equivalent of latinx locales), instead of the glyphs, you'll see missing glyph boxes.
As seen in WINEDEBUG=font, the program (or - more likely - wxWidgets) calls CreateFontIndirectExW with a LOGFONTA with DEFAULT_CHARSET, that is one based upon current locale. If it's one that doesn't match glyphs needed by the text, missing glyphs happen.
Letting the user pick the font by themself would likely side-step the problem.
I'd like to see this feature too, but primarily for cosmetic reasons. I have some fonts that look like old IBM text mode, and soon may have another font that looks like old MacOS system font, and I would like to use those in both the text edit panel and the hex edit panel, depending on my mood.
I highly second this! For some reason, on my system wxHexEditor picks non-monospace font, and this renders the app pretty much unusable.
... well, here's a patch for that, actually - it's pretty trivial to implement wxHexEditor-font-chooser.patch.gz
While I missing, someone looks like add an option. What a good day :+1: :1st_place_medal: