rg_software wrote: 2025-05-10, 14:39 UTC
XML is supposed to be shown as code.
And I really liked the XML display at 1.0.8. No one has this.
rg_software wrote: 2025-05-10, 14:39 UTC
However, it is actually malformed.
It's clear. You need to think which version is better to use. The work of scripts can be seen in MarkdownView. But the chips 1.0.8 is nowhere to be found. Even plugins for viewing XML files do not know how.
Unfortunately, people complained earlier in this thread that 1.0.8 was broken for other documents. It all boils down to the method of opening files. One method breaks some things, another method breaks other things.
I don't think there is an easy fix for malformed HTMLs. However, if you want to view XMLs like this, I think it can be done (as an option).
Try this version. It should display any file (e.g., XML) as HTML if its extension is in the ForcedHtmlExt list. It WILL NOT display resources referenced by relative links, but perhaps for XML it is not very important.
Everything turned out perfectly. You can use the XML viewing mode convenient for the user. Thank you.
All the same, I think about Readme_ru.htm. It confuses me that Edge shows him correctly. I understand that someone has a setting of its correct display breaks the display of other files. But I do not have such files. Is it possible to make an option in this case,
switching display?
AkulaBig wrote: 2025-05-11, 16:57 UTC
Everything turned out perfectly. You can use the XML viewing mode convenient for the user. Thank you.
All the same, I think about Readme_ru.htm. It confuses me that Edge shows him correctly. I understand that someone has a setting of its correct display breaks the display of other files. But I do not have such files. Is it possible to make an option in this case,
switching display?
I have to think about it. Frankly speaking, it is baffling why Edge and embedded Chromium (essentially the same engine) show this file differently. Edge correctly deduces utf8 (even though the file is malformed), but EdgeViewer falls back to Win-1252. I'll have to experiment with it a bit.
Try this update. It is not well-tested, but works at a glance. There is a new parameter "DetectEncoding". If it is set to 1, the plugin will try to guess and force the right file encoding.
There can be subtle differences how these modes handle the same files (even if the detection is correct in both cases), but I found none; maybe something will pop up later.
Good job regarding the "Detectencoding=1" feature. I'm happy that you found a solution that works for AkulaBig.
I'm just tuning in to report that with "Detectencoding=1", Edge Viewer displays GIFs in raw text mode instead of the graphical representation. Maybe you can fine-tune this a bit more, or add a flag that controls whether to ignore/force certain file extensions?
deus-ex wrote: 2025-05-18, 18:36 UTC
Hi there, rg_software,
Good job regarding the "Detectencoding=1" feature. I'm happy that you found a solution that works for AkulaBig.
I'm just tuning in to report that with "Detectencoding=1", Edge Viewer displays GIFs in raw text mode instead of the graphical representation. Maybe you can fine-tune this a bit more, or add a flag that controls whether to ignore/force certain file extensions?
Thanks for reporting! Will fix it. I guess you are (ab)using the current functionality by listing GIF here?
Well, this should be a quickfix, please check. Basically, with DetectEncoding set to 1, non-HTML files should not be listed as HTMLs. They should be in the "OTHER" section instead.
I'd put everything that is not HTML into "OTHER". The only difference is that for HTML files in DetectEncoding mode I am trying to detect encoding. This might work against files like SVG or GIF. (I see I forgot to move SVG from the HTML list, will do).
I'm happy that you found a solution that works for AkulaBig.I'm happy that you found a solution that works for AkulaBig.
