On 29-Aug-05 FX Fraipont wrote:
Maura Edelweiss Monville wrote:
I downloaded Acroread 7.0 from the site you indicated. I still have Acroread 6.0 installed. Shall I uninstall the current version before installing the new one through Yast ? To install the new version is the following command right:
#rpm -Uvh AdobeReader_enu-7.0.0-2.i386.rpm
yes. Uninstalling 6 is not necessary.
But wait, I'm trying out the various solutions I proposed on the file you sent, and they are NOT convincing to say the least ...
Acrobat reader 7 saved to *.txt > gibberish Acrobat reader 7 copy text paste to Openoffice > gibberish Open pdf in Kword > gibberish pdftk > useless pdf2html > gibberish
I've just installed acrobat 5 for windows through crossover wine, and export to txt > gibberish
I've then downloaded Acrobar Reader professional tryout version for windows (100mb) and installed it on my son's computer. It opens your pdf fine, but saving as .txt has it choke on page 21.
I have used the recommended conversion methos repeatedly in the past, and they have worked fairly well, but I had never used it with a file as complex as the dreaded Bagheri file. Have you considered getting in touch with the author and requesting another format?
I'm afraid this is the only thing I can recommend, having unsuccessfully tried all the other options :-(
fx
Maura also (at my request) sent the file to me. (It weighs in at
4.9MB as a 70-page PDF [with some graphics] and when exported from
acroread as a PS file it becomes 85MB).
I have made a serious attempt to analyse the PS file. It's a
monstrous nightmare.
At the end I have a few questions for anyone who may have the
expertise to take the matter further, but it seems very likely
that all of the usual resources (such as many have suggested)
will simply fail.
The basic issue, it seems to me, is that (apart from one tiny patch
in the middle of a Figure which may have been imported from some
other application), the entire text is in bit-mapped glyphs set up
as Type 3 fonts. There is a total of 8 "user-defined" Type 3 fonts.
Each page begins with a set of font definitions. For each font, there
is an encoding vector followed by glyph definitions on the lines of
T3Defs
/FontType 3 def
/FontName /N9 def
/FontMatrix [1
...
]def
/Encoding [/a0 /a1 /a2 /a3 /a4 /a5 /a6 /a7 /a8 /a9 /a10 /a11
/a12 /a13 /a14 /a15 /a16 /a17 /a18 /a19 /a20 /a21 /a22 /a23
/a24 /a25 /a26 /a27 /a28 /a29 /a30 /a31 /a32 /a33 /a34 /a35
...
/a228 /a229 /a230 /a231 /a232 /a233 /a234 /a235 /a236 /a237
/a238 /a239 /a240 /a241 /a242 /a243 /a244 /a245 /a246 /a247
/a248 /a249 /a250 /a251 /a252 /a253 /a254 /a255 ] def
/GlyphProcs 257 dict begin
/.notdef {250 0 d0} bind def
/a0 { save
0 0 0 0 164 170 d1
164 0 0 170 0 0 cm
_op? setoverprint
BI
/Width 164 /Height 170 /BitsPerComponent 1 /Decode [0 1]
/ImageMask true
/DataSource
{{<~J,fQLzzz!!!!@n:1K=zzzz+7Od\zzzz!$C]\zzzz!!",1J,fQLzzz!!!!@n:1K=z
[lots of stuff defining a bit-map]
} _i get /_i _i 1 add 2 mod def} /_i 0 ID EI
restore } bind def
(the above for glyph "a0") followed by similar for each glyph "a1",
"a2", ... , "a255" in Font "N9". And so on for other fonts.
Then, when it comes to the text on the page, this is referenced as
octal codes like (excerpt from page 3):
/N9 1 Tf
(|\342;\315\360\323\223\300l\314l\302\214\352\371\277\\\304\371\
\325\326\316\\370\315\233\325\016\277;\314\233\322v\300)Tj
/N272 1 Tf
(=<)Tj
/N9 1 Tf
(\231\300m\300\233\317\036\301\251\317\371\300K\301\330\320D\312\
\313\277\265\\300|\353)Tj
2004 0 Td (\301v\325\326\312a\320)Tj
221 0 Td
(\314\303\325\206\315\242\316\275\317;\314\330\312\313\316\223\
\317\265\340)Tj
/N272 1 Tf
(><)Tj
/N9 1 Tf
(\265\302\230\314l\317;\315)Tj
831 0 Td
(\277\371\300l\325a\316\223\3174\325\313\315\242\316\223\300\233\
\317\343\315\\242\300)Tj
illustrating switching from user-defined fonts
N9->N272->N9->N272->N9
Having had a good look at all this, I'm coming to the conclusion that
Maura's ambition to be able to extract ASCII text (which is what
it looks like when displayed on screen) by "select&paste" is probably
hopeless.
First of all, the encoding vector ("\a0 \a1 ...") makes no reference
to ASCII characters and the bit-map glyphs are internally defined,
so as far as acroread is concerned ASCII has nothing to do with it.
This is confirmed by the fact that when the file is displayed in
acroread, acroread is unable to locate ASCII text using the "Find"
resource. For example, the word "data" occurs many times in the
file. But searching for "data" (case-insensitive) finds only the
single instance in the Figure mentioned above.
Secondly, an attempt to select&paste into a text file and reading
out the bytes as hex, comparing these with the sequence of ASCII
characters displayed on screen, did not seem to establish a definite
correspondence between the bytes and the characters.
Indeed, when the mouse is used to select text on-screen in acroread,
it appears visually that the text is not consecutively selected but
in blocks which jump about on the page, suggesting that the blocks
of code in the PS file may correspond to blocks which are positioned
in the right places in screen but in a sort of "random" order.
Thirdly, in the absence of establishing a correspondence between
the octal codes and ASCII characters, and ditto for the encoding
vector, there is no way of knowing what corresponds to what except
by extracting the glyph definitions (all 255 of them for each font)
and rendering them from an artificial PS file. This would mean
enormous work unless there were some application which is tailor
made for the job (and I never heard of one!).
Finally, the task of re-writing (even automatically using a custom
written program which would have to avoid treading on things it
shouldn't tread on) the whole of an 85-MB PS file is itself enormous!
QUESTIONS:
However, despite all that, I'd like to appeal to any true PS/PDF
gurus out there who can recognise the above and are familiar with
the situation, for any clarification about how the problem can
be approached -- or for confirmation that it really is out of reach.
Another question I'd like to put to anyone who may have encountered
this kind of thing before is:
What software could possibly have created this in the first place???
Acroread's "Document Info" says:
Creator: Not Available
Producer: Aladdin Ghostscript TESTER RELEASE 6.23
but that's only the end of the line. Lurking in the PS version one
can find, as well as the user-defined Type 3 fonts used for the
English text, the following mentions (but no usage):
/HeiseiMin-W3-83pv-RKSJ-H _pdfFontStatus
/HeiseiMin-W3 _pdfCIDFontStatus
/HeiseiKakuGo-W5-83pv-RKSJ-H _pdfFontStatus
/HeiseiKakuGo-W5 _pdfCIDFontStatus
/HeiseiMaruGo-W4-83pv-RKSJ-H _pdfFontStatus
/HeiseiMaruGo-W4 _pdfCIDFontStatus
suggesting Asian capability. Also, Bagheri himself is of Iranian
origin, so may have been created the document using software
with capabilities adapted to that part of the world. So this may
be a clue.
This problem is very tantalising -- theoretically, it could be
solved if a suitable "key" could be spotted, and a suitable
"translation" program composed. In practice, it seems to be
wrapped in obscurity and complexity.
Best wishes,
Ted.
--------------------------------------------------------------------
E-Mail: (Ted Harding)