Speed issues.

[rquadling]

Hi.

Using Windows 10 x64, ANSICON V1.7.0 (is there a binary for V1.7.1).

When using PHP to generate output (and using the Unicode output), I get corrupted output that seems to be speed related.

If the output is short, all seems OK. So, repeatedly running type captured.txt all works fine. But, if you run type captured_long.txt (which is just the same content repeated multiple times, the output is as shown in the image below. Not always the same corruption, but very close.

If I use cat captured_long.txt nothing (I've got Cygwin installed too).

Using Cygwin's more is OK too. Windows more ... WTF!!! ... I guess it isn't Unicode aware!!!

Sending the output to a file (attached) captured.txt captured_long.txt

[adoxa]

This is actually a problem with type itself, that I can't really solve. What type does is read a buffer, convert it to UTF-16 and output that. The problem is that it is splitting multiple UTF-8 bytes across two reads, so the conversion gives you undefined characters. I've fixed this in WriteConsoleA (where I can detect the split), but type is using WriteConsoleW (where it's already expected to be right). I'm afraid you really only have two options here: put up with it; or don't use type.

[rquadling]

Oh fantastic! Well. Very happy to hear that. Look forward to a new release.

[adoxa]

Did you see the comment as I was writing it? You might like to look again...

[rquadling]

Yes. It previously said you could fix it! Pah! :disappointed:

[rquadling]

Ah. I didn't explain myself fully in my original post.

I get the issue when I run PHP in my normal windows shell with ANSICON.

I get the same issue when I use type.

[adoxa]

My version of PHP is too old; which version should I get?

[rquadling]

I'm using 5.4.45. Even though it is end-of-life, are servers are stuck with it at the moment.

[adoxa]

Wrapping captured_long.txt as php

<?php
echo "...
...
";

and using 5.6.17, I can see it going wrong. set ANSICON_API=php and running it through ANSICON 1.66 works fine.

The issue here (at least, the issue I had, not sure if it's the same as yours, though) is that WriteFile is given, say, three bytes (which is the size of a line drawing character in UTF-8), detects that it's writing to the console, so sends it along to WriteConsoleA, which converts it to UTF-16 and reports back that it wrote one character, so WriteFile reports back that it wrote one byte. Now PHP requested three bytes to be written, found out that only one was, so it sends two again. The ANSICON_API setting tells WriteFile to just report back what it was sent (which 1.72 always does, only using ANSICON_API for WriteConsoleA).