You seem to have acquired a pretty good grasp of the subject matter already, so I'm not sure I'm telling you anything new...

Anyhow, the problem you have is most likely related to font subsetting, because embedded fonts are typically also subsetted these days.  I've tried to explain in some more detail what the issue is in Re: CAM::PDF did't extract all pdf's content, so you might want to read this first. The next thing would be to find out whether you actually have those reverse mapping tables I mentioned in that node.  Note that they're optional; in other words, they're not required to render the fonts' glyphs (i.e. the text) properly (and I've more than once come across PDFs that didn't have them — presumably on purpose, to make it harder to mechanically extract the content...).

Unfortunately, if you don't have those mapping tables, you're pretty much out of luck, because you'd have to generate them manually yourself, character for character (or maybe with the help of OCR, though I'm not aware of any ready-made tool for that purpose).

In order to find out, either look at the PDF source (the respective objects should be referenced from the font descriptor via a dictionary entry named /ToUnicode), or check if Acrobat Reader's text tool can in fact extract selected text (cut-n-paste the selection into an editor, or some such). In case the tables are just not there, it won't be able to extract the text either.

Once you've verified you have the tables, I'm afraid there's still work to do, i.e. write code that reads those tables and maps the subsetted encoding back to unicode.  AFAIK, PDF::API2 doesn't have support for this (it's more geared towards generating PDFs, rather than extracting content from existing PDFs), and I'm not aware of any other CPAN module that would help here either (though it's a while since I've last checked, so you might want to re-check recent additions to CPAN).

9.2.2 Basics of Showing Text
EXAMPLE 1
This example illustrates the most straightforward use of a font. The t
+ext ABC is placed 10 inches from the bottom of the page and 4 inches 
+from the left edge, using 12-point Helvetica.

BT
    /F13 12 Tf
    288 720 Td
    (ABC) Tj
ET

The five lines of this example perform these steps:
a) Begin a text object.

b) Set the font and font size to use, installing them as parameters in
+ the text state. In this case, the font resource identified by the na
+me F13 specifies the font externally known as Helvetica.

c) Specify a starting position on the page, setting parameters in the 
+text object.

d) Paint the glyphs for a string of characters at that position.

e) End the text object.
[download]

Thanks for the suggestion desemondo!
I've been leaning very heavily on the Adobe document you referred to (especially the section you referenced) and I had actually seen that example too. Unfortunately it doesn't really help with my problem because my issue is PDF::API2-specific.

I guess it might be helpful to rephrase my question: how do I use PDF::API2 to "import" the fonts that are embedded in a PDF so that I can map the character IDs used in the content stream to unicode code points (which can then be assembled into words and sentences...etc.)?

To put the question in perspective, here is a simple example of what I'm dealing with. In the example you supplied, the characters "ABC" are in a known encoding. They would be encoded in the PDF exactly as the example states. However I am dealing with PDFs that do something like:


BT
/F13 12 Tf
288 720 Td
[<01>4<02>-1<03>-1<04>-1<05>2<06>] TJ
ET
[download]

I need a way to use PDF::API2 to map the character IDs (the things between the angle brackets) to unicode code points...

as a side note, there is a PDF::API3 available on CPAN.

I have used CAM::PDF mainly for the tasks of extracting text. However, I have had little luck with embedded html in pdfs. You may be able to walk the root dictionary of the pdf using CAM::PDF and store information you need. There is also a module CAM::PDF::Renderer::Text that may be of some help