Images and printing....

[david]

> On Sat, 10 May 2003 "David Bovill" <david at anon.nu> wrote:
> 
> What's with the "anon.nu" address?
> 

It's what we use for art based projects / installations. Last years project
didn't have much to do with technology... www.multiculturalyoghurtparty.com
This year's project is an emotional dictionary, for which we plan to use MC
and Valentina's new unicode support.

> 
> After you paint on it.  Or maybe set the imageData.
> 

Painting the jpeg's produced by PictureGear results in being able to print
it - getting, deleting and then setting the imagedata has no effect
strangley... maybe I'll try changing one of the pixels?

> 
> Unless you paint on the image, it's the exact same data you imported.
> 

Except that exporting the image after you resize it effectively exports the
screen resolution (size) of the image not the original data (even if you did
not paint the image).

> 
> IMHO it's a bad idea to think in terms of "X dpi" when working with
> images because there is no inherent size to them.  The effective DPI
> is a function of the resolution of the output device and the ratio of
> the images "rect" property and the width/height of the image data.
> 

Yes it is confusing in terms of programming. But the "tags" that Theresa
pointed out (thanks Theresa) do have some uses. First if you want to produce
images that print and display right across packages.

In my case I want the application to take in jpegs or other images that
users may choose to resize with other applications to get the best possible
print quality. If they have indicated that the image should print 4cm by 3cm
then on import I want to use this info and not have them specify it again -
similar things apply to export for print by other applications I would
think?

> 
> No explanation for this, though we do know of problems displaying and
> printing very large images (larger than 4096 pixels in width) on MacOS
> systems.  This is due to a fundamental limitation in the QuickDraw API
> and not anything we can easily work around.
> 

They are not quite that big - 1575 x 1181... I'll send you an example.


> 
> You can certainly do this by setting the paintCompression property to
> "jpeg" and then painting on the image.  Note that this will force the
> image to be whatever size you've got it displayed on the screen.

Yes this works... would be neater to set the imageData, which I guess has to
work due to the same reasons?