Fix background select interpretation and 0:1 aspect ratio #6
Conversation
While a 0:0 aspect ratio is treated as an error, and falls back to the macro parameter value, a 0:1 aspect ratio is considered valid, and will round up to the minimum AR of 1:1.
The background fill only begins on the first line that outputs a sixel data value. So if the image starts with one or more DECGNL commands, they will need to be prefixed with at least one data value (potentially zero) in order to trigger a fill from the very top of the image.
The vertical extent specified in the raster attributes command should be given in screen pixels rather than sixel pixels.
This replaces the original (incorrect) zero size test with a test of the background fill when an image begins with one or more DECGNL commands. And the default/zero size test is incorporated into the last test case, which is intended to fill up to the screen boundaries.
There was a problem hiding this comment.
Ah! I had run into that problem with DECGNL not taking effect. So you're using ? to draw an empty sixel ("graphics space"), which seems reasonable. This is reminiscent of how we had to have a character to get the proper region to clear instead of the whole screen. I had been appreciating " for fixing that problem because of the nice symmetry with DECGRA, but it doesn't help in this case, whereas ? works for both.
Is there any other character or sequence that might be more generally useful as the "solution" for getting fill to do the right thing? For example, adding graphics carriage return, ?$, wouldn't ever be necessary, right?
|
Updated .png files are available with the results. |
Oh you mean always putting that at the start of the image when you don't know what might follow? That's not a bad idea. Although if you're optimising images to the extent that you're getting a solitary
Thanks for that, but what happened to the |
|
You're right. It should have been blue periods on white. I just ran the script again and it is white, not black, so I'm not sure what happened. I'll try running Media Copy again in 132- and 80-column mode and see if I can track it down. (As you may recall, background_select.sh in 80 column mode was the first screen image I found that consistently caused the VT340 to glitch when running Media Copy). |
OK cool. My one thought was the |
This PR fixes a bunch of issues in the way the background select is interpreted following our discussions in issue #5. It also includes a fix for the 0:1 aspect ratio which I had previously assumed to be an error (which would fallback to the macro parameter value), but is actually just rounded up to a minimum AR of 1:1.