[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #34740] gnustep has problems with PNGs that have a sRGB colorspace
From: |
julian |
Subject: |
[bug #34740] gnustep has problems with PNGs that have a sRGB colorspace |
Date: |
Sun, 06 Nov 2011 23:59:43 +0000 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.51.22 (KHTML, like Gecko) Version/5.1.1 Safari/534.51.22 |
Follow-up Comment #8, bug #34740 (project gnustep):
>It will now use exactly 72dpi (1 point = 1 pixel) if the pixels-per-meter
value in the file is close to that.
thanks i can confirm that fixes the problem so this bug can be closed.
>not sure.. see if cairo fixes it.
i can't use cairo. i want to deploy a binary-only with included gnustep as a
precompiled package for all linux distributions. in this case the only thing i
really care about is deployability = dependencies. i will therefore try again
to get plain X backend working and file a bug about the font issue if it still
exists.
> the pixel data with -bitmapData is a dangerous idea unless you are prepared
to check the bitmap format carefully
thanks for the warning! actually i don't know a better way except perhaps
using TIFFRepresentationUsingCompression:NSTIFFCompressionNone, and i believe
i tried that and the results were not good...i think there was a issue with
transparency. if you want i can retest this and look if there is bug there
compared to cocoa. i believe in my case bitmapData (with a few sanity checks)
isn't so bad anyway since i have complete control over the embedded gnustep
version and all images that ever will get loaded.
>calculating rowsize yourself is wrong becasue the framework
yes thanks. i actually tried bytesPerRow to see if the problem would go away
when using it but didn't leave it in the production code since i was afraid it
wouldn't work under cocotron/win32 path.
>comes from the resolution independence of NSImage
ok since AFAIK you were working on the resolution independence of NSImage i've
got a question. i added a icon to my app some days ago and couldn't find any
documentation regarding the recommended size or format of the icon (seems only
base is really documented) and therefore added
1.) a tiff file with all sizes from 512x512 down to 1x1 embedded. this fucked
up the icon in the taskbar, in gnusteps dock and in the about panel
2.) next i tried a tiff file with a single size 512x512. this just fucked up
the about panel if i remember correctly
3.) i settled on a 64x64 tiff which finally worked fine ;)
is this known to be broken or not expected to work or should i file a bug
there?
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?34740>
_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.gnu.org/
- [bug #34740] gnustep has problems with PNGs that have a sRGB colorspace, julian, 2011/11/03
- [bug #34740] gnustep has problems with PNGs that have a sRGB colorspace, Fred Kiefer, 2011/11/05
- [bug #34740] gnustep has problems with PNGs that have a sRGB colorspace, julian, 2011/11/05
- [bug #34740] gnustep has problems with PNGs that have a sRGB colorspace, julian, 2011/11/05
- [bug #34740] gnustep has problems with PNGs that have a sRGB colorspace, Fred Kiefer, 2011/11/06
- [bug #34740] gnustep has problems with PNGs that have a sRGB colorspace, julian, 2011/11/06
- [bug #34740] gnustep has problems with PNGs that have a sRGB colorspace, Eric Wasylishen, 2011/11/06
- [bug #34740] gnustep has problems with PNGs that have a sRGB colorspace, Eric Wasylishen, 2011/11/06
- [bug #34740] gnustep has problems with PNGs that have a sRGB colorspace,
julian <=
- [bug #34740] gnustep has problems with PNGs that have a sRGB colorspace, Eric Wasylishen, 2011/11/06
- [bug #34740] gnustep has problems with PNGs that have a sRGB colorspace, julian, 2011/11/07