#2619 sixeltek incomplete display and pattern fills

[Anonymous]

With the latest gnuplot snapshot, version 6.1 patchlevel 0, compiled with " --with-bitmap-terminals", and xterm under Linux compiled with "-enable-sixel-graphics", and

set term sixeltek
test

the display is incomplete (the lower horizontal line is missing) and the pattern fills for 4 and 5, and 6 and 7 are reversed. This used to be correct in gnuplot version 5.

Attached are the code differences in source/bitmap.c and term/tek.trm

[Ethan Merritt]

I have not looked at the sixeltek terminal for a long time. For me both version 5 and version 6 are basically unusable because the line types and color assignments are unstable, particularly the background color, which seems to flip to whatever line color was used last (which tended to make the axis and/or the plot itself invisible). This may well depend partly on the sixel emulator used to view the output, but there some places in the code that obviously needed updating. I had to revamp the color handling before I could try to reproduce or evaluate your specific points.

Fill patterns: Some time in between gnuplot 5 and 6 the guts of the terminal were replaced and/or merge with the generic bitmapped terminal code. The difference you point out in fill patterns is due to use of the patterns shared by all the bitmapped terminals, and yes it should be revised to agree with most of the other terminals. So that part is easy.

"Display is incomplete": I don't see this. Could it be a side-effect of the default terminal size not being a multiple of 8? That was, I think, unintended. I have reset it to 640x480 rather than 641x481. Or perhaps it is an artifact of the sixel emulator. What terminal emulator or viewing program are you using?

Anyhow, here is the commit message for an overhaul to the terminal in version 6.1. Almost all of the changes have to do with palette color assignment. The fixes to terminal size and fill pattern are comparatively minor. I also optimized the code in the innermost rendering loop, which sped up the display by about a factor of 2X on my desktop machine.

Please report back if this does not resolve the issues you saw before.

commit 63a38d8c9ba47ee9a7bcb75816a971a45c2758a1
Date:   Sun Apr 30 20:52:14 2023 -0700

    sixeltek:  rework assignment of palette colors, other glitches

    Apparently during the 5.5 development cycle, handling of colors in
    the sixeltek terminal became glitchy.  It is possible that some of
    the observed problems are dependent on the terminal emulator used
    to view the output, but some are clearly wrong.

    1) The blue RGB component of palette colors could overflow
    2) set_linetype did not handle linetypes < 0 (LT_AXIS, LT_BLACK, LT_BACKGROUND, ...)
    3) The first use of a palette consumed all remaining color slots,
       so no addtional linetype colors could be defined
    4) re-initialization of a palette ignored previously determined
       palette size
    5) The background color was unstable (would change between plots).
       I did not figure out exactly why this happened, but I don't see
       it any more after revising the palette code.
    6) The new discrete palette mode was not supported (commits 685c7a77 0f292b42 etc)

    Not palette related

    -  The default terminal size was 641x481 rather than 640x480.
       I think this was unintended.  It produced missing left and
       bottom borders on some sixel emulators (Bug #2619).
    -  The pattern fill sequence used by bitmap terminals differed from that
       of most other terminals.  The version 5->6 transition seems like a good time
       to bring them into agreement (Bug #2619).

[Erik Olofsen]

Thank you so much for your work on this term! I use it every day.

It could be that the decrement of SIXEL_YMAX and SIXEL_XMAX w.r.t. earlier sources solved the issue (the y size has to be a multiple of six). I will have a look, and also at the background color.

Currently a grid seems to be white (or the background color) instead of light gray.

While testing with fillcrvs.dem it seems that the colors for "Some sqrt stripes on filled graph background" and the next plot on the gnuplot website demo pages are not ok (at least with version 5.5)?

[Ethan Merritt]

What does "not OK" mean? It looks as expected here using set term sixeltek colors 256 from a KDE konsole window. Also fine using 16 colors from an xterm vt340 window.

[Erik Olofsen]

Yes, for that demo the sixeltek colors are as expected, and also the colors with pngcairo, but a red color is blue on the website demo page.

[Erik Olofsen]

Just an update: all demos seem to work quite well, but with the "test" command we see 1) that line 0 is white which I think should be black and 2) the filled polygons have different colors than with other terminals. In the test routine (in term.c) the colors of the polygons are selected with the "linetype" routine of terminal which I think possibly selects different colors than expected. I haven't figured out yet why these two things work differently compared to previous versions.

[Ethan Merritt]

I think you still haven't said what terminal emulator you are using, or what color options. For what it's worth here's a screenshot of what I see with "test".

Linetype 0 is used to draw the axes. Its distinguishing feature is that it is dotted, even on terminals that don't support general dot/dash patterns. The color is not specifically defined anywhere that I know of, so I don't think there is an expected result of linecolor 0.

I don't know why the polygon colors are what they are. The purpose of the test is to show whether the current terminal supports filled polygons at all, and if so what it does with transparent fill.

[Erik Olofsen]

The screenshot does show what I mean and it is the same with xterm that I'm using.

Linetype 0 is invisible because it is white but it used to be black and it is black with other terminals.

This occurs because the first two colors are now fixed in routine SIXEL_graphics(). But if all palette colors are made available, the colors with "test" are wrong. These are correct, including those of the polygons, if also routine SIXEL_linetype() is replaced by the previous version.

[Ethan Merritt]

Thanks for the big clue that this is a result of something in SIXEL_linetype() rather than SIXEL_set_color(). I have been staring over and over at the latter and not understanding how the axis color could be set to white rather than black. The answer turns out to be that the test routine dates back to when the gnuplot core code called term->linetype() directly. The rest of the code doesn't do that any more; it channels all linetype requested through a terminal-independent routine term_apply_lp_properties(), which separately applies the dash properties via term->dashtype() and the color properties via term->set_color(). It calls term->linetype() only to distinguish between "special" linetypes like LT_BACKGROUND, LT_NODRAW, etc. I had lost track of the fact that LT_AXIS was in that "special" class.

Fixed now.

That also explains the odd colors of the polygons and text samples in the sixeltek "test" output. Again the test command is calling term->linetype() directly rather than going via term_apply_lp_properties(). Maybe the test routine itself should be updated to use the current protocol.

[Erik Olofsen]

Thank you very much!!

And I agree; it would be good that the polygons have the same colors for all or most terminals with the test command.