Images containing text - suggestions?

[Chris Beall]

I'm struggling with how to handle, on a web page, images that contain
text that the user must be able to read. Examples: tombstone photos,
photos or scans of historic documents (handwritten or typed), a map with
place names, route numbers, etc.

(An appropriate alternative for audio UAs would be provided and is not a
part of my concern).

I see two ways to handle these images:
1. Dynamic scaling, with the source image containing enough detail
for readable display in a large window, and a width specified in % so
that it always nearly fills whatever window the user has provided.
CONCERN: For small window sizes (ex: full-screen on a 640 X 480 display)
the browser shrinking of the image may make it illegible, especially the
fine lines in handwritten documents. CONCERN: In the case of a map, I
want to put an image map behind it for navigation. Popular browsers
don't seem to scale image maps when the associated image is scaled,
making this unworkable.
2. Multiple images: Let's say three images, each at a different
resolution, with the middle-sized one presented by default. On the same
page would be links for 'smaller image' and 'larger image' that would
take you to the other versions. CONCERN: Storage space required for 3
copies of every image (and image map, where used). CONCERN: 2/3 of the
users will not want the default and will have to click to the version
they want each time they reference any such image. CONCERN: How best to
create the images:
2a. Scan the original document/photo three times, setting the
scanner for different DPI values each time.
2b. Scan the original once, at a high DPI value, and use PhotoShop
or equivalent to produce the smaller versions.

Comments and suggestions?

Thanks,
Chris Beall

[Malcolm Dew-Jones]

Chris Beall (Ch*********@prodigy.net) wrote:
: I'm struggling with how to handle, on a web page, images that contain
: text that the user must be able to read. Examples: tombstone photos,
: photos or scans of historic documents (handwritten or typed), a map with
: place names, route numbers, etc.

: (An appropriate alternative for audio UAs would be provided and is not a
: part of my concern).

: I see two ways to handle these images:
: 1. Dynamic scaling, with the source image containing enough detail
: for readable display in a large window, and a width specified in % so
: that it always nearly fills whatever window the user has provided.
: CONCERN: For small window sizes (ex: full-screen on a 640 X 480 display)
: the browser shrinking of the image may make it illegible, especially the
: fine lines in handwritten documents. CONCERN: In the case of a map, I
: want to put an image map behind it for navigation. Popular browsers
: don't seem to scale image maps when the associated image is scaled,
: making this unworkable.
: 2. Multiple images: Let's say three images, each at a different
: resolution, with the middle-sized one presented by default. On the same
: page would be links for 'smaller image' and 'larger image' that would
: take you to the other versions. CONCERN: Storage space required for 3
: copies of every image (and image map, where used). CONCERN: 2/3 of the
: users will not want the default and will have to click to the version
: they want each time they reference any such image. CONCERN: How best to
: create the images:
: 2a. Scan the original document/photo three times, setting the
: scanner for different DPI values each time.
: 2b. Scan the original once, at a high DPI value, and use PhotoShop
: or equivalent to produce the smaller versions.

: Comments and suggestions?
Perhaps publish it as a pdf document and let the reader take care of all
those details.

[erikd]

On Sat, 27 Nov 2004 22:57:16 GMT, Chris Beall
<Ch*********@prodigy.net> wrote:

I'm struggling with how to handle, on a web page, images that contain
text that the user must be able to read. Examples: tombstone photos,
photos or scans of historic documents (handwritten or typed), a map with
place names, route numbers, etc.

I don't know if it will work for your particular application, but
someone in the office is investigating using SVG for displaying
schematics. I tried out a sample and it's pretty impressive the way
that you can zoom in to see the drawing details. I don't know if it
will work for your items of interest. SVG = Scalable Vector Graphics.

--
Erik

[Darin McGrew]

Chris Beall <Ch*********@prodigy.net> wrote:

I'm struggling with how to handle, on a web page, images that contain
text that the user must be able to read. Examples: tombstone photos,
photos or scans of historic documents (handwritten or typed), a map with
place names, route numbers, etc.

(An appropriate alternative for audio UAs would be provided and is not a
part of my concern).
Presumably, this appropriate alternative will also work for non-audio UAs
that can't (or that are configured not to) use your images.
I see two ways to handle these images:
1. Dynamic scaling, with the source image containing enough detail
for readable display in a large window, and a width specified in % so
that it always nearly fills whatever window the user has provided.
CONCERN: For small window sizes (ex: full-screen on a 640 X 480 display)
the browser shrinking of the image may make it illegible, especially the
fine lines in handwritten documents. CONCERN: In the case of a map, I
want to put an image map behind it for navigation. Popular browsers
don't seem to scale image maps when the associated image is scaled,
making this unworkable.
And browsers do a poor job resizing images, so you waste bandwidth and
deliver a lower-quality image than you might have if you had resized the
image properly yourself.

