ttl@sti.fi (Timo Lehtinen) (11/21/90)
On page 126, the green books states:
"The data acquisition procedure used in a particular instance depends
upon the amount and nature of the data making up the image."
I understand this is also true for the length of the DataString used
i.e. it has to match the length of the image in question.
Now, lets say my file has tens or hundreds of bitmaps/images. Is there
really no way to write a general purpose proc for data acquisition so
that I merely would need to specify the width, length, depth and matrix
for the image and then execute this generic image-display proc which
would read the data as printable hex from currentfile ? Seems like
a really stupid limitation so I believe there must be a way...
If anyone has a solution I'd very much appreciate hearing about it.
I have a feeling this must be extra trivial but I'll summarize if
appropriate...
Timo Lehtinen
--
____/ ___ ___/ / Kivihaantie 8 C 25
/ / / SF-00310 HELSINKI, Finland
____ / / / Phone: +358 0 573 161, +358 49 424 012
Stream Technologies Inc. Fax: +358 0 571 384glenn@heaven.woodside.ca.us (Glenn Reid) (12/02/90)
In article <1990Nov20.215152.1365@sti.fi> ttl@sti.fi (Timo Lehtinen) writes: > >On page 126, the green books states: > >"The data acquisition procedure used in a particular instance depends >upon the amount and nature of the data making up the image." > >I understand this is also true for the length of the DataString used >i.e. it has to match the length of the image in question. > >Now, lets say my file has tens or hundreds of bitmaps/images. Is there >really no way to write a general purpose proc for data acquisition so >that I merely would need to specify the width, length, depth and matrix >for the image and then execute this generic image-display proc which >would read the data as printable hex from currentfile ? Seems like >a really stupid limitation so I believe there must be a way... The basic example for "image" in the red book is appropriately generic. It looks like this: { currentfile picstr readhexstring pop } You can't get much more generic than that. The "picstr" needs to be defined slightly differently each time, but you already have to specify the width, length, depth, and matrix anyway, so this is lost in the noise. You might try something like this: /im % width height bits matrix buffsize im { %def save /picstr exch string def { currentfile picstr readhexstring pop } bind image restore } bind def 80 200 8 [100 0 0 -200 0 200] 10 im Then all your invocations will be exactly as you require; you only need to pass one more argument, "buffsize", which will basically be the width of the image divided by the bits/sample value. Yes, you could do this in the PostScript code, but it's easier and faster to generate it from the App. Anyway, the point is that even though in the green book it is suggested that you can improve the efficiency of an image proc by adjusting it to the data in some useful way, the standard proc mentioned above already is perfectly generic and perfectly suitable for any size image. Glenn Reid