[Gimp-developer] Mac native version of GIMP
Hi all, Are there plans for porting GIMP to Mac OS X using Aqua and not X11? I'm interested in learning how to code user interfaces and in helping the free software community (since it has developed so many useful software that I use daily). I've used GIMP for Linux and Windows but not for Mac. I'm switching to Mac when Leopard ships. If there's a porting project I will help coding the interface of GIMP for Aqua (or start a new project if there's none). no one helps for mac? -- Gerhard (via www.gimpusers.com) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] optional scaling in the save dialog?
Am Freitag 18 Februar 2005 22:31 schrieb Sven Neumann: No, this would only clutter the save dialog. It is already crowded enough. If we'd do that, next week someone will call for auto-whitebalance on save, adding a border and sending mail to grandma. No way. Hello Sven, I agree with you, but wouldn't it be nice to have once on a day something similar to the file automation dialog in Photoshop? There one can choose for example contact sheet or batch processing. In batch processing one can select an action (i.e. gimp-script), a folder for loading the files for processing and one for saving them, and in which kind the naming is to be managed, and so on. I think, this could be something for later plans in the far future. Kind regards Gerhard ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some questions
Am Samstag 12 Februar 2005 13:54 schrieb Sven Neumann: Hello Sven, it's fine to getting aware of the beginning of the cms development in the Gimp! We'll need this stuff :-) Color management on Windows would ideally be implemented using the color management capabilities of the operating system. Same on Mac OS X where ColorSync should be used. For now we will however concentrate on the LCMS based implementation and of course we will make sure that it works on all supported platforms. Hello Sven, like you mentioned before in other cms related threads, it is an good idea to make it possible to choose the CMM the user prefer. And also I thing it would be the best choice to use for default the OS specific build-in CMM, as you said above. Users will be able to load color profiles from whatever location they wish. I don't think we need to provide a way to specify profile directories. GIMP will remember the last location you loaded profiles from and if you need to use multiple profile directories, it's easy to add bookmarks for them. That's a very good point, and it comes with the behavior we should keep in touch with: A very flexible implementation of cms into the gimp. I like this idea. This goes however way too much into details yet. We can figure out such usability concerns as soon as the basic framework has been put in place. When do you expect the basic framework will be up for discussions regarding the usability? ICC profiles can be stored in TIFF files. The parasite is just the way that GIMP deals with this information. I don't know off the top of my head if JPEG allows to embed ICC profiles. Since I would rather get back to work on the color management implementation, I kindly ask you to look that up in the JPEG spec yourself. Yes, JPEG (JFIF) allows to embed ICC profiles. Also it's possible to choose CMYK as colormodel. At least JPEG2000 support this, and Photoshop is able to save normal jpeg files with an icc profile and in CMYK. It support's also clipping paths.[1] http://developer.gimp.org/standards.html has some links that you might find useful. If you know of any URLs that should be added there, let me know. It may would be useful to make a special section colormanagement, and point for example to color.org fogra.org eci.org http://www.swop.org/specifications.html etc. Kind regards Gerhard [1] http://www.jpeg.org/apps/prepress.html?langsel=en http://www.wotsit.org/search.asp?page=5s=graphics http://www.boscarol.com/pages/cms_eng/065-icc.html http://www.google.de/search?hl=deie=ISO-8859-1q=jfif+cmyk+icc+site%3Acolor.orgbtnG=Suchemeta= ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Some questions
Am Sonntag 13 Februar 2005 21:27 schrieb Bob Friesenhahn: None of these metadata types has anything to do with embedding ICC profiles in JFIF JPEG files. Hello Bob, that's true, but the icc profiles are may be stored in a similar way, at least icc is listed here: http://www.ozhiker.com/electronics/pjmt/jpeg_info/acronyms.html It's also a good recource of image file specs (jpeg tiff metadata and Adobe PS related stuff): http://www.ozhiker.com/electronics/pjmt/jpeg_info/index.html Kind regards Gerhard ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Color Management was GEGL development/gimp integration
Sven Neumann wrote: - display profile should be adjusted _once_ systemwide (every time changeble by systemwide color preferences indepenant from the GIMP, as used by (e.g.)scribus [1], inkscape [2], sodipodi[3] wine e.g. for Photoshop and maaybeee by commercial apps available for *nix like Page Stream [4], Cenon [5], Viva Designer [6]) with an monitor profile (like the one of l-prof or adobe-gamma etc.), there for it would be overwhelming to have this choice again in the opening file dialog, if the profile doesn't fits the working color space. regards Gerhard [1] http://www.scribus.org.uk/ [2] http://www.inkscape.org [3] http://www.sodipodi.com/ [4] http://www.grasshopperllc.com/ [5] [6] http://www.vivaip.de/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] mbox archive of [gimp-devel] 2004 and 2005
Hello, I subscribed today to gimp-developers, and I need at least the archives for January 2005 in mbox format (b- or gziped). http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer has got only the archives until 2003. Thank you Kind regards Gerhard Gaußling ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] mbox archive of [gimp-devel] 2004 and 2005
Am Samstag 15 Januar 2005 18:07 schrieb William Skaggs: It's broken. See http://www.gimp.org/mail_lists.html for other archives. Hello Bill, Thank you for the hint, but unfortunately there is nothing to find for downloading in mbox format :-( regards Gerhard ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Color Management was GEGL development/gimp integration
Sven Neumann wrote: If we don't convert the image at load time, all plug-ins that change colors would have to be aware of the color-space the image is in. Since this is not the case for the time being, it would probably be a bad idea to not convert the image. As soon as we go further down the road and have all plug-ins as GEGL ops, this will change. But for the time being, I don't see much choice but to convert everything to sRGB. Note that we are just talking about the first step here. Something that we can achieve in the next few months, without changing each and every piece of code in GIMP and it's plug-ins. Hello Sven, Sorry for breaking the thread, but I was not able to find this message as mbox-archiv. I think that the suggestions made by Hal V. Engel and Jan-Peter Homann (a well known color management consultant in Germany, afair also a member of the eci.org maillist, a very good resource for cms knowledge)are very important for a professional color management in the GIMP. I'm not a Programmer, but isn't it possible to make a plug-in which load's the icc information at a first step, to offer the user the ability to decide in which way he wants to handle the file regarding it's color space? After this step the file will be converted into the choosed colorspace[*] and then loaded into the gimp, displayed in the working colorspace, corrected by the monitor profile, with the possibility to choose a color proof view with a selectable icc profile for the soft proof. Please, correct me if I'm wrong. [*] a. no colormanagement b. working colorspace (imho don't offer the user the ability to preselect the working color space in the preferences and instead convert all files into sRGB is the worst we can do) c. apply an icc profile and then as a suboption c1. convert it into the working color space. For Gimp-print we can handle the icc like Jan-Peter Homann suggested. I agree, that this behavior would be very close to the behavior of adobe photoshop regarding color-management, which got imho a very good implementation of a colormanagement for professional needs. There are good starting points by Alastair M.Robinson blackfive [ a t ] fakenhamweb.co.uk. He made a good start of such a plugin with it's 'separate' plugin: http://www.blackfiveservices.co.uk/separate.shtml He send me a copy of an improved version for gimp 2.x . Please see this thread in gimp user: http://article.gmane.org/gmane.comp.video.gimp.user/6008 He also works on a programm called photoprint: http://www.blackfiveservices.co.uk/photoprint.shtml based on guten print for gimp. (GIMP-Print/GutenPrint version 5 (beta 2)) for example photoprint.. quote o Can apply ICC colour profiles, with selectable rendering intent. o Can generate rough-cast ICC colour profiles, given RGB Primary chromaticity coordinates (x,y), Gamma values and White Point. o Can read and use an embedded colour profile (currently TIFF only). /quote He's working on CMYK support implemented with Argyll: quote Coming soon: Support for CMYK images and profiles (useful in combination with Argyll), and widgets for dealing with physical dimensions. [...] CMYK images are not yet properly supported, but I intend to support these in future. /quote I think it's very important for the future of the gimp, to handle color management in a proper and professional way, to get it on a professional level also for pre-press image processing. Is there an existing roadmap for this issue? Thank you Gerhard Gaussling ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Color Management was GEGL development/gimp integration
Hello David, BTW: Using the gmane.org newsserver and a news client seems to be a good alternative to the mbox archive ;-). David Neary wrote: [...] Gerhard Gaußling wrote: I'm not a Programmer, but isn't it possible to make a plug-in which load's the icc information at a first step, to offer the user the ability to decide in which way he wants to handle the file regarding it's color space? It would be possible to do the following: - load image's raw data, and ICC profile - During display, convert from source colorspace to display colorspace If you apply a conversion to the file there will be a loss of color information, so it's necessary, that we avoid unneeded conversions to the original file. For example, if you convert from adobeRGB into sRGB and viceversa several times, you wouldn't receive the original color impression never more, it's lost, and there for in poor quality (comparable with the jpeg lossy compression, keep that in mind). So, we have to convert only the displayed version of the data, not the original data (Jan-Peter, Hal and others, please correct me if I'm wrong). This is important, to get a display color as closed to the original scene in nature as possible, adjusted to the display hardware by the measured or proofed monitor profile. While rendering the data for the display this way, the data itselves stays in working color space, or original color space (as choosen by the user while opening the file). It should be saved with the working color space e.g. as device independant suggested by ECI.org eciRGB.icc, which is comparable with widegammut and adobeRGB, or the original color space (as choosen by the user while opening the file), to avoid unneeded conversions while saving the data. eciRGB.icc offers a wider range of colors compared to sRGB, which got a very limited color space, so it avoids clipping, when converting e.g. from scanner profiles to the working color space. The user should archive the data in the recommended device independent colorspace (e.g. for Europe according to the suggestion of the ECI in eciRGB color space [1]). To Print the data it should be converted to the printer profile (This should happen in the service bureau or the printer service, maybe the printer offers you the printer-device profile to do the conversion by yourself. At home you can measure your inkjet profile for example, and apply that.) If you want to save your work for web you should do that by using the conversion from (the wider) working color space to sRGB the default for webpublishing. - During saving, save the originally loaded ICC profile back to file, if the format supports it, or convert to sRGB if it doesnt. This all should be flexible and interactive (there could be an easy mode coosen in the preferences to disable colormanagement at all), and it's important to retain as much original color informations than possible. The problems with that approach are - Lots of elements in the GIMP are not colorspace aware - for example, you would have to modify the paint tools to detect whether there was an ICC profile associated with a display they were painting to, and color convert the (sRGB) data that they are painting. This is not possible currently, and Sven has expressed a desire that color management be kept out of the core in the past. Okay, so I assume, that my (and Hal's and Jan-Peter's) suggestions have to wait for the release after GEGL? For a new rendering-engine further to GEGL? GIMP 3.0? I want only remember the developers that there is already a state of the art color-management used by the printing industry, which the GIMP-developers can't ignore while implementing colormanagement and CMYK or multichannel/DeviceN mode for the GIMP. Just avoid to go into the wrong direction when going further with the implementation of colormanagement. - Data which enters the image from other sources (copy paste from another image, for example) may have been in a different colorspace, requiring convertion or some other funkiness to keep things coherent inside the image Photoshop lets pop up a dialog where the user can decide the kind of conversion he will do for the pasted/dragged image. After this step the file will be converted into the choosed colorspace[*] and then loaded into the gimp, displayed in the working colorspace, corrected by the monitor profile, with the possibility to choose a color proof view with a selectable icc profile for the soft proof. We currently have the ability to do color proofs with external ICC profiles. THe interface to the loading of the profiles isn't perfect yet, but it's there. Desired is a 'On the fly' Softproof. I admit, that this is a very complex subject, and it is much work to implement all this color stuff into the GIMP, but I'm shure it's worth it. Thank you Gerhard [1]http://www.eci.org/eci/en/044_working_colour_spaces.php http://www.eci.org/eci/en
[Gimp-developer] Re: Re: Color Management was GEGL development/gimp integration
Sven Neumann wrote: You misunderstood me then. Managing colors does of course belong into the core but I would like to keep the implementation out of the core. The idea is to be able to use different color management systems and not to restrict ourselves to lcms. GEGL seems to offer just the right level of abstraction that would be needed here. That's why it seems like a nice idea to use it. That's a good point, also because in the lcms-user maillist there was a thread about Fast colour managed preview, how? , where Gerhard Fuernkranz pointed out, that Argyll's IMDI routines are _very fast_ with 8bpp input: http://sourceforge.net/mailarchive/forum.php?thread_id=6213268forum_id=1912 . regards Gerhard ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Color Management was GEGL development/gimp integration
Hello Sven, thank you for your reply! Sven Neumann wrote: Gerhard Gaußling [EMAIL PROTECTED] writes: Okay, so I assume, that my (and Hal's and Jan-Peter's) suggestions have to wait for the release after GEGL? For a new rendering-engine further to GEGL? GIMP 3.0? Why? Almost everything you listed can already be done in GIMP. It's just a bit akward to do it from a user interface point of view and that's what we want to improve for GIMP 2.4. This is good to hear! Desired is a 'On the fly' Softproof. Could you explain what you mean by on the fly softproof and how that is any different to the softproof that's available? What kind of softproof is available? Hmm.. I can nothing similar find here. I got under Image Separate Proof the possibility of an Softproof (plug in 'separate' by Alistair M. Robinson). It shows up a dialog which asks me the Source Profile /usr/lib/scribus/profiles/AdobeRGB1998.icc and the Destination Profile /usr/lib/scribus/profiles/USWebCoatedSWOP.icc (defaults, should be eciRGB.icc and isocoated.icc according to eci.org [1]) and the checkboxes Preserve Pure Black and Overprint Pure Black. If I press OK I got the message-dialog PROOF IMAGE Image is not separated So I have to separate the image first into cmyk mode by the plugin 'separate'. That's not a Softproof 'on the fly'. So I have to seperate the image first. I do it with the default profiles. A new image with the CMYK separated RGB shows up (5 layers, 4 layers CMYK mode 'darken only' 1 Background, Image in RGB Mode, if I save that it will be saved as cmyk tif). The 3rd step is to proof that image with the CMYK profile. A 3rd image pops up (RGB, 1 Layer)... That's Not a on the fly preview at all. Please, I'm sorry for my sad english, and I hope this all doesn't sounds to rude. I wanted only spend some Information of an user point of view, that's all... regards Gerhard [1] http://www.eci.org/eci/en/044_working_colour_spaces.php More information about the European Color Initiative and their work on standardisation of a color workflow: http://www.eci.org/eci/en/021_goals.php http://www.eci.org/eci/en/035_digital_photography.php http://www.eci.org/eci/en/050_news.php Here is some Information for download: http://www.eci.org/eci/downloads/ECI-en/eci_general_downloads/eci_whitepaper_1_1_ENG.pdf 46 page (~ 500 kB) Guidelines for device-independent color data processing in accordance with the ICC-Standard (Preview) Table of Content: Foreword 1. Objectives of the »European Color Initiative« 2. Objectives and Contents of the ECI-Guidelines 3. Commitment to Supporting the ICC-Standard 4. Establishing the Proof 4.1 »Idealized ICC-Proof« 4.2 »ICC-Proof« (»ICC Contract Proof«) 4.3 »ICC-Proof with Generic Profiles« (»ICC Contract Proof«) 4.4 »ICC-Soft Proof« 4.5 Proprietary Digital Proof Methods 5. Administrative Communication between »Data Supplier« and »Data Receiver« 6. Basic Workflow for Digital Processing of Printed Material 7. Technical Specifications for the Exchange of Advertisement Files 7.1 Exchange Format 7.2 Exchange Color Spaces 7.3 Overprinting and Trapping 7.4 Process and Data Control 7.5 Proofs 7.6 Data Exchange Media 8. Technical Specifications for the Exchange of Files for Catalogue Production 8.1 to 8.x 9. Technical Specifications 9.1 to 9.x Appendix 1: Recommendations for the Adaptaion of ICC-Workflows in Advertising Production Appendix 2: Recommendations for the Adaptation of ICC-Workflows in Catalogue Production Appendix 3: Recommendations for the Adaptation of ICC-Workflows in General Offset Production Appendix 4: Recommendations for the Adaptation of ICC-Workflows in Editorial and Publishing Techniques Appendix 5: Process Control The Ugra/FOGRA Media Wedge Appendix 6: »MediaStandardPrint« (not included) Appendix 7: The Corner Points of the ICC-Standard Appendix 8: »The 10 Commandments of Color Managements« Appendix 9: Example of a Measuring File in Accordance with the Color Chart ISO 12642 (IT8.7-3) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Re: Color Management was GEGL development/gimp integration
Hal V. Engel wrote: snip For those that are new to color management and would like to understand this better from a CM users perspective I would like to recommend that a good starting point is http://www.normankoren.com/color_management_2.html#Implementation%3C/A%3EHere, %20you%20helped%20me, %20again!%20%20I%20am%20learning%20how%20to%20do%20the Hello Hal, thanks for the link! This is a shorter one of the same site ;-) http://www.normankoren.com/color_management.html or the same uri like you used in a more shorter way: http://Implementing-cms.notlong.com This web site is from a color management users perspective and it starts out with a basic overview of how color management works and what all of the pieces are and how they all work together. He give examples of how to setup things in both Photoshop and Picture Window Pro. So this has lots of info about how two different apps have set up the user interface for this. Also one of the interesting things on this site is that he has the GretagMacbeth ColorChecker test pattern in both SMPTE-240M (same as AdobeRGB 1998) and sRGB color spaces. One of the patches (out of 24) is out of gamut in the sRGB version of the image but is in gamut in the SMPTE-240M image. good night Gerhard ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Color Management was GEGL development/gimp integration
Sven Neumann wrote: Go to View-Display Filters and enable the Display Proof filter. Thanks to you and Alastair to pointing that out, I'm quite impressed! Even the rendering intends are there! So I'm pleased that there is some work going on in this direction. In the GEGL TODO there is shown 0% progress for the color models and cms, that might be not related to reality! (even if this display filter is not part of GEGL) Please, I'm sorry for my sad english, and I hope this all doesn't sounds to rude. I wanted only spend some Information of an user point of view, that's all... Your feedback is very much appreciated. You're welcome! (Hope this english fits!) Kind regards Gerhard ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color Management was GEGL development/gimp integration
Am Samstag 15 Januar 2005 23:42 schrieb Gerhard Gaußling: Photoshop lets pop up a dialog where the user can decide the kind of conversion he will do for the pasted/dragged image Of course only if the source color space of the imported (pasted/dragged) image is different from the working color space. As I mentioned before the working color space is also meant as 'device independent' like recommended by eci.org, and there for suitable for archives. (The recommendations might be different for the US and other non-european states: there it might be recommend to use AdobeRGB as wotrking color space - and WebCoatedSWOPv2v as printing profile ). If the archived files are saved in (the recommended wide working color space such as eciRGB or AdobeRGB, or WideGammut) the appropriate color space, then it can be imported without flaws (w.o. popup window with the selection dialog) into theGIMP. regards Gerhard ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Color Management was GEGL development/gimp integration
Hello Sven, Sven Neumann wrote: - display profile should be adjusted _once_ systemwide (every time changeable by systemwide color preferences independant from the GIMP, as used by (e.g.)scribus [1], inkscape [2], sodipodi[3] wine e.g. for Photoshop and maaybeee by commercial apps available for *nix like Page Stream [4], Cenon [5], Viva Designer [6]) with an monitor profile (like the one of l-prof or adobe-gamma etc.), there for it would be a little overwhelming to have this choice again in the opening file dialog, if the profile doesn't fits the working color space. regards Gerhard [1] http://www.scribus.org.uk/ [2] http://www.inkscape.org [3] http://www.sodipodi.com/ [4] http://www.grasshopperllc.com/ [5] http://www.cenon.info/frame_gb.html [6] http://www.vivaip.de/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Color Management was GEGL development/gimp integration
Sven Neumann wrote: Stefan Döhla sent me a patch last year that implements this and I will probably base the changes on that. The settings he suggested are: - use CM or not - display profile - default workspace profile - default rendering intent for color conversion + from workspace to display (default set in display profile) monitor/display profile + from workspace to printer (should default to us: webcoatedSWOP for ads (coated paper) and europe: isocoated.icc (also coated paper) * perceptual for pictures * relative colorimetric for most other work) agreed, but flexible enough to set it to saturation or absolute rendering intend. - default cmyk-profile (is later used to convert RGB-CMYK) see above europe: isocoated.icc - default profile path (/usr/share/color/icc/ and ~/.color/icc/) agreed As soon as we have such settings, we need to figure out a way to make them available to plug-ins and modules. We also need an API to access the color-profile attached to an image. I like the idea of an abstract API, which can be managed by different cmm e.g. lcms or argyll This seems to be all over viewed a reasonable practice to use CMS on image manipulation. regards Gerhard ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Color Management was GEGL development/gimp integration
Gerhard Gaußling wrote: + from workspace to printer (should default to us: webcoatedSWOP for ads (coated paper) and europe: isocoated.icc (also coated paper) Only as a suggestion, please keep it flexible! * perceptual for pictures * relative colorimetric for most other work) agreed, but flexible enough to set it to saturation or absolute rendering intend. - default cmyk-profile (is later used to convert RGB-CMYK) see above europe: isocoated.icc see above, keep it flexible! You have to have the access to choose the printer profile of the device, which is used actually ! regards Gerhard ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Can't unsubscribe?
Hello all I now for some time tried to unsubscribe from this list. Unfortunately the mechanism to do so is broken. I tried to unsubscribe as told in the mails but got the attached response. Problem is, I don't anymore now my password. So I asked for help and got the answer that I could get my password from http://lists.xcf.berkeley.edu/list...(and.so.on). Problem here is, I can't get a connection to that webserver. I always get a connection-refused message. I tried it on two computers here in germany (one in the university net and one where I work). So. How do I unsubscribe? Sorry to bother you. -- cu --== Jerri ==-- Homepage: http://www.jerri.de/ ICQ: 54160208 ---BeginMessage--- This is an automated response. There were problems with the email commands you sent to Mailman via the administrative address [EMAIL PROTECTED]. To obtain instructions on valid Mailman email commands, send email to [EMAIL PROTECTED] with the word help in the subject line or in the body of the message. If you want to reach the human being that manages this mailing list, please send your message to [EMAIL PROTECTED]. The following is a detailed description of the problems. * unsubscribe Usage: unsubscribe password [email-address] ---End Message--- msg01633/pgp0.pgp Description: PGP signature
