Font display inconsistency with renaming

[Stiltzkin]

i noticed this behaviour a while back when i switched to the "Dina" font.

the left part is the regular totalcmd filelist window, where some characters are just "-".

on the right side is the same directory with renaming active.

can anyone explain the logic behind this to me?


Image: http://i.imgur.com/IJrhm.png

[MaxX]

2Stiltzkin
Use only standart fonts - Tahoma, Verdana, Arial , etc..
Any other non-system fonts can't provide you all the letter-characters you can need.

[Stiltzkin]

2Stiltzkin
Any other non-system fonts can't provide you all the letter-characters you can need.

well, it depends on the font used.

but as you can see in the picture is posted ...in some cases the fonts get mixed, meaning characters which are not available in the choosen font are displayed in another font.

but not always - that's my point here.

[Stiltzkin]

*bump*

[Balderstrom]

IIRC "Dina" is a Bitmap font, and at best only supports the first 127 chars of the font-set - although it might have some of the higher ANSI Glyphs.

As such, Bitmap fonts are restricted to the sizings that have been predefined for them. Unlike TTF or OTF which utilize Kerning and are more akin to a vector than a bitmap image.

Also TTF/OTF fonts can have "ClearType"-like effects which can diminish a given pixel to give the lettering a softer/curve --- whereas a bitmap font: each pixel is either on or off and nothing in between.

If you are seeing drawing issues in TC with Dina, it's more than likely the font has bad top/bottom spacing for being utilized in this manner. Or as mentioned characters that can't be rendered, e.g. pretty much any character that isn't visible on a US/Standard keyboard.

[Stiltzkin]

IIRC "Dina" is a Bitmap font, and at best only supports the first 127 chars of the font-set - although it might have some of the higher ANSI Glyphs.

yes, i'm aware of that. but that's not my issue here.

as stated above:
if there are characters in the filename which aren't in the dina font-set they are replaced by "-" ... but not always.

e.g.
część ✔✗ -- the first two characters are displayed Dina, the characters after them are Arial?

if i rename the file/folder to "część" it will look like "cz---" (all in Dina)

another example:

file/folder named "критерий" (russian, i guess)
it's displayed as "--------" (Dina).
when i selected the file/folder for renaming it changes to "критерий" (Arial, again).

that's my issue here.
why can't it be displayed as "критерий" instead of "--------" ?

[Balderstrom]

TC doesn't mix fonts at the same time. I don't think I've seen any file-manager or Text-Editor that does.

In normal file-list display, a single font is used. If Dina can display the letters, it does.

It's possible that when an inline-rename is done, Ghisler uses a different font for that, one that is guaranteed to have the full-unicode character set. I doubt that Dina/Arial is mixed in rename mode, its most-likely a single font, and goes back to dina during normal file-operations. Which actually makes sense, I always wondered why the spacing seems to change during an inline-file-rename (as opposed to how the file name appears normally).

[ghisler(Author)]

Actually TC isn't actively mixing fonts, but the Windows functions DrawText or TextOut do it by themselves (it's called font substitution). It seems that some fonts (mostly truetype) support it, some don't. Windows uses a different font if a specific character is missing in the selected font, but just for that character.

Lister uses a different method to display fonts (Uniscribe) which uses a different method of font subsitution than the normal GDI functions used in the file lists. That's why a font may work in Lister but not in TC, or vice versa.