TC 11.57 Help File unformatted?

[AntonyD]

I can agree that with 12001 we can emulate(but how??? and that's the question indeed!) the problem.
BUT for correct testing we have to use PROPER values - which indeed can be found among all values of this reg.key.

[petermad]

2AntonyD
I can reproduce the problem with the old help files if I use value 11001 or 11000 but not with lower values - so just test with value 11001.

I thin Ghisler might have made a typo in his post: viewtopic.php?p=484118#p484118 and written 12001 instead of 11001.

[AntonyD]

lower values means that IE engine should start use more older version of it - 10/9/8/7
and obviously that on such old values=engines this problem will disappear - coz we use very old technique to write the html content.
This is certainly interesting - trying to tweak the code so that it works again as if it were the year 2000.
But there is absolutely no sense in this from the outside view, imho.

[petermad]

2AntonyD

CHM files (Compiled HTML Help) primarily use the Internet Explorer rendering engine, essentially locked to IE 7 emulation mode on Windows Vista, 7, 8, and 10. Although newer versions of IE (up to IE11) may be installed on the system, the HTML Help Viewer (hh.exe) renders content using an older, restricted engine.Default Engine: On modern Windows, the engine behaves as IE 7, limiting CSS3 and HTML5 capabilities.

So that is why we do not want to use IE11 rendering. And why would we need that anyway - just because something is newer doesn't mean that it is better for the purpose - and in this case it is worse.

If you force the chm files to be rendered as IE11 with the 11001 registry setting, then the help file has to be totally rewritten, and then it will not work on systems that do not support IE11 - i.e where nether IE11 nor Microsoft Edge is installed. That is why we have added <meta http-equiv="X-UA-Compatible" content="IE=5"> to force it back from the 11001 registry setting - that is not a default setting anyway - you cannot know if the user has that setting tor totalcmd64.exe or not

[petermad]

2ghisler(Author)

An executable ends up under HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION when an application that embeds the legacy Internet Explorer (IE) WebBrowser control needs to force a specific, often modern, rendering mode, rather than defaulting to the very old IE7 standard.

This registry setting is usually created by an application’s installer, a setup script, or programmatically by the application itself upon its first launch to ensure website compatibility.

Here are the primary ways the key is added:
Application Installer/Updater: During installation, the software setup (e.g., a setup.exe) writes the executable's name and desired emulation mode (e.g., \(11000\) for IE11) to the registry, so it works immediately upon launch.

I don't see any indication in TC's INSTALL.INF that this should be done during installation. So how do some people get the [HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION} setting for totalcmd64.exe in their registry ????

If it is possible for the TC installer to set this key, maybe it would be a good idea to set it to 10000 or 7000...

[AntonyD]

Yep, this should be a good question))
I definitely did not do anything related to this reg.key - neither on a special testing actions - nor the occasional changes
deduced from some another actions related to my local custom ver. of hh.exe...

BUT value of FEATURE_BROWSER_EMULATION I had... But now w/o any value all is fine))

[petermad]

She this post: viewtopic.php?p=484539#p484539 - the last two links are good if you want to check all the Help pages in a fast way.

[ghisler(Author)]

It should indeed be 11001 and not 12001, which was the highest value I tested to check whether it makes any difference. 11001 would be Internet Explorer 11 in Edge rendering mode.

I can see that you divided by 11 when converting - I divided by 10 - how do we know which font size is default 10 or 11 pt?

I googled
css 1em is how many pt
and it reported that the default is 12pt. I devided by 11 instead of 12 to make sure that it didn't get too narrow, but 12 would probably also work.

[petermad]

I discovered that setting the font-size in % makes the pages render the same in the Help and in modern browsers.
I used:
84% for x-small
100% for small
150% for large

With these values it is the pages looks indistinguishable the same in both the .chm files and in browsers

You can dowload my latest set of .chm files here:

