[gs-bugs] [Bug 691661] pdfclean writes pdf with missing japanese fonts when given -g option

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Sat Oct 2 14:42:57 UTC 2010


http://bugs.ghostscript.com/show_bug.cgi?id=691661

--- Comment #6 from Benjamin Ullian <bullian at factset.com> 2010-10-02 14:42:56 UTC ---
You are correct - the bug i noticed was with the single -g argument on the 0.7
TAG, but I checked out the latest git sources and the problem is no longer
reproducable if i compile those.

Digging into the PDFs, it seems the PDF hex strings <...> were coming out
entirely differently in the 0.7 TAG, perhaps it was a decryption issue?



Most strings in these pdfs are UCS2 and so should, upon decryption, begin with
a BOM (FE FF .... ) . Here's an example of a bookmark where the 0.7 TAG version
of pdfclean was obviously incorrect:

(from input pdf #1, line 7080, object 693 0)
/Title <15ADBE3CE202>  (this is Arcfour encrypted)


(from TAG 0.7 cleaned pdf #1, line 4853, object 693 0)
/Title<32274D4C7C35>  ( no BOM .... )


(from git-bleeding-edge cleaned pdf #1, line 4853, object 693 0)
/Title<FEFF88687D19>  (notice the BOM -- this is correct)

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


More information about the gs-bugs mailing list