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. > > === > .\" 1.23.0.2146-d958f-dirty > .\" Build with pdfmom(1); output to pdf > . > .sp 6P-1v > . > .nr img-w 25p > .nr img-d 22p > . > .di img-div > .ev img-div > .nf > \X'pdf: pdfpic GNU-head-small.png' > .ev > .di > . > .char \[img] \h'-\w'.'u'\m[white].\m[]\*[img-div] > . > .ds gnu \v'-\n[img-d]u'\[img]\h'\n[img-w]u' > . > .nop A GNU head \*[gnu] image. > === > > 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. Cheers Deri
GNU-head-small.pdf
Description: Adobe PDF document
