Re: [Gimp-developer] Need quick development workstation
Hi, Winston Chang [EMAIL PROTECTED] writes: I wrote the GIMP unsharp mask plugin a while back and I'm looking to add a preview window to it. I wrote the code just now and I tried to compile the latest CVS tree but the GIMP won't build at all for me. I don't know much about autoconf, but I assume I have to run autogen.sh or autoconf. autogen.sh complains: Testing gettextize... too old! (Need (0.)10.38, have 10.35) and autoconf makes a configure script that complains: ./configure: line 570: syntax error near unexpected token `AM_INIT_AUTOMAKE($PACKAGE,' ./configure: line 570: `AM_INIT_AUTOMAKE($PACKAGE, $VERSION, no-define)' Anyway, I don't feel like going to the trouble of updating my libraries or whatever it is I need for this little modification, so if I could have short-term ssh (with X) access to a machine that can build the latest CVS branch, I'd really appreciate it. I promise not to do anything bad -- besides, you should have the latest patches installed anyway. :-) all I can offer you is to help you with upgrading your libraries. The files HACKING and README should give you a good overview of what you need. If you have problems, ask. So you are working on plug-in preview. Did you consider to resurrect the code or at least the idea of a generic preview suitable to be used by all (or most) plug-ins? I think now is a good time to add such a feature since almost all plug-ins would benefit a lot from having a preview and it does IMO not make sense to duplicate the same code all over the place. The code I'm speaking about can be found at ftp://ftp.gimp.org/pub/users/amundson/gimp_plugin_preview-0.29.tar.gz Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: Gimp-Print 4.1.99-b1
Please visit http://gimp-print.sourceforge.net for more information, or to download the software. This is gimp-print version 4.1.99b1, the first beta release leading up to the 4.2 stable release. This release is not 4.2. This software includes the Print plug-in for the Gimp, and GhostScript and CUPS drivers. The support for printers in GhostScript and CUPS is identical to the support for these printers in the Print plugin -- they use the identical code base. Please read src/ghost/README and src/cups/README for more information on this. These release notes primarily describe changes visible to the end user. Detailed descriptions of changes may be found in the ChangeLog. The Gimp Print plugin requires the Gimp 1.2. Gimp-Print 4.1.99b1 contains the following changes over 4.1.99a3: 1) Fixes for the Lexmark driver. 2) The print plugin now stores the current printer name correctly in all cases (broke in 4.1.99-a3). 3) The PCL driver prints correctly in all resolutions (broke in 4.1.99-a3). 4) The driver supports minimum, as well as maximum, paper sizes for printers. 5) Fix margins for some Epson printers. On many printers, it's possible to print closer to the top and bottom of the page when using softweave than otherwise; the driver now changes the margins dynamically depending upon the settings. See bug 231885. 6) The Foomatic driver now displays human-readable names (broke in 4.1.99-a3). 7) The print plugin has tooltips for most functionality. 8) The printer driver list in the print plugin should be displayed in the correct position (with the currently active printer visible). 9) The default resolution for Epson printers supporting variable drop size printing (essentially the Stylus Color 740 and newer) has been changed from 360 DPI to 360 DPI Softweave. This will produce much better output. 10) The preview in the Gimp plugin is much smoother (does not flash to nearly as great a degree) when moving, resizing, or changing the color settings of the image. 11) Fix a few more corner cases for the Epson Stylus Color 480/580, C20, and C40 series printers. Known limitations of this release: 1) The Epson Stylus C40UX (and very likely other printers in the C20 and C40 lines) do not identify themselves. Therefore, escputil -u -d will not return anything useful. 2) The align color (-o) command to escputil does not currently work on the printers that should support it (Epson Stylus Color 480 and 580, and C20SX, C20UX, C40SX, and C40UX). 3) Changing ink cartridges on the Epson Stylus Color 480/580 is not supported. 4) The drivers for the Epson Stylus Pro printers (5000, 5500, 7000, 7500, 9000, 9500, and 1) are not tested or tuned. They may not work correctly in all cases, and their outputs are not properly tuned. 5) The Canon BJC-8200 and S800 do not produce optimum quality. 6) The Gimp Print plugin tooltips may not work properly on all systems. -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Gimp-Print 4.2 hit list
Here's my hit list for 4.2. Does anyone else have anything they'd like to add to this, or any comments? I'd like to load these into the tracker somehow. If you disagree with the priority, please speak up too! I) Outright problems that we need to either fix or consciously waive for 4.2 (potential stoppers). 1) Clean up the i18n for the print plugin (Roger?). I consider this a stopper because the Gimp is one of our major users, and we need our release to play with that. 2) Fix up/i18n the tooltips (I'm going to do that this week). It's less clear what the impact of this one is. 3) Fix the HP glossy paper problem (Dave?). Is the right fix to alias glossy paper to something else? This has been a thorn in our side for a while. 4) Complete the I18n on the CUPS (Mike, Roger?). 5) Fix the Canon BJC-8200/S800. Andy has told me that he cannot do this without a printer, and he either needs a printer or someone else with a printer who's willing to dig in. Any volunteers out there? This is another long-running thorn. 6) Test and tune some of the large format (Stylus Pro series) Epson printers. This one's a bit borderline, since there probably aren't a whole lot of people out there who really want this right now, but this is potentially flagship functionality. The reason I'm concerned about it prior to release is that there are some untested code paths, and we may potentially have to change the logic around or change some of the resolution options. I'd really, REALLY hate to be talking about doing this after release. In addition, the Stylus Pro 1 is a variable drop size printer; we may have to support two different printer definitions, one for pigment ink and one for dye ink. 7) Determine that the Stylus Color, Stylus Color 1520, and other very old printers do the right thing with the default resolution in both color and black white. Mike, can you test this? This would represent a regression if it's broken. II) Things that may well be stoppers, but I don't have as much justification. 1) Figuring out how the color head alignment works, and on what Epson Stylus printers it applies. Should this one be a stopper? This will certainly affect more people than the Stylus Pro printers, but it's not likely to be absolutely mandatory functionality. Then again, for really critical, high quality stuff, maybe it is. I'm talking with the Epson folks about it, but a lot of people have been on vacation lately, and I'm not sure where this is. Perhaps someone running Windows could reverse engineer the remote mode command that prints the color head alignment page. 2) Documentation. Consensus seems to be that we're doing much better than we were last time, but it's still not great. Potential stopper? What are we missing? 3) Human factor analysis (and cleanup, and???) on the Gimp plugin. This is completely beyond my abilities. Mitch, Sven, can you help us out here? III) Things that we really should fix if we can, but that won't stop the release. 1) Tune the Stylus Photo 2000P. Nothing at all has happened here since 4.0. We haven't received any complaints about it, and I don't think that this printer sells all that well. This one's not a stopper by any stretch of the imagination since it's simply a matter of tuning the inkset. If it turns out to be more involved (which I think is unlikely) we can decide what to do then. 2) Tune the 2880x720 Epson printers. It may be possible to get slightly better print quality on those machines; if we can, that would be mildly useful to a lot of people. If we can get an improvement, it's going to be in the dark midtones, by using smaller dots. The quality may be high enough already that we don't need to worry. 3) Determine if there's some hidden way of using all the nozzles to print in black and white at 720 and 1440x720 DPI on the Stylus Color 480 and 580. This affects a lot of people; the workaround is to print at a lower resolution (720x360), or to accept that printing at 720 DPI, even in black and white, will be very slow (as slow as printing in color on those already slow machines). I'm working this with Epson. IV) Things that would be really nice to have, but aren't essential. 1) Determine how to make the printer ID command work on the C20/C40 printers. I'm working this one with Epson also; there may simply be no workaround. 2) Figure out how to embed non-printing information in the header of a print job. I'm working this one with Epson. The idea is that we can put the driver version, printer model, and such in the file header, and then tell people to run parse-escp2 as
Re: [Gimp-developer] Solaris 64bit compile
So if I understand you correctly, since the gimps main purpose is to perform bitwise manipulation that 64 bit won't give much of a benefit. If someone were to go in and change the memory management scheme of the gimp to make use of the OS instead of gimps tiles than we would probably see a benefit in the load time and save time. I could also see that breaking other OS's unless it was done to work across platforms. I don't know why but for some reason I got it in my head that 64 bit would be twice as fast for any application that was processor intensive. Thinking that you can have, I don't know how many more, many more instructions and the system buss would be twice the width allowing twice the amount of data to go between ram and the CPUs. Maybe when I design my new processor I will include that in :) - Original Message - From: Daniel Egger [EMAIL PROTECTED] To: Brian Weber [EMAIL PROTECTED] Cc: GIMP developer [EMAIL PROTECTED] Sent: Monday, September 03, 2001 8:21 AM Subject: Re: [Gimp-developer] Solaris 64bit compile Am 25 Aug 2001 22:21:58 -0700 schrieb Brian Weber: I did get a successful compile of 64 bit gimp. I ran it and used so of the limited functionality that I usually use with no problems at all. I wouldn't expect them either. I ran GIMP before on 64bit USparc, PPC and Itanium without any quirks. The other thing I didn't see is any performance increase. Bad luck. :) My machine is an Ultra 2 with dual 168 mhz and 192 Meg of ram. I grabbed a relatively small bitmap and used the globe plugin for 10 iterations to make sure that I had enough time to get some statistics. I wasn't using any swap space and one of the processors was pegged about 3/4s of the time. The other process got pinged a couple times but that was probably more os and vmstat. Ok, two reasons for that: GIMP is not requesting a single big chunk of memory from the system but rather does it's own memory management using a tile based system. So if you do not excessivly utilize your system or lie about your memory size then GIMP will probably never hit SWAP at all. The second CPU will be only used for tile rendering if GIMP is compiled with the MP option, however it doesn't give much of a benefit, is rather untested and will definitely result in a deterioriation on a single CPU system because of the additional checks (which is also why it is not activated by default). My question is, am I expecting too much from 64 bit? Yes you are. Does the C code actually have to change to get the benefit from 64 bit? Yes. I don't exactly know how your machine is organized and how USPARC addresses memory but it maybe that differently aligned memory might show benefits here. Also I have some ideas how to optimize the GIMP to give bigger benefits on 64bit architectures but cannot benchmark it due to unavailability of those systems; the trick here would be to reorganize memory utilisation to use the full 64bit capabilites of your machine. Those architectures normally shine while handling big chunks of data and suffer when addressing small amounts of data (say bytewise) with a lot of instructions because they are clocked so slowly. Is this the right list to be asking this question? Sure it is. Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Patch to fix the jpeg plugin compilation
Hi, I've attached a patch that allow the compilation (and installation) of the jpeg plugin. It uses a GtkTextView/GtkTextBuffer couple instead of the deprecated GtkText for the image comment. Well, to use this patch, you'll also have to remove the '#' in front of the jpeg plugin definition in plugin-defs.pl, and re-run mkgen.pl. The patch works OK. I've tested it, and I'm happy to see this plugin back :-). Please apply. Now that I know how to do this, and if my patch is good enough, I could fix the other plugins if you want to. Just tell me. Regards, DindinX -- [EMAIL PROTECTED] patch-jpeg-plugin.bz2
