[texhax] includegraphics and image scaling

[Peter Davis]

On Fri, Dec 10, 2010 at 5:08 PM, Heiko Oberdiek <
heiko.oberdiek at googlemail.com> wrote:

> On Fri, Dec 10, 2010 at 03:10:05PM -0500, Peter Davis wrote:
>
> > Thank you, Heiko.  I agree that having both JFIF and EXIF data is
> > over-specifying the information, and creates opportunities for such
> > inconsistencies.  In fact, files with such inconsistencies are *very*
> > common.  I've run into this situation, and had to code around it, many
> times
> > over the years.
> >
> > There should be some consensus on which overrides which in cases where
> the
> > image is inconsistent.
>
> I consider it as a bug of the application that creates the image file.
> Why should one case more "bug free" than the other?
>

You are, of course, free to take that position.  However, in a very large
number of cases, with a very large number of files, users will not get what
they want or expect.  The Chrysanthemum.jpg image comes from the Corbis
library, a pretty large stock house, I think.  I think Photoshop and other
widely used apps commonly write files like this.  So you can either "be
right," or "do the right thing."  I think it's like saying "HTML is wrong
because it allows style information  like <b> and <i> to be set explicitly.
 Therefore, my browser will not support HTML."



>
> > It seems that much of the more widely used software
> > (Photoshop, InDesign, Windows, pdfTeX, the IJG JPEG library, etc.) use
> the
> > JFIF data, while ImageMagick and XeTeX use the EXIF data.
>
> JFIF data are very easy to parse, but very few information is provided.
> EXIF data needs more effort for parsing, but can provide a variety
> of information. File formats with redundancy involved have the risks
> of inconsistency. Fix the inconsistencies and the file reading
> applications are happy.
>

In the printing and publishing world, at least in my experience, Photoshop
is *the* de facto standard image manipulation tool.  Any file that comes
from Photoshop is, by definition, "correct."

-pd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/texhax/attachments/20101210/fbc3873f/attachment.html>