From: nospam <nospam@nospam.invalid>
Subject: Re: Weird Picasa bug (only affects Lexmark printers?)
Full headers:
From: nospam <nospam@nospam.invalid>
Subject: Re: Weird Picasa bug (only affects Lexmark printers?)
Date: Sun, 29 Oct 2017 16:37:10 -0400
Organization: A noiseless patient Spider
Lines: 84
Message-ID: <291020171637100327%nospam@nospam.invalid>
References: <> <271020171123595218%nospam@nospam.invalid> <> <271020171648544999%nospam@nospam.invalid> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Injection-Info:; posting-host="165483f2a3a2da85db80fc3ac9d07d60";
logging-data="18712"; mail-complaints-to="";posting-account="U2FsdGVkX18yeHTW67zn+Zq2Ebuq8gpf"
User-Agent: Thoth/1.9.0 (Mac OS X)
Cancel-Lock: sha1:Ev6TbQGjW6lmc4IDfBBk+ETGkFI=
Print Article
Forward Article
In article<>,
newshound<> wrote:

> >>>> After much trial and error, I've found it is the Picasa Export which
> >>>> causes the problem. If you open and then save the JPEG in Paint
> >>>> (overwriting the original file) the problem goes away.
> >>>
> >>> that doesn't mean it's a bug in picasa.
> >>>
> >>> if the jpeg from picasa is valid, then it's word and/or lexmark.
> >>
> >> But they behave fine with picasa files that havn't been compressed by
> >> Picasa export. So I think there is something wrong in the file header
> >> which either the Word print engine or the Lexmark is getting confused
> >> about.
> >>
> >> And the fact that just importing the file into Paint and saving it again
> >> clears the fault points to something in the JPEG.
> > 
> > different doesn't mean one is wrong.
> > 
> > can you post a sample jpeg exported from each app?
> Well I could, but as far as I am concerned I have a fix. I can certainly 
> do that if anyone confirms they would like to do some investigation. I 
> was partly posting this in case anyone already knew about it, or so that 
> someone Googling the same problem in the future would find it.

you don't have a fix. you have a workaround that avoids the issue.

> > the content of the photos is completely irrelevant, as long as the
> > sizing issue can be duplicated.
> > 
> > take a photo of something random, or even fill it with black. no need
> > to share internal photos if you don't want to.
> Happy to share something. With a solid black image I wouldn't be able to 
> see that the process had failed.

then post real images. the point is they the images do not need to be
anything internal to your company or you personally. 

all that matters is that the issue you describe can be duplicated.

two solid black images would still be sized differently.

> > without examining the files, it sounds like the resolution tag, which
> > is sometimes used for initial image sizing/placement in some apps, is
> > set differently.
> Yes, that was one of my guesses but I am not all that familiar with this 
> stuff.

then post samples so that those who are can investigate. 

> > if that's the case, there is probably a default setting which can be
> > changed.
> Yes but what setting?

default resolution, which is usually ignored, except by some apps.

> In Word, you check page layout via print preview. 

word is probably working as designed. however, that you get different
results with lexmark suggests an issue with lexmark.

> And you expect the printer to give you the same thing (although 
> occasionally a line of text spills on to the next page).

that's not good either.

> >>> how did you validate the jpeg? or did you?
> >>
> >> I don't know how to.
> > 
> > that would be a no. :)
> > 
> Indeed. Suggestions would be useful. The export files look fine in 
> several different viewers.

that means nothing.

what does exiftool show for tags, notably resolution?