I’ve entered a bug report on this here:
https://bugs.freepascal.org/view.php?id=32558
James
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
2017-10-16 19:03 GMT+07:00 James Richters :
>
>
> I’m curious how the CRT unit handles the Extended ASCII codes on Mac and
> Linux… All versions should be the same for cross platform compatibility.
>
I don't know the underlayer library being used by CRT unit on Mac and
Linux. Perhaps because CRT
On 16/10/17 13:03, James Richters wrote:
>Long story short: CRT unit doesn't work at all on Windows, but it
works with unicode on Mac/Linux.
I’m curious how the CRT unit handles the Extended ASCII codes on Mac and
Linux… All versions should be the same for cross platform compatibility.
I a
>Long story short: CRT unit doesn't work at all on Windows, but it works with
>unicode on Mac/Linux.
I’m curious how the CRT unit handles the Extended ASCII codes on Mac and Linux…
All versions should be the same for cross platform compatibility.
I also noticed that email broke my links
2017-10-16 3:14 GMT+07:00 James Richters :
>
> 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.
>
Long story short: CRT unit doesn't work at all on Windows, but it works
with unicode on Mac/Linux.
-
>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
>th
I had a similar problem when trying to represent trees using extended ASCII
characters. My solution was to adapt my character representations to UTF8.
To see what I mean you can have a look at
https://github.com/svpantazi/catalan-monoid-generator. The
generate_catalan_monoid.pp contains a PrintASCI
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 s
It may be worth looking at the SetTextCodePage in the System unit. On
Windows targets I often find it necessary to include
SetTextCodePage(output,cp_utf8);
to avoid problems writing UTF-8 to the console.
On 14/10/17 08:12, pasc...@piments.com wrote:
On 13/10/17 14:39, James Richters wrote:
I
2017-10-14 14:12 GMT+07:00 :
>
> Thanks for that lengthy description of the problem, much better than OP's
> just describing output as rubbish, or something similar.
> since char is a single byte type a large value will just get truncated. If
> you turn on range checking it should return a compi
On 13/10/17 14:39, James Richters wrote:
I‘ve tried Writeln(Chr(9556)) but chr() has a limit of 255, and I’ve
tried just Writeln(#9556) and while that compiles and runs, it doesn’t
produce the correct character.. I have a feeling (but have not tested
it) that it keeps cycling around the first 2
>I want to create console app that's using box drawing characters from unicode.
>Before CRT unit is used, it's all fine and my program could draw
>table beautifully. But once I put CRT unit, those characters became garbages.
>But strangely, it's only happen on Windows' terminal (win10).
>I tr
Hi,
I want to create console app that's using box drawing characters from
unicode. Before CRT unit is used, it's all fine and my program could draw
table beautifully. But once I put CRT unit, those characters became
garbages. But strangely, it's only happen on Windows' terminal (win10). I
tried th
13 matches
Mail list logo