IMHO, this isn't even an option.
2. Multiple images: Let's say three images, each at a different
resolution, with the middle-sized one presented by default. On the same
page would be links for 'smaller image' and 'larger image' that would
take you to the other versions. CONCERN: Storage space required for 3
copies of every image (and image map, where used). CONCERN: 2/3 of the
users will not want the default and will have to click to the version
they want each time they reference any such image. CONCERN: How best to
create the images:
2a. Scan the original document/photo three times, setting the
scanner for different DPI values each time.
2b. Scan the original once, at a high DPI value, and use PhotoShop
or equivalent to produce the smaller versions.

Start with the smallest image. Have this thumbnail image link to an image
that is as large as necessary. Don't bother with any sizes between the
thumbnail image and the "as large as necessary" image. As an option,
provide links to even larger images for those with interest and bandwidth.

Scan at the highest resolution possible, and resize the images as
necessary.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"You learn nothing new the third time a mule kicks you in the head."

[Chris Beall]

Malcolm Dew-Jones wrote:

Chris Beall (Ch*********@prodigy.net) wrote:
: I'm struggling with how to handle, on a web page, images that contain
: text that the user must be able to read.

: Comments and suggestions?
Perhaps publish it as a pdf document and let the reader take care of all
those details.

Thanks Malcolm.

My main concern with using pdf is that I expect many visitors to be
unfamiliar with it (and may not have the reader). The Adobe Reader
interface uses icons for things like magnification, which could confuse
some visitors.

Also, for the map case, I'm not aware of any way to make a pdf
navigable, i.e.. to put an image map or equivalent behind it.

Chris Beall

[Chris Beall]

er***@nospam.wanted.here wrote:

On Sat, 27 Nov 2004 22:57:16 GMT, Chris Beall
<Ch*********@prodigy.net> wrote:

I'm struggling with how to handle, on a web page, images that contain
text that the user must be able to read. Examples: tombstone photos,
photos or scans of historic documents (handwritten or typed), a map with
place names, route numbers, etc.

I don't know if it will work for your particular application, but
someone in the office is investigating using SVG for displaying
schematics. I tried out a sample and it's pretty impressive the way
that you can zoom in to see the drawing details. I don't know if it
will work for your items of interest. SVG = Scalable Vector Graphics.

Thanks Erik,

I'll look into this, which may be a good choice for the maps, although I
suspect I'll still have the problem that, even though the image itself
should scale nicely, the underlying image map will NOT be scaled (a
browser implementation error, IMO.)

Chris Beall

[Chris Beall]

Darin McGrew wrote:

Chris Beall <Ch*********@prodigy.net> wrote:

I'm struggling with how to handle, on a web page, images that contain
text that the user must be able to read. Examples: tombstone photos,
photos or scans of historic documents (handwritten or typed), a map with
place names, route numbers, etc.

(An appropriate alternative for audio UAs would be provided and is not a
part of my concern).

Presumably, this appropriate alternative will also work for non-audio UAs
that can't (or that are configured not to) use your images.

True. No magic here. For tombstones and documents, the alternative will
just be a text transcription page. The whole idea of images is to allow
those who are dubious of the transcription to see the original source.
I don't think there's anything I can do about that for the visually
impaired. The other thing is that images are a bit richer in terms of
typography and handwriting, giving the user a better 'feel' for the
material.

Maps are a bit harder. The audio-only user would hear the navigational
choices provided by the image map, but would not be able to 'see' the
physical relationships between the various places named, nor get driving
directions, but the latter is probably superfluous anyway.

I see two ways to handle these images:
1. Dynamic scaling, with the source image containing enough detail
for readable display in a large window, and a width specified in % so
that it always nearly fills whatever window the user has provided.
CONCERN: For small window sizes (ex: full-screen on a 640 X 480 display)
the browser shrinking of the image may make it illegible, especially the
fine lines in handwritten documents. CONCERN: In the case of a map, I
want to put an image map behind it for navigation. Popular browsers
don't seem to scale image maps when the associated image is scaled,
making this unworkable.

And browsers do a poor job resizing images, so you waste bandwidth and
deliver a lower-quality image than you might have if you had resized the
image properly yourself.

IMHO, this isn't even an option.

Agreed. I listed it mainly to show WHY it probably isn't.

