bugGNU troff - Bugs: bug #51568, gropdf: Bug when string '\e014' is...

 
 

bug #51568: gropdf: Bug when string '\e014' is in the input

Submitted by:  Bjarni Ingi Gislason <bjarniig>
Submitted on:  Tue 25 Jul 2017 02:03:05 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: Deri James <deri>
Open/Closed: ClosedPlanned Release: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>
Project Member
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>
Project MemberIn charge of this item.
Thu 03 Aug 2017 11:22:48 PM UTC, comment #6:
Bjarni Ingi Gislason <bjarniig>
Thu 03 Aug 2017 10:14:18 PM UTC, comment #5:
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>
Project MemberIn charge of this item.
Sun 30 Jul 2017 08:04:23 PM UTC, comment #3:
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>
Project MemberIn charge of this item.
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:
Bjarni Ingi Gislason <bjarniig>

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 04 Nov 2017 11:09:02 PM UTCbgarriguesOpen/ClosedOpen=>Closed
    Wed 01 Nov 2017 04:09:18 AM UTCgbrandenStatusNone=>Fixed
      Assigned toNone=>deri
    Tue 25 Jul 2017 05:06:14 AM UTCwlSummarypropdf: 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.1-cleanup1