![](https://secure.gravatar.com/avatar/c4fb1aecd98bbaa9856f8c421db294e0.jpg?s=120&d=mm&r=g)
On Mon, Jul 04, 2005 at 03:48:47PM +0200, Hans Hagen wrote:
Heiko Oberdiek wrote:
\pdffiledump length 20 {abc.bmp}
Reads the first twenty bytes of abc.bmp in binary mode and returns them as hex string.
Uses: a lot, eg. inspecting the file header to get size information of bitmap files (eg. for latex/dvips). Or it could be used to read ucs2/4 files, recode them and reading (\scantokens, \pdfunescapehex) them as utf-8.
often one needs more trickery to get a size due to the fact that many bitmap formats are linked lists of tagged records; i suppose that reading in a 400K file has some mem penalty -)
BMP formats are supported by dvips and you need some header
bytes only.
400K files don't need to be read as a whole. An intelligent
implementation would parse the necessary parts. With the
information of \pdffilesize files can also read from behind
and parse pdf or dvi files, for example. But it is easy to
add another option for the read direction for parameter "whence"
of fseek (SEEK_SET, SEEK_CUR, SEEK_END).
Currently the file is not remembered, thus "current" has no meaning.
Keyword "offset" can be given an option "end":
\pdffiledump [offset [end] <int>] [length <int>] <general text>
"offset 10 length 2" means byte 10 and 11,
"offset end 10 length 2" means byte 10 and 11 before end of file.
Yours sincerely
Heiko