2. Multiple images: Let's say three images, each at a different
resolution, with the middle-sized one presented by default. On the same
page would be links for 'smaller image' and 'larger image' that would
take you to the other versions. CONCERN: Storage space required for 3
copies of every image (and image map, where used). CONCERN: 2/3 of the
users will not want the default and will have to click to the version
they want each time they reference any such image. CONCERN: How best to
create the images:
2a. Scan the original document/photo three times, setting the
scanner for different DPI values each time.
2b. Scan the original once, at a high DPI value, and use PhotoShop
or equivalent to produce the smaller versions.

Start with the smallest image. Have this thumbnail image link to an image
that is as large as necessary. Don't bother with any sizes between the
thumbnail image and the "as large as necessary" image. As an option,
provide links to even larger images for those with interest and bandwidth.

There will not be multiple images on a page. Instead, text indices will
list the various documents (or tombstones). Each list entry will link
to the appropriate image, so thumbnails are not needed or useful in this
case.

"as large as necessary" is the problem. If I size the image to fit on a
full-screen 600 X 800 space, it may be too small to read at 1024 X 768
and huge (requiring horizontal scrolling, which I view as a Bad Thing)
at 640 X 480. Not to mention several other window sizes. [I am NOT
targeting this for PDA or cell-phone viewing, though. ...And it's not a
commercial site, so I feel comfortable with that restriction.]

On rereading, I see that I may have misinterpreted your response. Would
you suggest one (default) image at about 640 X 480, with the larger one
big enough to be readable at the highest expected window size, say 1280
X 1024, with no others in between?

Scan at the highest resolution possible, and resize the images as
necessary.

OK. I suspected that would make for better quality, and it's easier
(for me) to do.

Thanks Darin,
Chris Beall

[Lauri Raittila]

in comp.infosystems.www.authoring.html, Chris Beall wrote:

Malcolm Dew-Jones wrote:

Chris Beall (Ch*********@prodigy.net) wrote:
: I'm struggling with how to handle, on a web page, images that contain
: text that the user must be able to read.
Solution depends greatly on images. Usually, best aproach is to just
replicate text below/aside image.
Perhaps publish it as a pdf document and let the reader take care of all
those details.

My main concern with using pdf is that I expect many visitors to be
unfamiliar with it (and may not have the reader). The Adobe Reader
interface uses icons for things like magnification, which could confuse
some visitors.
Very likely. It is also great annoyance to wait Acrobat reader to start.
That takes half minute in high end machines, and more on low end. So one
thinks twice before looking at those.
Also, for the map case, I'm not aware of any way to make a pdf
navigable, i.e.. to put an image map or equivalent behind it.

PDF will be better that image in html, if your map is vector. If your map
image is bitmap, PDF won't help. And then also, it is useful to have
bitmap for web and provide PDF as alternative.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>

[Darin McGrew]

I wrote:

Start with the smallest image. Have this thumbnail image link to an image
that is as large as necessary. Don't bother with any sizes between the
thumbnail image and the "as large as necessary" image. As an option,
provide links to even larger images for those with interest and bandwidth.

Chris Beall <Ch*********@prodigy.net> wrote: "as large as necessary" is the problem. If I size the image to fit on a
full-screen 600 X 800 space, it may be too small to read at 1024 X 768
and huge (requiring horizontal scrolling, which I view as a Bad Thing)
at 640 X 480. Not to mention several other window sizes. [I am NOT
targeting this for PDA or cell-phone viewing, though. ...And it's not a
commercial site, so I feel comfortable with that restriction.]

On rereading, I see that I may have misinterpreted your response. Would
you suggest one (default) image at about 640 X 480, with the larger one
big enough to be readable at the highest expected window size, say 1280
X 1024, with no others in between?

By "as large as necessary", I meant that the next size up from a thumbnail
should be large enough to show whatever detail is essential. If the goal is
to make the smallest text legible, then the next size up from a thumbnail
should be large enough that the smallest text has enough detail to be
legible when displayed at an appropriate size.

If you also provide larger versions, then you will help those who want to
see more detail, and those with high-res displays who can't read the text
in the images when one image pixel equals one screen pixel.

If the goal is something else, then the next size up from a thumbnail
should be large enough to meet that goal.

If the smallest image that is "as large as necessary" is bigger than my
browser window, then I need to enlarge my browser window (if possible) or
scroll. There is nothing you can do to change this. It is a property of the
medium.

So make the images no larger than necessary, and don't worry if some users
still need to scroll.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"Warning: Dates in the calendar are closer than they appear."