4 ms·

Tv pushes the rendering further by using more unicode characters. It also uses GDAL as a backend which allows subsampling of massive images and access to many s

Tv pushes the rendering further by using more unicode characters. It also uses GDAL as a backend which allows subsampling of massive images and access to many scientific image formats (GeoTiff, NetCDF, JPEG2000, etc)

JdeBP 10y ago
Some other differences are given at https://news.ycombinator.com/item?id=13906483 https://news.ycombinator.com/item?id=13906483 . One problem that all of these programs share is something that you cannot really do much about absent user-supplied information, since it is something that isn't exposed in the abstraction of a POSIX General Terminal Device. It is probably more acute for tv than for the others, albeit that as I have mentioned I couldn't get tv to actually run without error to see what the effect is. This problem is that there is a baked-in assumption about the glyphs of the characters. This is not the usual concern that glyphs are different shapes in different fonts. That's not really much of a concern for box drawing and block graphic characters. The baked-in assumption is that glyphs are rectangular, with a 1:2 aspect ratio. This is the assumption that underpins the idea that U+2580 is two square pixels, one atop the other. But this is not true even for 9x15 fonts, which yield a slight distortion with all of these programs, let alone for yet squarer fonts. Barack Obama looks very odd indeed when U+2580 is actually a 16x16 or 32x32 square, as it sometimes is. (http://fileformat.info/info/unicode/char/2580/fontsupport.htm http://fileformat.info/info/unicode/char/2580/fontsupport.ht... shows several square appearances, and it is square in one of the fonts that I use here.) tv, with the way that it already works, is probably best placed to incorporate user-supplied information about the font's character cell aspect ratio. pxl could probably be extended fairly simply, too. The others including timg, I suspect would be harder. Interestingly, M. Zeller has had an open issue about this for timg since 2016. * https://github.com/hzeller/timg/issues/4 https://github.com/hzeller/timg/issues/4

JdeBP 10y ago

Some other differences are given at https://news.ycombinator.com/item?id=13906483 https://news.ycombinator.com/item?id=13906483 . One problem that all of these programs share is something that you cannot really do much about absent user-supplied information, since it is something that isn't exposed in the abstraction of a POSIX General Terminal Device. It is probably more acute for tv than for the others, albeit that as I have mentioned I couldn't get tv to actually run without error to see what the effect is. This problem is that there is a baked-in assumption about the glyphs of the characters. This is not the usual concern that glyphs are different shapes in different fonts. That's not really much of a concern for box drawing and block graphic characters. The baked-in assumption is that glyphs are rectangular, with a 1:2 aspect ratio. This is the assumption that underpins the idea that U+2580 is two square pixels, one atop the other. But this is not true even for 9x15 fonts, which yield a slight distortion with all of these programs, let alone for yet squarer fonts. Barack Obama looks very odd indeed when U+2580 is actually a 16x16 or 32x32 square, as it sometimes is. (http://fileformat.info/info/unicode/char/2580/fontsupport.htm http://fileformat.info/info/unicode/char/2580/fontsupport.ht... shows several square appearances, and it is square in one of the fonts that I use here.) tv, with the way that it already works, is probably best placed to incorporate user-supplied information about the font's character cell aspect ratio. pxl could probably be extended fairly simply, too. The others including timg, I suspect would be harder. Interestingly, M. Zeller has had an open issue about this for timg since 2016. * https://github.com/hzeller/timg/issues/4 https://github.com/hzeller/timg/issues/4