Hi Deri, At 2024-12-15T16:22:59+0000, Deri wrote: > On Saturday, 14 December 2024 19:42:00 GMT Peter Schaffter wrote: > > An undocumented use of the .char request is mapping a special > > character to a diversion holding a graphic image so the image can be > > used as a glyph. [...] > > I'm attaching GNU-head-small.png if anyone wants to test this out. > > The mapped diversion requires a glyph--any glyph--beforehand or it > > won't output in position (hence the whited-out period kludge). Can > > anyone explain why this is? > > Hi Peter, > > It looks like it is a regression (from 1.23.0) because if I remove the > "kludge" and change the GNU png to pdf (so it is compatible with > running 1.23.0) it works in 1.23.0 but is wrong in current. I also > tested using 1.23.0 groff and run the output through current gropdf > and the result was good. > > I can not find anything in the NEWS file regarding a change to .char > handling and all the regression tests are passing, so I presume this > is an unintended change of behaviour.
Yikes. Very likely it was unintended. I haven't done anything that I can recall to deliberately alter anything about diversion behavior, so I fear some spooky action at a distance going on here.[1] Time to pull on the bisecting gloves. The post-1.23.0 commit count is now well over 2,048 so, yay, an 11-step process awaits. Regards, Branden [1] I recall messing around a bit with error handling in the case of diversion overflow; that is, when you write several million lines of output to a diversion and exceed INT_MAX in the vertical drawing position. That *seems* like it should not be involved here.
signature.asc
Description: PGP signature