Talk:Sixel

ADD A PICTURE

Please add a picture of what the example code renders.

-128.61.124.56 (talk) 09:27, 30 November 2010 (UTC)

Done! In case you're still around, anonymous commenter from 2010... Autopilot (talk) 03:26, 25 March 2016 (UTC)

Supporting models

The two terminal models previously mentioned in the introductory paragraph did not support sixel. Fixed that to VT330 and VT340. According to xterm (which also supports sixel graphics since ~304), supporting models were VT240, VT241, VT330, VT340 and VT382. For VT240, however, I could not find sixel mentioned in the manual. — Preceding unsigned comment added by Towopedia (talk • contribs) 12:12, 14 May 2014 (UTC)

There are plenty of references to sixel support on the VT240 -- including section 4.18.1 of the VT240 Series Programmer Reference Manual, EK-VT240-RM-002. 99.122.168.208 (talk) 09:35, 24 February 2016 (UTC)

A closely related question: does this mean that the VT240 was the first model to introduce sixel graphics, or did the VT125 or GIGI support them also? 74.125.122.49 (talk) 22:33, 3 July 2016 (UTC)

Can the horizontal location of the sixel be controlled?

According to the DEC document, you can skip down with "-" and return to the beginning of the line with "$". This all seems to work in xterm. But how do you skip to the right without overwriting the background color?

Do you have to query Xresources to retrieve the background color and then plot that color before each line? But this feels perhaps not reliable. Plus, how do you selectively update a portion of the window if all newly painted sixels cast a shadow on everything to the left?

Found it: "?" character. — Preceding unsigned comment added by 108.185.180.195 (talk) 20:16, 22 August 2017 (UTC)

I think the example needs to be expanded to show how to overlap the sixels on normal ANSI/text images. — Preceding unsigned comment added by 108.185.180.195 (talk) 22:44, 22 August 2017 (UTC)

When sixel scrolling is enabled, the current cursor location determines where the image begins. Transparent parts of the image will allow the original content to show through, whether that is text, a previous sixel image, or a ReGIS graphic. On emulators the text size can typically be changed on the fly (retroactively updating existing text), and there is no standard on the text size, so it's hard to know exactly how the composed screen will look in a portable way. --77.56.99.18 (talk) 23:16, 29 October 2017 (UTC)

Can the coordinate system be automatically calibrated?

In most sixel programs in use in 2017, there is some sort of calibration phase to align the sixel (0,0) with the ANSI (0,0). The coordinate transform depends on things like xterm scrollbar width and side, inside window border, and font size. Is there some standard installed library API to automate this calibration?

When sixel scrolling is disabled, images are always placed in the upper-left of the screen. When it is enabled the cursor location is used. If the location is 0,0, there shouldn't be any need for calibration. If the scrollbar or window border affects the image alignment, this is probably a bug. The font size shouldn't control the alignment of 0,0, but it would affect the mapping of the other parts of the image to the text. --23:31, 29 October 2017 (UTC)77.56.99.18 (talk)

The "-" character is not the LF portion of CRLF

The portion after the semicolon in this sentence of the Description section seems to be factually incorrect:

Carriage return (CR) is represented by $, and line feeds (LF) with a -; both had to be sent in turn to return the cursor to the start of the line, CRLF.

Both references linked in the article name the "-" character's operation as "New Line", and itself performs the full action of both moving to the next line and returning to the left side of the rendering area. A CRLF-comparable "$-" combination is not required, nor used in the main example in this article. Edits to correct this have been reverted, so I'd like to see some discussion on its clarification. — Preceding unsigned comment added by 70.166.159.104 (talk) 19:42, 19 October 2020 (UTC)

The previous edit asserted that "newline" was the term used by both sources. That's factually incorrect. One omitted the term, the other commented that it was "newline-like". The relationship between the Unix newline and various graphics documentation for "new line" is more or less coincidental, and implies that the Unix jargon in some sense influenced the other (not a credible line of discussion) TEDickey (talk) 20:18, 19 October 2020 (UTC)

Sure, the naming is a separate issue and the lack of space between the words could incorrectly draw a link to Unix, but the linked Newline article is named without a space and is not Unix-specific. But the description of the sixel operation is plainly wrong, as demonstrated in the references and article example, and is the primary issue I'd like to see corrected in the article: A CRLF-like pairing of "$" and "-" is not required to perform a new line operation, but rather a lone "-" character performs the entire operation. The "$" is redundant in any "$-" pair.

As far as the naming goes, the reference manual clearly titles it "Graphics New Line (-)", so abbreviating it as "GNL" might be an appropriate alternative to distinguish it from existing NL or LF connotations; "Graphics Carriage Return ($)" could then benefit with a corresponding change to "GCR" as well. However, these would be unique to the article, and might not be a great idea. Not having CR/NL/LF/etc abbreviations at all and simply using the "$"/"-" characters themselves might be best to avoid misrepresentation. 70.166.159.104 (talk) 21:09, 19 October 2020 (UTC)

I suggest quoting the definitions for Graphics Carriage Return and Graphics New Line, comment that in most terminals those functions are control characters (but that the data-string is limited to certain printable characters) and explain that "active position" is analogous to a computer terminal's cursor (pointing that that they're not synonymous would confuse the reader). Mentioning CR and CR/LF would work at that point. The typical user is confused by the Enter key on a keyboard (sending CR and "echoing" CR/LF), so going very deep at that point would again add to confusion. TEDickey (talk) 22:57, 20 October 2020 (UTC)

As it happens, the unsigned IP address above who had his/her edits reverted was correct. The Graphics New Line ('-') works like the Unix Newline. It does both Carriage Return and Line Feed. I am pretty sure this is explicitly stated in the DEC VT340 documentation. Ben (talk) 22:47, 8 September 2021 (UTC)

See the top of page 237 in the Programmingreference. It doesn't say what the IP-editor asserted. As usual, a verifiable reliable source is the way to go. Talk pages (like Wikipedia topics) are not reliable sources TEDickey (talk) 23:23, 8 September 2021 (UTC)