Version: (using KDE KDE 3.3.2) Installed from: Slackware Packages OS: Linux KCharselect could use some improvements to the way characters are displayed. Unicode is huge and most fonts have a lot of unimplemented characters, which makes finding the char you need a real pain. For example in order to get to the extended punctuation (em-dashes, nice quotes etc.), I have to go to table 32, which means a lot of scrolling through ugly pages with no characters inside. I, for one, do know where to look for each character, but a person without prior experience would probably quit after 5 or 10 pages. My suggestion is to leave the current layout as an option, as some people may be used to it an maybe it is good for some situations (although not in my usage pattern) and implement the default program layout to look more like the character selector dialog in OpenOffice.org. There, only characters present in the selected font are displayed, with no empty space in between. One could perhaps use some placeholder to indicate that there's a number of misssing characters in between, but make it a single cell, not a thousand if 1000 characters are unimplemented in the font. The other thing worth copying is that there's a combo box with character group names, e.g. 'Extended Latin A' which makes finding characters much easier than the current table number based approach. Finally, what is worth preserving in KCharselector is the editable text field - this is good, much better than in OOo and should be left as is. However, please make that field a regular left-aligned edit field if left alignment is locale's default. On KDE 3.3.2 the edit box uses uses right-aligned text, which is at least strange (and awkward to use).
Knwoing if a character is part of a font or not is nearly impossible with Qt, as, since Qt 3.x, all fonts are simulated to be Unicode fonts. So the code has not any chance to know what is in the font and what is not. As for character placeholders, it is a Qt decision too. (There is a bug about KHTML for this; I have not its number at hand.) As for Unicode code group (e.g. "Extended Latin 1"), if I remember well, there is also a bug report about this. The problem is that they may be many of such groups in what Unicode calls a row (what KCharSelect shows at one time). The last problem is that, as far as I know, KCharSelect is unmaintained... Have a nice day!
*** This bug has been confirmed by popular vote. ***
The prior maintainer of KCharselect, that's me, agrees. This would be a great feature.
This bug report actually contains multiple requests and most of them are solved in the KDE4 version of KCharSelect. However, the actual issue, hiding characters not in the selected font, is still not implemented and I'm not sure if that feature still makes sense, because the page based system has been replaced with named categories and a search function. That means you find your character much faster without digging through lots of ugly pages. Also, if you're looking for a specific character, not finding it because it's not in the font would also be confusing. I also don't know if the technical problems are fixed in Qt4, there is QFontMetrics::inFont(QChar), but I didn't test if it works correctly. Also, if this feature was still wanted, a good place for enabling it in the GUI would be needed.
*** Bug 363864 has been marked as a duplicate of this bug. ***
I tried the new QFont::styleStrategy(QFont::NoFontMerging), and it seems to work for most scripts. if the current font does not have the selected script, a fallback will always be used. This seems to be a (documented) Qt peculiarity. Would it be okey to display the characters that are available in the selected font with the default (white) background, while characters from a fallback font are displayed with a dimmed (gray) background? If it needs to be configurable, I thought about adding a toggle toolbutton next to the font combobox.
(In reply to Christoph Feck from comment #6) > I tried the new QFont::styleStrategy(QFont::NoFontMerging), and it seems to > work for most scripts. if the current font does not have the selected > script, a fallback will always be used. This seems to be a (documented) Qt > peculiarity. Ah. That explains a lot. > > Would it be okey to display the characters that are available in the > selected font with the default (white) background, while characters from a > fallback font are displayed with a dimmed (gray) background? > > If it needs to be configurable, I thought about adding a toggle toolbutton > next to the font combobox. For my use, I just need to know if a particular glyph is in the font or not (and how it looks, of course). So having a different background would be fine. I have in the meantime noticed that there is a difference (usually) between glyphs in the font, and those not, in that the missing ones are rendered thinner. Though I suppose how noticeable this is depends on the font in question. Have you seen how FontForge the missing glyphs? But AFAIK they're on GTK not QT so they probably don't have the exact same problem. Thanks.
Have you seen how FontForge HANDLES the missing glyphs? Need an edit box on comments... :-)
https://git.reviewboard.kde.org/r/128680/
Hi I took a look at your proposal, thanks. I then realised what part of the problem is ... there are two different Use Cases for KCharSelect: 1. probably the original one, which probably dates all the way back to the similar program on Windows 3.1 ... you're typing something, need a ß character, and don't know the alt-xxxx/whatever code for it, so you fire up a Character Select program to find it, copy and paste. This use case predates Unicode. 2. Other use, (eg me) is to see which glyphs are in a font, and what they look like. This is to help in deciding which font to use for a particular job. In use case 1, you may be happy with QT/system substituting a glyph from a different font. In use case 2, you need to know exactly what's what. Use case 2 is actually "Font Browser" rather than Character Select, but the existing font browser on KDE is way underpowered for proper investigation of a font. (I guess it's also very old and possibly pre-unicode, where there were only a handful of glyphs in a font). So yes, your proposals will work for me, and are a definite improvement. My only issue is what is the default view, and that I suppose depends on whether you are targeting Use Case 1 or Use Case 2 .... I would prefer the greyed out as default, but I accept that those in Use Case 1 would prefer the other view. Thanks, Ian
*** Bug 412267 has been marked as a duplicate of this bug. ***
Perhaps a toggle button with a bundled font, if you're able to specify multiple fonts for fallback like CSS has? When enabled, this would allow for using whatever font is currently in the dropdown box as the 1st font, and then the fallback font(specified in settings if bundling isn't possible, although that makes the feature less reliable, perhaps package managers can ensure the dependency?). This would make the distinction pretty clear, and perhaps be relatively easy to support this feature, so that KCharSelect is reliable utility for inspecting glyph support in a font? You can create your own font for the fallback glyph, or use existing solutions. There is Adobe Blank(v1, v2, VF) which is intended for this type of purpose but as the name implies, is a blank fallback, so the cell would just look empty. They have an alternative called Adobe NotDef, which provides the familiar rectangle tofu glyph, another is TofuDetector, which is suggested by behdad(Pango and I think FontConfig core developer?) Adobe Blank: --- v1 --- https://github.com/adobe-fonts/adobe-blank https://blogs.adobe.com/typblography/2013/03/introducing-adobe-blank.html https://blog.typekit.com/2013/03/28/introducing-adobe-blank/ --- v2 --- https://github.com/adobe-fonts/adobe-blank-2/ https://blogs.adobe.com/CCJKType/2015/04/adobe-blank-2.html --- VF --- https://blogs.adobe.com/CCJKType/2019/05/adobe-blank-vf.html https://github.com/adobe-fonts/adobe-blank-vf Adobe NotDef: https://github.com/adobe-fonts/adobe-notdef https://blogs.adobe.com/CCJKType/2016/05/tofu-or-not-tofu.html TofuDetector: https://github.com/santhoshtr/tofudetector https://github.com/Pomax/CFF-glyphlet-fonts/issues/12
I want to show the glyphs on a specific font, tried kcharselect and couldn't find a way to do it. Tried fontforge and gucharmap and they both fail in KDE/wayland. Booted into X.org and found in gucharmap there is an option View -> Show only glyphs from this font I will live in KDE/X till life outside is better ;)