Re: Release critical or not? [was Re: strange box-offset]

[<br...@ph...>]

Ethan A Merritt wrote:

> The length in pixels of a line that starts at pixel x1 and ends at pixel x2
> is (x2-x1)+1.   So this code looks correct to me.  It may well be that some
> terminals interpret w and h incorrectly, but that would be an error in the
> individual terminal driver, not the core code. 

It can't really be an error --- for the simple, if somewhat shameful 
reason that the terminal API fails to actually specify what the 'width' 
paramter of the fillbox call is supposed to mean.  In other words, we're 
staring directly into the face of a serious design flaw.  That'll need 
to be ironed out.  The only open question is: is it urgent enough to 
warrant delaying the release?  I don't think so, based on the ratio of
exposure versus complaints about this feature.

> IMHO an off-by-one-pixel error is not release-critical, however.

On the GUI terminals, it rather probably isn't --- they all effectively 
oversample, so the error is actually smaller than one pixel.  The 
critical ones are the pure pixel formats (which don't oversample), and 
the vector-based ones (because they may get zoomed up uncontrollably, 
later).

Which reminds me: in a certain light, this is a re-play of that bug 
concerning microscopic gaps in pm3d maps and colourboxes caused by 
aliasing artefacts, in our PostScript output rendered by Ghostscript.

> If there's a simple fix to the core code that makes things more consistent,
> fine.

I doubt there can be.  Such a fix would almost certainly be wrong for 
about as many terminal drivers as it might help.

 > But if we need to poke about in all the individuals drivers, let's
> not do this for 4.2.

Good point.  This can become a first TODO list item for post-4.2.