• https://tcmd.madsenworld.dk/tcmde1157b_chm_em5%.zip
• https://tcmd.madsenworld.dk/tcmdd1157b_chm_em5%.zip

It is the same files that I use here:
I have changed the layout a little of:

• https://tcmd.madsenworld.dk/onlinehelp
• https://tcmd.madsenworld.dk/onlinehelp-deu

And there is also an online tool here to quickly go through all pages:

• https://tcmd.madsenworld.dk/onlinehelp/index2.html
• https://tcmd.madsenworld.dk/onlinehelp-deu/index2.html

I devided by 11 instead of 12 to make sure that it didn't get too narrow, but 12 would probably also work.

And I divided by 10 to make room for rounding down - I didn't want fractions because my experience (with pt and px) is that using fractions is not always rendered the same way in different browsers - like some browsers enlarges a font at a threshold of for example going from 11.5 to 11.6 while others do it already when going for example from 11.3 to 11.4.

[ghisler(Author)]

I discovered that setting the font-size in % makes the pages render the same in the Help and in modern browsers.
I used:
84% for x-small
100% for small
150% for large

Interesting, did you try these also at different screen scaling factors, e.g. 100%, 125%, 150%?

[petermad]

Interesting, did you try these also at different screen scaling factors, e.g. 100%, 125%, 150%?

If you mean bnrowser scaling (with Ctrl+mousewheel) - yes it works with no problems.

I havent tried Window system scaling - on my Windows 10 laptop I opnly have 125% as an option. On Window 7 I have 125% and 150% option. I will try it with other user accounts - changing that can really mess up my desktop when going back.

EDIT I have now tried with System Windows scaling in both Windows 10 and 7 - no problems with that either.

[ghisler(Author)]

I think that we shouldn't make this change in Total Commander 11.57a. This is just too big and may break the help in unexpected places like Windows 9x, Linux (Wine) etc. I think the safest thing to do would be to only add the line

<meta http-equiv="X-UA-Compatible" content="IE=5">

and then try these other changes in a public beta test for a later version. What do you think, any downsides?

[white]

I think the safest thing to do would be to only add the line

<meta http-equiv="X-UA-Compatible" content="IE=5">

and then try these other changes in a public beta test for a later version. What do you think, any downsides?

Seems OK to me. It fixes the issue reported by the OP. The other things are improvements (and some minor other issues reported by petermad).

[petermad]

I don't think the risk is there, but OK

I also think the: display:inline-block; fix for all .s* classes should be implemented.
You actually don't have to add { display:inline-block; to every .s class - you can just add one class in the start:

Code: Select all

span {  display:inline-block; }

That is why it is called cascading style sheets


Changing this:
84% for x-small
100% for small
150% for large

For the online version is pretty easy.

Actually if I implement the % font-sizes and add span { display:inline-block; } in the ie.css file of the original totalcmd.chm for TC 11.57 - then the problem reported by the OP is gone. But I would keep the <meta http-equiv="X-UA-Compatible" content="IE=5"> for backwards compatability with old Windows systems (9x).


It actually makes sense:
In IE5 and IE7 supports the width style for inline level elements as for example <span>, but later versions of IE don't as well as other browsers. Tha is why declaring the <span> tags as inline-block solves the problem because the the width style is supported.

the size of x-small, small, large etc. are predefined absolute sizes,. Those sizes was apparently different in IE5 than in other browsers. that is why the fonts suddenly becomes very small when the Registry setting forces the chm files to be rendered as IE11

In IE5 those absolute sizes was generally one size bigger than in all other browsers.

[ghisler(Author)]

I also think the: display:inline-block; fix for all .s* classes should be implemented.

Yes, I can keep that, because it's not used by the help system when using the IE5 renderer.

Changing this:
84% for x-small
100% for small
150% for large

This is where the incompatibilities start. 100% means the full size of the default font, but it depends on the browser how this is defined. Therefore this requires more research. Users can just zoom in for now when the font is too small.