Fixes

[t-bltg]

@johnnychen94, I had to merge #1 to setup CI.

If you could review #1, I could release the initial version in https://github.com/JuliaRegistries/General (there is a mandatory period of 3 days), and work on the wrapper TerminalImages.jl afterwards.

I you require any changes, I'll push the fixes in this PR.

[codecov]

Codecov Report

Merging #2 (7464534) into master (5b5aeba) will increase coverage by 1.47%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master       #2      +/-   ##
==========================================
+ Coverage   96.77%   98.24%   +1.47%     
==========================================
  Files           4        3       -1     
  Lines         124      114      -10     
==========================================
- Hits          120      112       -8     
+ Misses          4        2       -2     

Impacted Files	Coverage Δ
src/encoder.jl	100.00% <ø> (+2.63%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5b5aeba...7464534. Read the comment docs.

[t-bltg]

@johnnychen94, ok for initial release ?

[johnnychen94]

@johnnychen94, ok for initial release?

See #3 (comment), I believe it's easier to use by making enc a keyword argument small_block.

Also, the color mode stuff seems to belong to TerminalImages where we query the terminal information and provides smart adaptive handling. It's not used here, so might just remove them.

The docstrings also need a revisit before releasing.

[t-bltg]

See #3 (comment), I believe it's easier to use by making enc a keyword argument small_block.

I don't see how you can do that. We'd need downscale, restrict and this got removed.

Also I think TermColor256 should be renamed to TermColor8bit as it is not consistent with TermColor24bit.

Also, the color mode stuff seems to belong to TerminalImages ...

Removed.

[johnnychen94]

I think it's because we enforced a canvas concept for BigBlocks and SmallBlocks and drops out-of-canvas values in

XTermColors.jl/src/encoder.jl

Lines 133 to 141 in 7464534

	if n < w # right part
	_printc(io, RESET, " … ")
	for i in ((-n + 1):0) .+ lastindex(img)
	color = img[i]
	fgcol = color_enc(color)
	chr = _charof(alpha(color))
	_printc(io, Crayon(foreground = fgcol), chr, chr, " ")
	end
	end

That should be part of TerminalImages.jl, I believe.

The idea of XTermColors is to support a faithfully decoding of the xterm_24bit_encode result without knowing the canvas(runtime) information -- if there's … in the middle of the encoded result, then we loss the data.

[johnnychen94]

Also I think TermColor256 should be renamed to TermColor8bit as it is not consistent with TermColor24bit.

Maybe, The name TermColor256 is perhaps based on the observation that most people uses the term "xterm-256 color" instead of "xterm-8bit" for this color setting.

[johnnychen94]

Currently busy with other tasks, I can revisit it this weekend if you don't have plans to do the decoding part.

[t-bltg]

That should be part of TerminalImages.jl, I believe.

I think I'll leave the rewrite in your hands, since I'm afraid my vision on this is kinda blurry.

Maybe, The name TermColor256 is perhaps based on the observation that most people uses the term "xterm-256 color" instead of "xterm-8bit" for this color setting.

Sure, we know the internals as when taking 8bits, we can encode 2^8 = 256 colors. What I mean is that since this package is low level it should be imo the other way around and name it with ..._8bit in the sources and maybe alias it once to 256 for exporting (but I don't think this is necessary, again, since this package is a low level encoder), as it would be more consistent this way.

Currently busy with other tasks, I can revisit it this weekend if you don't have plans to do the decoding part.

Sure, I have limited time and very few will to do that.