bugGNU roff - Bugs: bug #51568, [gropdf] should protect glyph...

 
 

bug #51568: [gropdf] should protect glyph sequences that look like octal character escapes \ddd

Submitter:  Bjarni Ingi Gislason <bjarniig>
Submitted:  Tue 25 Jul 2017 02:03:05 AM UTC
   
 
Category:  Driver gropdf Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  Fixed
Privacy:  Public Assigned to:  deri
Open/Closed:  Closed Planned Release:  1.22.4
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 01 Nov 2017 04:09:18 AM UTC, comment #8: 

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 '\'.

G. Branden Robinson <gbranden>
Group administrator
Thu 03 Aug 2017 11:50:38 PM UTC, comment #7: 

Oh dear! I think I have nailed the octal character problem now, about to check in the fix. I spotted the undefined warning yesterday, and it was included in the patch attached to bug 50989. I will be including it also in the fix I upload today.

Deri James <deri>
Group Member
Thu 03 Aug 2017 11:22:48 PM UTC, comment #6: 


  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;


Bjarni Ingi Gislason <bjarniig>
Thu 03 Aug 2017 10:14:18 PM UTC, comment #5: 


Still a bug in gropdf

  The escape (\e) is not printed if a character with a code < 9 is in the
same word.

.pl 20
Print \eC\[aq]abc\[aq]
.br
\eC\[ha]a\[ha]
.br
\eC\[ti]ab\[ti]
.br
\eC\[tm]abc\[tm]
.br
\eC\[tm]abcd\[tm]
.br
\eC\[eu]abcd\[eu]
.br
\eCa\[tm]abc\[tm]
.br
\eCab\[tm]abc\[tm]
.br
\eCabc\[tm]abc\[tm]
.br
\eCabcd\[tm]abc\[tm]
.br
\eCabcdefgh\[tm]abc\[tm]
.br
\eCabcdefghijkmnopqrstuvwxyz\[tm]abc\[tm]
.br
\eCabcdefghijkmno\c
pqrstuvwxyz\[tm]abc\[tm]
.br
\eCabcdefghi
jkmnopqrstuvwxyz\[tm]abc\[tm]
.br
A\[tm]abc\eC


Bjarni Ingi Gislason <bjarniig>
Mon 31 Jul 2017 03:48:40 PM UTC, comment #4: 

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.

Deri James <deri>
Group Member
Sun 30 Jul 2017 08:04:23 PM UTC, comment #3: 


Subject: The fix of bug #51568 is too specific

  This was discovered in "groff.7".

  Testfile:

.pl 10
Octal number 1: \e01, \e001
.br
Octal number 7: \e07, \e007
.br
Octal number 8: \e10, \e010
.br
Octal number 9: \e11, \e011
.br
Octal number 33: \e41, \e041
.br
Print an escape \e isolated.
.br
Print an escape at the end of a line\e
Next line

  Command:

groff -Tpdf

  Output:

  Lines with "Octal number" show '\' and the glyph in the first column and
the octal number in the second (\0xx)

  Lines with input "\exx" have '\\\' instead of just '\\' in the PDF file.

  Conclusion:

  Where '\' is in the intermediate output, there must be a '\\' in the PDF
file.  That is independet of what follows.

  This should at least be valid for the intermediate output whose lines begin
with the command 't' or 'u'.

N.B.
  I don't think, that the intermediate output ever contains an octal number
(\0...) that has to be interpreted by the postprocessors to be somethings
else than a text string, namely literatim "\0...".


Bjarni Ingi Gislason <bjarniig>
Tue 25 Jul 2017 12:03:44 PM UTC, comment #2: 

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.

Deri James <deri>
Group Member
Tue 25 Jul 2017 02:08:07 AM UTC, comment #1: 

  The name is "gropdf" not "propdf"!

Bjarni Ingi Gislason <bjarniig>
Tue 25 Jul 2017 02:03:05 AM UTC, original submission:  


  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.




Bjarni Ingi Gislason <bjarniig>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bgarrigues (Updated the item)
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by deri (Posted a comment)
  • -email is unavailable- added by wl (Updated the item)
  • -email is unavailable- added by bjarniig (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-01-22 gbranden CategoryNone Driver gropdf
        Item GroupNone Incorrect behaviour
        Planned ReleaseNone 1.22.4
        Summarygropdf: Bug when string '\e014' is in the input [gropdf] should protect glyph sequences that look like octal character escapes \ddd
    2017-11-04 bgarrigues Open/ClosedOpen Closed
    2017-11-01 gbranden StatusNone Fixed
        Assigned toNone deri
    2017-07-25 wl Summarypropdf: Bug when string '\e014' is in the input gropdf: Bug when string '\e014' is in the input

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code