tei2html
tei2html copied to clipboard
jhellingman
Including high-resolution images for high-resolution output devices
The current code is developed for producing web-based editions with
low-resolution images. When we also want to produce version suitable for
printing, we need ways to also specify alternative, high resolution images that
can be printed, preferably without changes to the master files themselves.
The idea is to pull the images from an alternative path containing the high
resolution versions.
The idea is to have a hires/ folder next to images/, which should contain the
high resolution versions of the low resolution images. In images.xml, we
collect all information about both, and verify this is the case.
Now, when generating a PDF for print, we use the hires instead of images folder
as source.
Original issue reported on code.google.com by jhellingman on 27 Aug 2010 at 9:38
One way to handle this is outside the tei2html scripts, by simply creating an
extra CSS file that replaces the images for use with Prince XML.
Original comment by jhellingman on 1 Feb 2011 at 1:40
Note that for P5, we will also need to support the <graphic> element. A
sensible way to do this is to check for its presence inside a figure, and use
those in that case, while using the legacy ways of defining graphics when it is
not present.
Original comment by jhellingman on 22 Apr 2011 at 1:21
Original comment by jhellingman on 16 Apr 2014 at 9:21
- Added labels: Type-Enhancement
- Removed labels: Type-Defect
Adjusting the title now that high-resolution screens become commonplace. My current practice for Project Gutenberg is to scale images to 144 dpi, and to keep the longest edge below or at 720 px. This 144 dpi resolution is pretty non-standard. Recently PG adjusted their guidelines to allow for significantly higher resolution illustrations.
Since the current practice in high resolution devices is to distinguish between hardware and software pixels, such that a CSS px is roughly equivalent across devices.
Android defines steps of 120, 160, 240, 320, 480, 640 dpi. Apple iPhone uses 163, 326, and 458 dpi (calling it @1x, @2x, @3x) Printers use 300 to 600 dpi
Original scans are often made at 300 to 600 dpi; photographed sources can be anywhere in that range, or even outside it, however, the actual resolution (in dpi) is often not recorded.
Dynamic scaling on the client is not really a big issue anymore, however still incurs some loss in image quality.
Another consideration is that scanned photographs from books are often rasterized, and at higher resolutions, moire patterns can be a serious problem. It basically makes little sense to retain an image at a resolution that the original doesn't have. (see http://www.robotplanet.dk/graphics/raster_removal/)
Solution
Allow multiple directories with images, at various resolutions. Allow configuration to specify which directory to use (default: 'images'). Specify image sizes in CSS (software) pixels in generated HTML/ePub output, using a configurable scaling factor (default: 1.0). Adjust imageinfo tool to collect image information from all directories, and obtain resolution information. Warn on images that are scaled to half-pixels, etc. Define convention to use even or modulo 3 or 4 pixel sizes at higher resolutions.
Also consider technique used here https://juiceboxinteractive.com/blog/a-pixel-is-not-a-pixel-designing-for-a-new-generation-of-mobile-devices/
