#836 libgd: Fixes for minor issues introduced with patch 833 (dashtype support)

[Sethur]

Hi @sfeam,

While testing the plot area clipping implementation you proposed I came across some minor issues that have been introduced with my patch #833 (libgd oversampling => support for dashtype and better rendering).

I have created patches for these issues as well as accompanying documentation. I used LLMs to help with coding and documentation and thoroughly reviewed everything:

1. fix-libgd-thick-line-artifacts.mbox/md: There was an issue with the join discs being drawn when the angles between line segments were too large. Depending on line thickness and sampling rate, these joins were not drawn for very thick lines when they should have been, introducing visual artifacts (missing white pixels) like in the example image. The patch fixes this issue by making the condition on when to draw these joins depend on the line thickness.

2. fix-libgd-custom-and-dashtypes-greater5.mbox/md:
   2a) The pattern of the numeric dashtypes greater than 5 (i.e., beginning with dt 6) was wrong and not matching the pattern repetition of the cairo terminals. Before this fix, the dash patterns were repeating, but the solid line at position 6 was not being used. I changed this now to imitate the behavior of the cairo, but upon testing this, I found that the postscript terminal uses a totally different assortment of dash patterns, so maybe you want to adapt this to your liking for libgd.
   2b) The dashes of the custom dash patterns (like dt "._") were too long compared to cairo. This was originally introduced because with the empirical_scale of 0.25 used by cairo, small dash/gap-patterns would have been merged by libgd for small line widths. This patch fixes this issue and sets the length of these custom patterns to match cairo.

3. fix-libgd-screen-boundary-rounding.mbox/md: While staring at demo output, I found that, for example transparent_solids.dem, that draws a black rectangular thin border from screen 0.0 to screen 1.0, was missing the bottom and the right border line with the new libgd rendering approach. It turned out that the coordinate system with the new oversampling approach translated screen 1.0 to a coordinate outside of the image, which resulted in these lines not being drawn. The fix for this was a little more involved, because in the oversampled coordinate space, it matters whether you want to draw a line from pixel center to pixel center or fill an area when coordinates are converted back to image space.

[Sethur]

PS: I just found that fix-libgd-screen-boundary-rounding.md containes some references to a previous approach where I tried clamping the coordinates (which also worked but wasn't as clean). I have fixed that in the doc below.