>for what ever reason, your code arrived here looking to be in UTF8 or >ISO-8859-1 format... lazarus loaded is as ASCII but the box characters in >the code were obviously not the ASCII ones you are speaking of (eg: >ALT-201)... i tried to convert it to UTF8 in lazarus but the look was still >the >same... on my UTF8 xterm console, the characters look the same as in the code >when the program is run...
>FWIW: even your routine separator lines were converted... can you place the >original file online somewhere for download, please? I have put the program for download here: http://www.productionautomation.net/FPC/ASCII/ascii%20box.pas Note that the characters in the program are the box characters from here: http://www.asciitable.com/ They are the box characters form the 'extended ASCII Codes' ranging from #179 to #218 when displayed in almost any windows editor, that will still be #179 to #218, but now they are mapped to different characters. I do not believe UTF-8 are compatible with codes in this range from the original extended ASCII codes. If you want the characters to display properly, use the FreePascal Textmode IDE (type fp from a command prompt. ) I can only display the fonts properly in an editor by either using the FPC textmode IDE editor, or Notepad ONLY with an ASCII font I have. Lazarus uses windows fonts, so it displays #201 as É. I have made a simpler set of test programs and compiled some test results and posted them to my website, that thoroughly illustrate this issue. http://www.productionautomation.net/FPC/ASCII/Asciibox2.pas Is a test program with just a bunch of writeln's making box characters. It is run 2 ways, first without UNIT CRT; with the results here: http://www.productionautomation.net/FPC/ASCII/ASCII no CRT.jpg In these tests, I opened the file (with Unit CRT commented out) and ran It from Lazarus, FPC textmode IDE, Turbo Pascal 7.0, and also showed how the file looks with Notepad++, and normal notepad with ASCII font, and normal notepad with Consolas font. You can see from this test that the output is the same for Lazarus, FPC textmode IDE, and Turbo Pascal 7.0. http://www.productionautomation.net/FPC/ASCII/ASCII With CRT.jpg In these tests I ran with the CRT unit, Again I compiled and ran it from Lazarus, FPC textmode IDE and Turbo Pascal 7.0. From this we see that Lazarus and FPC textmode IDE display the Unicode versions of the characters instead of extended Ascii... but Turbo Pascal 7.0 displays the same Ascii Characters that it does without CRT. http://www.productionautomation.net/FPC/ASCII/Asciibox3.pas This is the program again but using Unicode characters. You can see in the following tests that now the characters display correctly in Lazarus, but not FPC IDE or Turbo Pascal 7.0, that is because they are way outside the range of FPC IDE and Turbo Pascal 7.0, so they all actually show up as 3 characters. http://www.productionautomation.net/FPC/ASCII/Unicode NO CRT.jpg Is a compilation of all the tests above, it shows that NOTHING displays this correctly!! Even though in Lazarus they look right, they are still wrong when it runs, it's also wrong in FPC IDE, and Turbo Pascal IDE http://www.productionautomation.net/FPC/ASCII/Unicode with CRT.jpg In these tests I turned the CRT unit on, but the characters are still never right. Strangely, the results are not exactly the same when characters are specified with #codes So I did another series of tests to demonstrate this: http://www.productionautomation.net/FPC/ASCII/Asciibox4.pas This test uses the Unicode #codes in the Writeln command. http://www.productionautomation.net/FPC/ASCII/Unicode Codes NO CRT.jpg Now, you can see, without the CRT unit the codes are displayed properly with FPC, of course they aren't the Turbo Pascal 7.0 because they are not valid codes for TP7, but it's surprising they actually work in FPC when a writeln with the characters directly didn't work. http://www.productionautomation.net/FPC/ASCII/Unicode Codes With CRT.jpg Even stranger that the fact that the codes work without CRT is what happens WITH CRT, someone must have re-mapped them to show kind-of a box using + for corners, etc... but why not map them to the correct box characters instead?? http://www.productionautomation.net/FPC/ASCII/Asciibox5.pas Just for completeness, I also used the Extended ASCII codes in a similar method to the previous test. http://www.productionautomation.net/FPC/ASCII/ASCII Codes No CRT.jpg Results are expected without CRT on both FPC and turbo pascal 7.0, the box characters are correctly represented. http://www.productionautomation.net/FPC/ASCII/ASCII Codes With CRT.jpg When CRT is used the results are the same incorrect symbols as when CRT is used with a direct Writeln; http://www.productionautomation.net/FPC/ASCII/PTCPAS ASCII box.JPG I was wrong about PTCCRT, it does display Extended ASCII codes, but the reason it's useless is because it uses Borland BGI fonts, and they are not fixed width, so nothing lines up. In my opinion, the CRT unit should be displaying the same original Extended ASCII characters that are displayed in the version without CRT... and the same as they are displayed on Turbo Pascal 7.0... but even if it was decided that the CRT unit use Unicode, then it should do that Correctly, which it does not. Whether CRT is using Extended ASCII or Unicode, as far as I can figure out, it's impossible to display box characters with the CRT unit at all. James _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
