Hi @sfeam, as discussed I have split the DPI feature into several commits (each with their own mark down commentary): cairo/webp part libgd part cairo meta-data embedding webp meta-data embedding libgd meta-data embedding This should make it much easier to review the changes and select the ones you like. The libgd meta-data embedding is actually very straight forward. Cairo and webp are the ones that involve some not-so-nice byte-manipulation. I have also renamed the resolutionoption to dpito make...
Hi @sfeam, as promised, I have prepared two patches now regarding the plot area clipping in libgd terminals previously introduced by my dashtype support commit: One uncomplicated patch that just removes the plot area clipping completely, thus making libgd symmetric again in behavior to all the other terminals that also do not clip the plot area. Beware, however, that this can - for thick lines or points - look pretty ugly, as evident by the attached examples, where the Cairo output is unclipped (as...
Hi @sfeam, as promised, I have prepared two patches now regarding the plot area clipping in libgd terminals previously introduced by my dashtype support commit: One uncomplicated patch that just removes the plot area clipping completely, thus making libgd symmetric again in behavior to all the other terminals that also do not clip the plot area. Beware, however, that this can - for thick lines or points - look pretty ugly, as evident by the attached examples, where the Cairo output is unclipped (as...
PS: I am confident that this solves bug #2316 , since this bug describes exactly the warning message problem that this patch is trying to solve.
Hi @sfeam, your suggestion of using deleting problematic characters from the output text was the right idea. I have implemented this now using blank spaces, as they can be used in the enhanced text path without changing byte offsets in PangoAttrList. If multi-byte glyphs are encountered, they are overwritten with the appropriate amount of spaces. This will likely make the text wider in many instances, but I think this would be an acceptable workaround. Your other suggested replacement glyphs are...
Hi @sfeam, I have: rebased the patch onto master made the grace period (on Windows only) into a global constant and increased it to 5 seconds shortened the commit message recompiled and tested everything on Windows Feel free to increase the Windows grace period even further. I thought if it takes longer than 5 seconds, it's warranted that the warnings is shown. EDIT: Replaced the patch file, the previous one did not include the changes listed above.
Hi @sfeam, I have: rebased the patch onto master made the grace period (on Windows only) into a global constant and increased it to 5 seconds shortened the commit message recompiled and tested everything on Windows Feel free to increase the Windows grace period even further. I thought if it takes longer than 5 seconds, it's warranted that the warnings is shown.
Understood, I will split the patch and hopefully submit them here within the next week. Regarding your ideas on how to present this to the user: Currently, the user indeed has to specify both a physical size and a resolution to trigger the dpi render path. Previously, if the user specified a physical size (instead of pixels), the physical size was just transformed to pixels assuming 72 DPI and everything else stayed the same. One more thing that we could integrate into the patch would be allowing...