[cairo-bugs] [Bug 13679] Error-prone eexec stream in PDF

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=13679





------- Comment #3 from ajohnson at redneon.com  2007-12-15 21:33 PST -------
(In reply to comment #2)
> eexec encoding has special means to avoid undesirable characters in the 1st
> position; there's no need to add spaces. I forgot about this feature.

So just to check that I understand this problem correctly:

  The '\r' character is the first ciphertext byte of the Private
  dictionary.  In PDF files where the eexec-encrypted text is
  embedded in binary some PDF interpreters treat the '\r' as part
  of the white space between the 'eexec' and the start of
  the eexec-encrypted text.

Is that correct?

When cairo subsets Type 1 fonts it just copies (after decrypting then
encrypting) all of the original Private dictionary from the start up
to "/CharStrings" to the subsetted font before it starts filtering out
unused glyphs. I don't have the exact same version of that font to
check but unless there is a bug in cairo it appears that the '\r'
resulted from the choice of the four random bytes required to be
inserted at the Private dictionary in the original font. However
section 7.2 of Adobe Type 1 Font Format requires the first four
plaintext bytes to be chosen so that the first cipertext byte is not
whitespace.

Should cairo be checking and if necessary modifying the four random
bytes of plaintext to ensure that the first ciphertext byte is not
white space?  Or is this bug in the font?


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.