Skip to content

Ansi color and cp437 text output#22

Open
michael105 wants to merge 1 commit intordoeffinger:mainfrom
michael105:textoutput
Open

Ansi color and cp437 text output#22
michael105 wants to merge 1 commit intordoeffinger:mainfrom
michael105:textoutput

Conversation

@michael105
Copy link

@michael105 michael105 commented Jan 7, 2026

Added two switches, -f cp437 and -f ansi

@rdoeffinger
Copy link
Owner

The cp437 seems to almost duplicate the utf-8 code, but with some small unexplained differences and it seems some bugs like missing bounds checks.
Not as obvious but similarly the ansi logic seems to duplicate a bit of the text logic, but also with differences that are not explained.
That makes this a lot of code that also is extremely hard to maintain because it introduces variations on behaviour that are not clear if they have any sense or reason.
This is also the reason I did not want to implement this feature: Yes, it's possible to add "something" that more or less does it.
But doing it correctly and without adding unnecessary maintenance burden is hard and requires putting A LOT of thought into the code.

@michael105
Copy link
Author

michael105 commented Jan 12, 2026

Well, in fact the cp437 part does the same as the utf8 part,
it just doesn't use utf8 characters.
Albite I'd say my code is easier to read..
bounds are 'checked' in the line
for (y = H - 1; y >= 0; y--)
...
But in this way you are right, it's a quick modification,
I just did need something that works,
and someone would need to document it in the manpage as well..
I did stumble upon the feature request in the issues,
so I pushed that back to git.
If anyone would need the same functionality as me,
I'm pasting text snippets to scan them with my mobile,
I modified the borders in the textmode again, and
added the possibility to read the input from stdin -i -
It's within the 'fork'.
Feel free to pull that in, or not,
me I'm lacking time and I leave it there the way it is.
Best wishes, Michael

@rdoeffinger
Copy link
Owner

rdoeffinger commented Jan 12, 2026

To be more specific then:
cp437 is the case with
for (y = H - 1; y >= 1; y-=2) {
When H is odd, it skips one row. In particular for H == 1 it prints nothing.
And it uses 3 spaces as left border while utf-8 uses one.
For the ansi case it's more that it seems overly complicated.
It seems there are three easy ways to simplify:

  • always print an escape code for every digit, like it is printed unconditionally at the end. Super simple, but wasteful
  • similarly wasteful but even more aligned to the other options and can possibly be integrated in the existing ascii case: printf("\e[7m \e[0m") for white, printf(" ") for black
  • only detect changes and print escape codes on change, and print a single space unconditionally for every iteration
  • bonus question: doesn't this give non-square "pixels"? Shouldn't maybe 2 spaces be printed for each "pixel"?

There are also some design decisions like whether to reset to non-inverted at the end of each line that should be documented with pros/cons.

@michael105
Copy link
Author

michael105 commented Jan 13, 2026

About odd counts of line, luckily someone did add the test

if ((W & 1) || ecc < 200) {	// odd sizes
		fprintf(stderr, "Not done odd sizes yet, sorry\n");

^^ (it wasn't me, and height is the same as the width)
Might be related to the utf8 code, which also wouldn't reproduce an odd count of lines..
But you are right, maybe someone else would use the quick mod of mine as starting point.
There would be better ways. Adding more patches to the code is not
necessarily the best idea.

That the qr/data matrix recognition of my mobile doesn't have any problems
with rectangular 'pixels' surprised me as well. Black on white, white on black,
or any other combination of colors I tested, doesn't seem to make a difference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants