Displaying issue with specific nfo files about ascension

[paxter]

Could be related to this issue: NewEraCracker/nfo2png#1

[ByteProject]

1. Could you please link to files that are easily downloadable and not leading to scam/spam unclear downloads? I was not able to download the file and I don't want to hassle with sites like that. Please use an easy solution like Cloud.app or your own FTP.

2. The NFO renderer is working 100%. If the files don't render, they are not proper. They either have a wrong encoding and / or wrong chars. A NFO file is a file that comes with the ancient DOS encoding (CP437 or equivalent) and uses the extended ASCII set to draw it's content. We sadly cannot work around issues by people who misuse the format, possibly to make it render in modern applications like Notepad. Please use the last release of Ascension (Ascension III - v3.0.0 - codename: Magrathea ), open the NFO file and try to change the encoding to Unicode UTF-8 or any other modern encoding, maybe Win-1252. The file should render now. If so, the files have a wrong encoding. If not, I need a file to evaluate what's the problem. But its definitely an unproper file, thats a fact as the NFO renderer is 100% implemented. Here is how you switch encodings http://cl.8-bit.info/3E1r411R2p1a

Let me know how it works. I will keep this issue open until then.

[paxter]

Thanks for your reply.
Sorry, I'm not using any cloud services. I tried to upload to another filehoster: http://s000.tinyupload.com/index.php?file_id=05005750082484399991 (download should work, I've tested it).

I'm using the latest Ascension version and tried all different encoding types. Without success. The NFO is still unviewable. I guess you're right, the NFO isn't created correctly. But I think a NFO-Viewer should handle such kind of NFOs.

[ByteProject]

Thanks mate, I was able to download the file now and test run it. It's like I said, they use Unicode characters to draw the box chars, not the extended ASCII charset (DOS codepage 437). Ascension can open these files and render correctly, however you have to select the Unicode-UTF8 encoding after opening such a file. There are two solutions to work around the problems that arise when using wrong files like this:

1. Open the file and directly select Unicode-UTF8 encoding. Ascension will render.

2. Change the ending of the file to .txt and open it with Ascension. Ascension will now assume it is a text file (which it is in fact) and directly open it in Unicode anyway (and render correctly).

I've uploaded a movie to show you what I mean. Note that I use the implemented "Commodore 64" font in Ascension III, so it looks a bit different than the standard DOS font "BlockZone": http://cl.8-bit.info/440J3N1d063C

Now to the root of the problem: using Unicode characters in an .NFO file is completely wrong. What you have here is a text .TXT file that is falsely flagged to .NFO - you could also create a Word document .DOC and flag it to .XLS - which would be as wrong either. It's just not right. Keep in mind that NFO files come from the good old DOS days, which means they should have 80 chars per line and Codepage 437 (or equivalent) encoding, so that these files would still render on a DOS machine. That's what NFO viewers are made for: to correctly render such files with ancient encodings. One of the key aspects of Ascension is to preserve the heritage of these good old days. Here is an early example: http://cl.8-bit.info/1k462h3Q3S2e

I might consider implementing a feature to check whether a NFO file contains Unicode chars and then switching the encoding to Unicode automatically. I see however not a point in this. Ascension can render the file anyway (if you either modify the ending to .txt or simply choose the UTF8 encoding), and it would be notably a workaround for issues that arise from people misusing the .NFO format. I put it on the list "to be considered" though and close the issue for now. Hope this helps.

[paxter]

Thanks for checking that. You're right, it works with UTF-8 rendering. I tested that before, but it didn't work. Looks like there is a small bug. For example: If I firstly select UTF-16 encoding and after that UTF-8 encoding, nothing happens. That was the reason why it didn't work for me yesterday.