A pair of enhanced progressbar/scrollbars characters kills single character between

[Maximus5]

Originally reported on Google Code with ID 1692

Win7 SP1 x86
ConEmu version: 140819

1. View attached text in ConEmu (eg. in a ConEmuIzed FAR Manager :)
2. Set codepage 437 (United States)
3. Turn on/off "Enhance progressbars and scrollbars"

If "Enhance progressbars and scrollbars" is off then we can see characters between
ASCII-shade characters

If "Enhance progressbars and scrollbars" is on and only 1 character between same enhanced
characters, then enhanced characters "overwrites" middle character.


So, ConEmu kills the ART!!!

.
.
...I mean ASCII-art  ;^)

Reported by nanofoxxx on 2014-08-23 07:55:33

---

- _Attachment: [Enhanced_shades_bug_#1.txt](https://storage.googleapis.com/google-code-attachments/conemu-maximus5/issue-1692/comment-0/Enhanced_shades_bug_#1.txt)_

[Maximus5]

As of version 2015-03-03 32bit all grey enhanced chars are totally black :(

Progress of this bug-fixing going into the opposite direction :)

Reported by nanofoxxx on 2015-03-05 05:15:22

[Maximus5]

Hmm? Where is the problem?

Reported by ConEmu.Maximus5 on 2015-03-05 08:39:13

---

- _Attachment: 2015-03-05_11-39-00.png
_

[Maximus5]

Well, seems like this problem was solved in version 15/3/3 - probably gone with issue
#1923. See attached pic for the original bug!

But I still can't enjoy the art of ASCII, because of my special color setup - see attached
pic!

Do I need to open a new topic like "Support background-image behind enhanced shade
characters"? That would be the perfect solution :)

How hard to implement this on a 0-10 scale? Saying 0 means 5 mins, 10=95 man-years.

Many thanks for all the employees at ConEmu's support department ;)

Reported by nanofoxxx on 2015-03-08 11:42:55

---

- _Attachment: ConEmu_new_problem.png
_

[Maximus5]

bg == fg == 0
What is the profit?
Actually, I think in that case blending must be disabled.

Reported by ConEmu.Maximus5 on 2015-03-08 12:57:50

[Maximus5]

I don't remember exactly why I made this setup, maybe because of some commandline util
which output nice color text on a hard-coded black background which I wanted to override
(?)

Or I liked to preserve all colors (except black) to function as normal background color
(?) I never using black background color, so I choose this for background image (which
is a light-gray texture) and I using black text on it.

If I using a rarely used yellowish-brown color for background-image then shades will
get a yellowish-brown tone, however attached image must be _greys_only_.

Mixing background-image with foreground color is da final solution.

Until that I trying to live in peace with current behaviour :)

Reported by nanofoxxx on 2015-03-08 15:36:18

---

- _Attachment: This_must_be_grays_only.png
_

[Maximus5]

I do not think that suggested feature is good enough to be implemented.
Now, gray blocks are painted using solid color brushes. And this color may be easily
evaluated.
But your case... There is no easy way to multiplex any arbitrary background with gray
block brush. And I do not think it will be nice even if implemented.
I will disable feature for equal bg and fg.

Reported by ConEmu.Maximus5 on 2015-03-08 15:47:16

[Maximus5]

Don't spend Your time to disable case bg=fg, it's really minor priority.

Now I playing with colors and will came up another issue in minutes XD

Reported by nanofoxxx on 2015-03-08 17:05:12

[Maximus5]

Reported by ConEmu.Maximus5 on 2015-03-28 20:36:29

• Status changed: Fixed

[Maximus5]

...and You just fixed it - thank You!!!     :)

I not really understand why the _proper_ "Mixing background-image with foreground color"
is "not nice" in Your eyes (in chase of shadow chars). I like the challenges, so once
I will be an adult, old & wise Windows guru (...or in reality: i will have a little
time) I will implement it.

However now I using #7 (light gray) as background color, so this issue left to the
really  über-perfectionists 'problem' :)

Reported by nanofoxxx on 2015-03-29 17:26:03