Mailing-List: contact dev-help@pdfbox.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@pdfbox.apache.org
Received-SPF: pass (nike.apache.org: domain of eric.leleu.dev@gmail.com
 designates 74.125.82.42 as permitted sender)
MIME-Version: 1.0
Date: Wed, 7 Mar 2012 09:15:50 +0100
Message-ID: 
 <CALu5cuDtAvMcBX40dK=u496i3vczKWabZmqtnp7XJ6-FiBjnYw@mail.gmail.com>
Subject: Questions about toUnicode Cmap
From: Leleu Eric <eric.leleu.dev@gmail.com>
To: dev@pdfbox.apache.org
Content-Type: multipart/alternative; boundary=f46d0444033271920104baa2c494

--f46d0444033271920104baa2c494
Content-Type: text/plain; charset=ISO-8859-1

Hi all,


I'm currently working on the preflight issue PDFBOX-1236 [1]

The error seems to come from the management of the "toUnicode" CMap in a
Type0 font.

The "toUnicode" CMap overrides the "Encoding" CMap of the font. Due to this
behaviour,
the preflight validator receives the unicode value for each character code
present in a Text operator instead of the CID value present in the Encoding
CMap.

So I have two questions :
- Is the "Encoding overriding" the right thing to do ?
- Why the "toUnicode" Cmap is used to display text? According to my
understanding of the PDF References v1.7, the toUnicode CMap is used to
extract Text from a PDF File and to create a text file with unicode
characters. To display the text on a PDFReader, the font content and the
Encoding Cmap seem enough.

What is your point of view about these two points?

BR,
Eric

[1] https://issues.apache.org/jira/browse/PDFBOX-1236

--f46d0444033271920104baa2c494--