Display bugs in Compare

[browny]

Binary compare has some display bugs, at least in the latest release of TC 7.02

Left file
65 00 73 00 0d 00 46 00 | e s FF
61 00 76 00 6f 00 75 00 | a v o u

Right file
65 00 73 00 0d 00 43 00 | e s CC
68 00 61 00 6e 00 6e 00 | h a n n

Note the doubled character in text part instead of space for null.
Highlighting is correct in binary display, but in text second F and C respectively were highlighted instead of the first ones.

Configuration:
OS XP Pro SP2+latest AutoPatcher, AMD 64 3200+, 2GB RAM.

[ghisler(Author)]

Hmm, no problem here, see screenshot:
http://www.ghisler.ch/img/compareshot.png

It may be a problem with the selected font, trying to display the 0d line break character. What font do you use? I'm using Courier New.

[browny]

It may be a problem with the selected font, trying to display the 0d line break character. What font do you use? I'm using Courier New.

It is not very clear with variable width font, so here is my screenshot: w13_easy-share_com/5055691_html (replace _ with dot, of course. Sorry, cannot post links and see no way to attach image)
I also use Courier New, but script Cyrillic. When changed to Western - it all looked exactly like you posted before.

[wanderer]

This issue seems related to this one.

Binary compare works fine with variable char fonts. Both 0D and 0A are displayed as boxes. The only thing i noticed is that the hex code 00 does not appear as a dot/box in binary mode but as a space, with both fixed and variable fonts. IMO, it seems more appropriate to be displayed as a dot or box, as is done in Lister.

Opinions on that?

[ghisler(Author)]

TC shows characters between 0 and 31 as a dot under the following conditions:
1. Fixed width fonts: If the character would be shown with a different width than the default fixed width
2. Variable width fonts: If the system reports a width of zero (0) for that character

If the system shows the 0 as a space, TC will not modify that.

[wanderer]

Ok, here's what's happening:

- In Lister window, using MS Sans Serif 8 fonts (as variable fonts), when a file is viewed in hex mode, char 00 appears as a box.
- In File Compare window, using the same fonts and comparing two Unicode files (but selecting ANSI as encoding for both), char 00 appears as a space.
- In both windows, 0D and 0A appear as boxes though.

I'm guessing that the technique used in Lister is not exactly the same with the one used in File Compare. I'm just saying that IMO, it would be more clear if char 00 in File compare appeared as a box, as it appears in Lister.

[ghisler(Author)]

Indeed they use different functions now. I will try to use the same function as in Lister.

[ghisler(Author)]

This should be a bit better now.

[wanderer]

Yes, indeed it is but it seems there are still some quirks though.

Using Arial, 0D and 0A are displayed as blocks in both Lister and Binary Compare, 00 though is displayed as a block only in Lister. In Binary Compare it is displayed as a space.

Also in Binary Compare, using "Terminal 9 normal" font, 00 is displayed as space but when using "Terminal 9 bold", it is displayed as a dot. In Lister, using both normal and bold Terminal fonts, 00 is always displayed as a space.

It seems there are still differences in the way special characters are shown, i'm not sure how this situation should be handled though. The original issue (some special characters not shown at all) seems resolved, so it has now become a matter of uniformity between File Compare and Lister. The way special chars are treated seems rather complex and i don't know if it's worth the effort to try and make File Compare and Lister work the same way. It would be nice to do it, if it's not too much trouble, otherwise i guess it's fine as it is now.

[ghisler(Author)]

There are some differences because Lister uses Uniscribe and Compare doesn't, so there will always be some difference.

The original issue (some special characters not shown at all) seems resolved

Great, thanks! I will leave it as it is for now.