Ethan Merritt

Cairo terminal thoughts a) Everything pertaining to cairo (and maybe webp, as it is directly connected) b) Everything pertaining to libgd c) All the metadata injection. Would this work better for you? Yes. I'd like to see a patch that has just the cairo terminal changes to support the dpi adjustment. I agree it may end up being a rather small patch. I am dubious that the metadata is worth it unless it can be done via a library call, which I gather cairo does not offer. It may be worth discussing...

[PATCH 6/8] Fix libgd clipping and libgd/cairo border rendering I have extracted and committed the parts of this patch that add term->path to the cairo terminals and gd terminals. Thanks.

Now for the goal and what we are trying to achieve: The main issue is that right now, the raster terminals are not very useful any more if you are working with high-DPI monitors, which is getting more and more common. A plot that looked great previously on monitors that were using resolutions below 100 DPI will not work any more for today's Retina, 4K, etc. displays. I don't get it. When or why would someone use one of the gnuplot raster terminals on a high-DPI monitor rather than a vector-based...

armillary.dem works for me without any missing glyphs, so the patch is not relevant. I.e. the glyph/font support provided by some underlying library (in my case libfontconfig) is also a contributing factor. charset.dem does indeed show that the patch removes over-large garbage from the output; note, however, that since the entire point of the demo is to determine what can or can not be printed with the current settings a better solution might be to simply skip the unavailable characters altogether...

3) Very complicated changes that may have wandered off target [PATCH 1/8] Implement DPI-scaling for libgd, cairo and web raster Is there really a problem here that needs to be fixed? If so, is this the right approach? I understand that there is a mismatch between font sizes specified in points and output to a pixel-based rather than vector-based format. In the absence of a specified dpi the font size is not well-defined. I also understand that it is common that the user wants to specify a size in...

2) Somewhat complicated changes that may fix a known problem [PATCH 4/8] Fix slow QT font-metric initialization and noisy warning good: I will be delighted if you can help clear some of the known Windows-specific issues, with or without LLM assistance. From the comments I take it that this commit may fix open bug 2316 "Slow font init" with every first qt plot in a session (Windows) and possibly also 2476 font problem on qt terminal on windows bad: The LLM analysis does not find or at any rate does...

I think I am learning a bit about the good and bad of LLM-assisted patch evaluation. This set of patches falls into several categories. Simple fixes for simple errors Somewhat complicated changes that may fix a known problem Very complicated changes that may have wandered off target I will try to sort the contributions here accordingly, but let me start with one that doesn't work for me. [PATCH 5/8] Fix oversized Pango hex box rendering with cairo Does not work in my testing. The huge missing-glyph...

1) Simple fixes for simple errors [PATCH 3/8] Fix Adobe glyph name truncation in PostScript terminal good: The patch to post.trm corrects a string length error introduced by an earlier commit that replaced strncpy with safe_strncpy in many places, but got the length wrong (entirely my fault). The fix is obviously correct. I've applied it. Thanks. bad: The analysis of where the bug came from is wrong. It is not a "long-standing bug present since the UTF-8/glyphshow support was added in 2007 (Thomas...