Re: Novel use of .char

[G. Branden Robinson]

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