2002.08.16 14:34 "RE: Orientation field", by Kari Poysa

Good points and great discussion. From my limited experience with scanner development, I want to add a few more comments:

Scanners like any other devices are intended for a target market (read: price) that sets some financial limitations to the amount of memory and CPU that can be offered. Because the slowest component is typically the physical paper movement, it is natural to feed the originals such that the original's longest edge that is shorter than the scanner bar is fed to the scanner. On a typical paper document - a letter or A4 size portrait - this requires a 90 degree rotation to view the scanned image properly. And I agree, this should really be done at the source, and it typically will be done as long as the resources to do it are available.

Now the dilemma: you can offer the user as an added bonus the scanning of originals that are larger in size and/or utilize a higher resolution than the intended everyday use (which set the original design boundaries - the target market). Problem is you cannot rotate them properly. Do you not offer these paper sizes and resolutions or do you hope that the viewer will do the rest of the work?

I agree that an experienced user will figure out how to feed the originals so that the resulting image is properly oriented and needs no rotating. However, the Joe Average user will still have to learn this the hard way when he opens his scan in a viewer.

I don't like the term laziness (I use words like "budget" and "schedule" with my boss ;), but how is it that just about all TIFF viewers offer a rotate option on the user's toolbar, but they do not rotate automatically if the TIFF tag requests it? This does not help spreading TIFF as a raster image interchange format.

So I want to repeat my plea for the viewer developers to rethink implementing the orientation tag. It will set you apart from the rest!

--- Kari ---