Artifacts are showing up in more complex chara files

[dylhack]

Assurance

• [X] I have read and understand the contribution guide, and
• [X] I'm sure there's no relevant issue in this repository

Current Behavior

Weird artifacts are showing up in more complex char files.

I believe this is because the character tested has multi-letter variable names rather than the usual single-letter variable names.

Steps To Reproduce

# fox.cow is provided at the bottom of this issue
chara say -f ./fox.cow "Hello world"

Expected Behavior

For there not to be characters (text) in the character.

Other Information

• Tested with fox.cow

[dylhack]

note: This file was generated by Charc0al's cowsay file converter

[dylhack]

note: it looks like cowsay-apj can interpret it just fine.

[vschwaberow]

Any other examples where this doesn't work? This issue is still open and I would like to take a look. So far from what I have been generated on the converter page I haven't find other examples.

[dylhack]

@vschwaberow

Since it's just Perl under the hood, if you replace any single letter variable with multiple letters, then that will reproduce the issue. You need a complex image with multiple color combinations to get the generator to produce it.

As @latipun7 puts it:

Yeah, honestly I'm aware of that issue. It's because there are too many colors, my solution so far is to convert images without true colors, so hopefully there would be less colors (no more than 50 colors)

Original cowsay or cowsay-apj would successfully display that because, essentially cowfile is legit perl code, hence legit variable names. Both are perl code, so they easily read the variables.

While I need to read the cowfile and write a custom parser to read the variables. I still have no idea how to parse $a alone, and not interfere with $ab. Currently all $a would be replaced by the correct color, that's why &ab would be <ansicolor_for_a>b 🥲

[vschwaberow]

Will have a look when time allows.