groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Novel use of .char


From: Deri
Subject: Re: Novel use of .char
Date: Sun, 15 Dec 2024 16:22:59 +0000

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

Attachment: GNU-head-small.pdf
Description: Adobe PDF document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]