Re: [Gimp-developer] Splash screen

2007-07-22 Thread Martin Nordholts
 I'm not really able to develop (not yet), so I made a little splash-screen
 image, because I saw on the bugzilla that a new splash-screen was needed.

Thank you for taking the time to make one, but it does not look 
professional enough imo to be the official 2.4 splash, mainly because of 
the too colorful plasma.

Also, you might find this interesting to read:
http://wiki.gimp.org/gimp/GimpSplashScreen

- Martin Nordholts

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Print plugin

2007-07-22 Thread Stefan Roellin
Hi,

I have submitted a patch which (slightly) improves the quality of the print
plugin (see Bug #387604). The problem basically was that Postscript can't
cope with transparency. In contrast, PDF is able to do so.

The current implementation/patch now has a disadvantage: if you print to a
postscript target, the image has to be exported TWICE: once for the 'print
preview widget' (with alpha) and once for the postscript target (without
alpha). This is certainly not optimal regarding memory consumption. 

So the question is, whether this is a real problem or not. 

If yes, a solution could be to not distinguish between a Postscript and a
PDF target (i.e. to embed only opaque images into a PDF despite the fact
that PDF can handle images with alpha values). In this case, we only have to
export the image at most once.


Stefan
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [Gegl-developer] PyGEGL instant crash

2007-07-22 Thread Kevin Cozens
David Gowers wrote:
 The what's new document for each release is a good resource for these
 kinds of problems, especially its porting section:
 
 http://docs.python.org/whatsnew/porting.html

The last two items on that page seem to be the more likely candidates that 
could cause problems. I don't see any calls to *_Malloc() or *_Free(). There 
are a number of calls to g_free(). If any of them are being called on items 
that were not allocated by a glib routine that could be the cause of the crash.

That page has also made me aware of at least one change needed for 64-bit 
machines.

-- 
Cheers!

Kevin.

http://www.ve3syb.ca/   |What are we going to do today, Borg?
Owner of Elecraft K2 #2172  |Same thing we always do, Pinkutus:
 |  Try to assimilate the world!
#include disclaimer/favourite |  -Pinkutus  the Borg
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Print plugin

2007-07-22 Thread D. Stimits
Stefan Roellin wrote:

Hi,

I have submitted a patch which (slightly) improves the quality of the print
plugin (see Bug #387604). The problem basically was that Postscript can't
cope with transparency. In contrast, PDF is able to do so.

The current implementation/patch now has a disadvantage: if you print to a
postscript target, the image has to be exported TWICE: once for the 'print
preview widget' (with alpha) and once for the postscript target (without
alpha). This is certainly not optimal regarding memory consumption. 

So the question is, whether this is a real problem or not. 

  

For me, it is a serious problem. I work in the print industry, typically 
creating PostScript drivers. The PS output is quite good quality, and 
every conversion generally suffers serious quality issues. Gimp is one 
of the best tools available for UNIX side PostScript. Photoshop and some 
other tools, despite being Adobe products, tend to break standards 
compliant high end print systems (most of those products work great so 
long as you don't mix them with other people's products, then they 
suck...gimp PS works flawlessly with all of the certified systems). As 
soon as you start making PDF-to-PostScript conversions or 
PostScript-to-PDF-to-PostScript, the output is hopeless. Don't do it.

If yes, a solution could be to not distinguish between a Postscript and a
PDF target (i.e. to embed only opaque images into a PDF despite the fact
that PDF can handle images with alpha values). In this case, we only have to
export the image at most once.
  


PDF is pretty much a subset of PostScript with a hierarchy, at least in 
the basic early versions. When you start getting into more recent 
versions, it diverges, but still contains mainly a subset of PostScript 
operators for the vector and bitmap part of it. If you wanted support 
for PDF, you'd be better off making both PS and PDF output options. It'd 
be nice to have direct PDF output, but this is a document interchange 
format, and NOT a print format. There is no reason to not add dual 
output format, but there is an extrordinary loss of quality by removing 
direct PostScript output (FYI, I must often slice and dice the raw 
PostScript, and gimp has the most sane version among the common tools).

FYI, a proper conversion tool can convert from PS to PDF without loss, 
but virtually all tools have issues, mainly when converting vector to 
bitmap, or using lossy compression without an option to say no to it. If 
anyone really felt the need to improve print options, my own feeling 
from coding for the print industry is that more options on compression 
formats and font embedding (perhaps not relevant for gimp) would be 
appropriate.

D. Stimits, stimits AT comcast DOT net

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer