Color not printed if BColor not specified

[synhershko]

Color printing isn't working unless BColor is specified.

For example, I'd expect this to work:

        final ColoredPrinter cp = new ColoredPrinter.Builder(1, false)
                .foreground(Ansi.FColor.GREEN)
                .build();

But it will just print text regularly, until BColor is set as well:

        final ColoredPrinter cp = new ColoredPrinter.Builder(1, false)
                .foreground(Ansi.FColor.GREEN).background(Ansi.BColor.BLACK)
                .build();

Setting BColor.None gives same no-op results

[dialex]

Sorry for the late reply, I did not get a notification -- it won't happen again 😉

I could not reproduce the issue. I'm on Mac 10.11.6, using IntelliJ and the message was printed with color (see the gif below).

Can you provide more info about your env (e.g. OS in use, console in use, versions of Java and JCDP)? Can you also update to JCDP 2.0.2? I upgraded the version of our Jansi dependency, as they have been doing some work around Cygwin.

[dialex]

I created a branch to address this, with a new unit test that includes your example (and that is currently passing, without the need of any fix): https://github.com/dialex/JCDP/tree/issues/6

[bartenbach]

I am having the exact same problem on a Mac.

Unless you specify a background color (also can't be BColor.NONE), the text printed to the terminal is completely default. I actually thought this library didn't do anything until I added a background color.

[dialex]

Thanks for raising it @Proxa. I'm also on a Mac and I could not reproduce it. Can you check the gif above and to see if you are doing something different?

• Which terminal and version are you using?
• Which Java version? Which JCDP version?

[bartenbach]

I wasn't using IntelliJ's terminal, I was using the Mac terminal. I don't know what it is, but $TERM replies xterm-256color. I created instantiated the ColoredPrinter with the ColoredPrinterBuilder, so it wasn't exactly like the gif.

Java 1.8, JCDP 2.0.3.1

I won't be able to re-test on the Mac until Monday.

[bartenbach]

*Compiling with 1.8 but down to 1.7 source level

[bartenbach]

Same problem, even trying the exact method in the gif. The gif is using a different version of JCDP than I am.

[bartenbach]

Tested on Intellij terminal and Linux terminal. No color - just prints message.

[dialex]

Thanks for your effort Blake, I'll have a look this week.

[dialex]

This is so frustrating, I can't reproduce it at all :(
This is the code I used (running with the latest version on Maven):

ColoredPrinter printer = new ColoredPrinter.Builder(1, false).build();

printer.setForegroundColor(Ansi.FColor.GREEN);
printer.println("A green message");

printer.setForegroundColor(Ansi.FColor.CYAN);
printer.println("A cyan message");

printer.print("A red message", Ansi.Attribute.NONE, Ansi.FColor.RED, Ansi.BColor.NONE);

1. Please run that exact code. Same issue?

Here's a screenshot of iTerm v3.0.15 on macOS 10.12.5:

And another of IntelliJ Community 2017.1.5:

I highly suspect this is an issue specific to the terminal or the some environment config. There's an easy way to find out. This is the ansi prefix that formats the text color \033[;32;m.

2. Please try on a new project (without any reference to JCDP) to run this single line of code:

System.out.println("\033[;32;mYour terminal should make this text green.");

3. If it's not coloured, please send me a zip with the source code ready to run, so I can run your exact same code and check it the bug is reproducible.

I want to find the cause, so that other users like you don't get disappointed on my library. I can't force the background to black by default, because that would not work for everybody.

[ryber]

So the same thing happens to me, but I suspect I know why. In my case I have a custom console logger for Fitnesse tests. When I run the logger directly from say a jUnit test its fine but when run as part of a fitnesse test runner it fails.

My hunch is that somewhere along the lines the terminal information is being lost. How exactly does jcdp determine the terminal? Can it be passed to it? I don't see anything in ColoredPrinter that looks like I can tell it?

[dialex]

Hey @ryber. JCDP uses your Java's standard out (source), so it doesn't really choose the terminal -- that's Java's responsibility. However, this line of code tries to guess your Operating System, and picks an ColoredPrinter implementation accordingly.

If you use polymorphism and do ColoredPrinter cp = new UnixColoredPrinter.Builder(1, false)...
instead of ColoredPrinter cp = new ColoredPrinter.Builder(1, false)...

...does it fix the issue?

[jdemeule]

Hello,

Sorry to commenting a closed issue but I do not think that is fixed.
I could easily reproduce the case directly on shell using the macOS integrated terminal (not iTerm nor IntelliJ one).

I think a simple should could be to avoid adding the trailing semicolon in case of no background specified.

[dialex]

Sure @jdemeule,
Can you share the code you used to reproduce the issue? I would like to reproduce it on my machine, so that I can debug a solution.

[jdemeule]

I fact I only notice that specifying a "empty" background color is disturbing for macOS terminal but do not specifying it is ok (\033[;32;m vs \033[;32m in the screen shot I provided).

If I take a look at the code generating this escape sequence, it seems that the pair foreground/background is always generated.

    @Override
    public String generateCode(Attribute attr, FColor fg, BColor bg) {
        return Ansi.PREFIX +
                attr.toString() + Ansi.SEPARATOR +
                fg.toString() + Ansi.SEPARATOR +
                bg.toString() + Ansi.POSTFIX;
    }

I could suggest to adapt this function this way:

    @Override
    public String generateCode(Attribute attr, FColor fg, BColor bg) {
        if (bg == BColor.NONE)
            return Ansi.PREFIX +
                    attr.toString() + Ansi.SEPARATOR +
                    fg.toString() + Ansi.POSTFIX;
        return Ansi.PREFIX +
                attr.toString() + Ansi.SEPARATOR +
                fg.toString() + Ansi.SEPARATOR +
                bg.toString() + Ansi.POSTFIX;
    }

I think at a reproducible test case could be the one from the original issue

        final ColoredPrinter cp = new ColoredPrinter.Builder(1, false)
                .foreground(Ansi.FColor.GREEN)
                .build();

[frossm]

Hello,

I have the same issue here. On windows where I normally develop everything is fine. But the same jar file does not produce color on the Linux (Fedora 30) comment line without having a background specified.

I may be doing something wrong so I created a simple java app that has this issue occur. It's a very basic maven project using JCDP 3.0.0 and is located here:

https://github.com/frossm/colortest

You should be able to just use "mvn package" to get the full jar file in the Target directory. I also uploaded it as a release if you don't want to go through that.

Here is the program output in Windows:

** Here is the same running in Linux:**

I love the software and use it all the time. I'm happy to help figure this out, just let me know how I can help.

Thank you very much.

Michael

[dialex]

Thanks a lot for the examples, that are precious for my debugging. Currently I'm on working on #21, as soon as I close that I'll move to this one.

[dialex]

I cloned your repo and was able to reproduce your issue. Both IntelliJ's and Mac's console trigger a Unix printer, which means it will skip Jansi (less dependencies to worry about).

IntelliJ (unexpected behaviour):

iTerm (expected behaviour):

There's two things wrong with IntelliJ:

1. Setting the background as black actually prints a white background ❌
2. Not setting a background, ignores all color codes ❌

This wrong behaviour only happens on IntelliJ. The same code running on iTerm prints as expected. I opened a ticket on IntelliJ's support.

[dialex]

Possible solutions:

• IntelliJ discovers why their terminal behaves diff and they fix it
  • ⏳https://youtrack.jetbrains.com/issue/IDEA-229594
• By default, JCDP applies BColor.Black
  • This would conflict with the user's theme (e.g. for a user with a light theme, Black would not be the same as None). Also, IntelliJ prints Black background as White.
• When BColor == None, JCDP doesn't add the Ansi code for it (kudos to @jdemeule)
  • Seems to fix the IntelliJ issue... need to confirm if doing so:
    • keeps the generated code ANSI compliant ✅apparently you can have any number of separators ;, e.g. \033[38;2;255;82;197;48;2;155;106;0mHello
    • works on all other terminals (Windows, iTerm)

[frossm]

Hello. For my issues on Linux I was not using IntelliJ. I tried on Fedora using Gnome Terminal and Tormentor using it's terminal (which I'm not sure if it's Gnome).

Both displayed the same issue running the same colortest jar file.

[dialex]

My latest PR (#34) should fix your issue, already tested it locally.

I published a new release 3.0.1 on maven, but it will takes a while to appear. Have a go with that new version, and let me know if it worked.

Thank you for your patience and happy festivities 😉

[frossm]

Thank you Diogo. Maven repository had the new version and I just tested it. Seems to work great in Linux now. I need to do a bit more testing, but looking good! Thank you. Happy holidays. Michael

…

On Sun, Dec 22, 2019 at 9:58 AM Diogo Nunes ***@***.***> wrote: My latest PR (#34 <#34>) should fix your issue, already tested it locally. I published a new release 3.0.1 <https://github.com/dialex/JCDP/releases/tag/v3.0.1> on maven, but it will takes a while to appear. Have a go with that new version, and let me know if it worked. Thank you for your patience and happy festivities 😉 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMLETYDJF6AYIYDNAVWW4LQZ6FCLANCNFSM4C3EQWGA> .