Reported fixed in git HEAD.

commit eaf4526d8c3d52a46f95bdfc06ac692f9d5b424f
Author: Deri James <deri@chuzzlewit.myzen.co.uk>
Date:   Fri Aug 4 00:56:22 2017 +0100

    See bug at: https://savannah.gnu.org/bugs/?51568
   
    * src/devices/gropdf/gropdf: Further 'fix' to handle those octal
    characters. See comment #5 - thank you Bjarni.

commit 6a241192be60d0cc1a2ab5464281e297b2c0243d
Author: Deri James <deri@chuzzlewit.myzen.co.uk>
Date:   Mon Jul 31 17:02:02 2017 +0100

    See bug at: https://savannah.gnu.org/bugs/?51568
   
    * src/devices/gropdf/gropdf: previous 'fix' was too narrow, all
    '\' characters should be escaped. Also there was an unwanted
    interaction with code in routine 'do_t'. Sometimes, do_C, when
    the named glyph is mapped to a chr < 32, this is encoded as
    octal \nnn, so in this case the '\' must not be escaped.

commit 67c3d46d452ce05082839920a8058091a8797583
Author: Deri James <deri@chuzzlewit.myzen.co.uk>
Date:   Tue Jul 25 16:43:54 2017 +0100

            If input text contained string which could be interpreted as
            escaped octal (\ddd) a pdf viewer would interpret as an octal
            character.  See bug at: https://savannah.gnu.org/bugs/?51568
   
            * src/devices/gropdf/gropdf: protect text which resembles \ddd
            by escaping with extra '\'.

  There is also warning when gropdf is compiled (and used):

Use of uninitialized value in substitution (s///) at /home/bg/git/groff/gropdf line 2947, <> line 10056.
Use of uninitialized value in substitution (s///) at /home/bg/git/groff/gropdf line 2948, <> line 10056.
Use of uninitialized value in substitution (s///) at /home/bg/git/groff/gropdf line 2949, <> line 10056.
Use of uninitialized value in substitution (s///) at /home/bg/git/groff/gropdf line 2950, <> line 10056.

  And repeated

  Source (gropdf):

        next if $wd->[0]=~s/\\\|!\|/\\/g;
        $wd->[0]=~s/\\/\\\\/g;
        $wd->[0]=~s/\(/\\(/g;
        $wd->[0]=~s/\)/\\)/g;

Yes, the fix needs to be more generic. However, in some situations the driver itself uses the octal \nnn markup. When a named glyph is sent, if it occurs in the first 32 font positions, or it occurs after position 255 and is then remapped to a position < 32 then the octal is used and the ’\' must not be escaped.

I am preparing another fix.

Looking inside the pdf (groff -Tpdf -P-d test | less) I see:-

0.000 Tw [(Octal character code "\014" for a form feed.  Alternati)] TJ

So gropdf has passed through the text "as is". The PDF Reference says:-

=================================================================

The \ddd escape sequence provides a way to represent characters outside the printable ASCII character set. For example:

  (This string contains \245two octal characters\307.)

The number ddd may consist of one, two, or three octal digits, with high-order overflow ignored. It is required that three octal digits be used, with leading zeros as needed, if the next character of the string is also a digit. For example, the literal
 
  (\0053)

denotes a string containing two characters, \005 (Control-E) followed by the digit 3, whereas both

  (\053)

and

  (\53)

denote strings containing the single character \053, a plus sign

  (+)

=================================================================

So it is the viewer which must interpret the string as a reference into the font, 12 has no glyph attached so nothing is printed.

If you change to "\e104" in the test file you will see "D".

The gap after "Alternati" is because gropdf has calculated the string length from the four characters which make up the string but the viewer is displaying nothing for it.

If I manually change in the pdf to "\\014" it goes back to looking normal. So I suspect the fix is to look for the pattern \\(\d{1,3}) (AFTER gropdf has calculated the string length) and prefix with a '\'.

I will prepare a patch.

  Input file (seen in "ispell.1"):

.pl 5
Octal character code "\e014" for a form feed.
Alternatively, if "n" appears in the character string

  Command:

test-groff -Tpdf <Input file> > <output>

  "xpdf <output>" shows somthing like:

Octal character code "" for a form feed.  Alternati    vely, if "n" appears in the character string

  The string '\014' is missing.

  There is a gap in the word 'Alternatively'

  "gv" instead of "xpdf" shows the same result.

  Using '-Tps' instead of '-Tpdf' gives a correct result.