gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Image size, DPI (was Re: Gorm is broken)


From: Eric Wasylishen
Subject: Re: Image size, DPI (was Re: Gorm is broken)
Date: Tue, 3 May 2011 19:51:20 -0600

On 2011-05-03, at 2:28 PM, Riccardo Mottola wrote:

> Hi,
>> Yes. However, the value 72 dpi is important in GNUstep/Cocoa because 1 point 
>> in the window's base coordinate system = 1 pixel, and a point is 1/72 inch. 
>> (even though it's an arbitrary number in some sense because no modern 
>> desktop screens are really as low resolution as 72 PDI).
>>   
> yes it is actually just an arbitrary value. It wass actually the DPI of early 
> dot-matrix impact printers... I don't think any NeXT machine had less than 90 
> dpi.
>> So drawing an image with 1 pixel = 1 pixel means treating the image as if it 
>> is 72 DPI, which is what the code did before my patch, i.e. it set the 
>> dimensions in points to the dimensions in pixels.
>> 
>> I just checked on Cocoa and it ignores the dpi of PNG's and assumes them to 
>> be 72dpi, however it reads and uses the dpi of TIFF's exactly as GNUstep 
>> does now. In addition, Cocoa supports multi-image TIFF's, something I would 
>> like to add support for to GNUstep. This means we can provide high-res 
>> versions of the default artwork which are only used when a scale factor>  1 
>> is set.
>> 
>>   
> Cocoa supprts also ICNS with multiple res images which is very good for 
> things like icons in the workspace or the dock. It is also very good when 
> supplying smaller images. For example 16x16 or 32x32 look much better if 
> supplied instead of precomputed.

Agreed. It turns out GNUstep already supported reading multi-image TIFF's. 
NSImage just need _bestRep:withResolutionMatch: implemented, which I just did.

I drew high-res (4x original size) versions of common_3DArrowRight.tiff and 
common_Dimple.tiff, and added these to the original files. These will now be 
used if you use a GSScaleFactor > 1. 

> It makes no sense to ignore it by PNGs and use it by TIFFs. I'd say Cocoa is 
> giving TIFF a preferential route.

I agree.

>>> I think your patch is wrong in concept: no developer would expect their 
>>> button or any other gui element to be resized according to the display 
>>> resolution. A pixel is a pixel in that case.
>>>     
>> By default a pixel is a pixel. But when you set GSScaleFactor to a number 
>> other than 1, everything is scaled.
>> 
>> Using the DPI metadata means a slight inconvenience for people who don't use 
>> the scale factor feature (ensuring all images are set to 72dpi), but it 
>> allows providing high-resolution versions of images for when higher scale 
>> factors are used, so I think it makes sense.
>> 
>>   
> I wonder how OpenStep handled this, I think the 72 dpi thing was inherited by 
> mac classic.
> If you find no resolution information you should then assume 72dpi.
> 
Right, that's how it works currently.

Eric


reply via email to

[Prev in Thread] Current Thread [Next in Thread]