Hi,

Frank Noack writes:

As first the good, i can print now with gimp2.0pre4. And now the bad. If i use a ppd file in the preferences from postscript level2 in gimp i lost the preview and i get no printer output. Only if i dont use a ppd file for my Stylus 670 with turboprint driver i get a preview and a good print. I use Suse 8.2 with updatet ghostscript7.07.1rc1 (gimp-print 4.2.6), turboprint1.86, cups1.1.18.

This is a problem with gimp-print. Although the gimp-print library has gimp in the name, the GIMP developers as represented on this list, are not involved with the gimp-print project. Thus we cannot help you.

Please check the gimp-print homepage at http://gimp-print.sourceforge.net/. There should be information on how you can get your question answered.

Sven

From: Sven Neumann
Date: 13 Mar 2004 12:03:21 +0100

Frank Noack writes:

> As first the good, i can print now with gimp2.0pre4. And now the > bad. If i use a ppd file in the preferences from postscript > level2 in gimp i lost the preview and i get no printer > output. Only if i dont use a ppd file for my Stylus 670 with > turboprint driver i get a preview and a good print. I use Suse > 8.2 with updatet ghostscript7.07.1rc1 (gimp-print 4.2.6), > turboprint1.86, cups1.1.18.

This is a problem with gimp-print. Although the gimp-print library has gimp in the name, the GIMP developers as represented on this list, are not involved with the gimp-print project. Thus we cannot help you.

Please check the gimp-print homepage at http://gimp-print.sourceforge.net/. There should be information on how you can get your question answered.

Also try using the native driver (rather than turboprint) -- Gimp-Print has a built-in driver for the 670 that will give you access to more features. Finally, make sure that the PPD file you're giving it exists and is readable.

Hi Frank,

Frank Noack wrote:

Its the same problem that i had before. It works fine with build in language (en) if i use it in german it fails. Now i can print with Turborint but without ppd-file. I show at http://gimp-print.sourceforge.net/

You might try updating to gimp-print 4.2.6 - there were some problems with localisation in earlier versions of gimp-print 4.2.x which have been fixed since (there is even a message about this when you run configure in the GIMP source tree).

Cheers, Dave.

Hi,

Frank Noack writes:

Its the same problem that i had before. It works fine with build in language (en) if i use it in german it fails. Now i can print with Turborint but without ppd-file. I show at http://gimp-print.sourceforge.net/

Did you update to gimp-print 4.2.6 yet ?

Sven

Note to the gimp-print developers: You should consider to stop using scanf() and similar locale-dependant functions to read your config files. Setting LC_NUMERIC to C is a workaround but it's rather ugly and easy to forget.

Sven Neumann writes:

Note to the gimp-print developers: You should consider to stop using scanf() and similar locale-dependant functions to read your config files. Setting LC_NUMERIC to C is a workaround but it's rather ugly and easy to forget.

What should be used instead (given that Standard C does not have locale objects)?

Hi,

Roger Leigh writes:

Sven Neumann writes:

Note to the gimp-print developers: You should consider to stop using scanf() and similar locale-dependant functions to read your config files. Setting LC_NUMERIC to C is a workaround but it's rather ugly and easy to forget.

What should be used instead (given that Standard C does not have locale objects)?

http://developer.gnome.org/doc/API/2.0/glib/glib-String-Utility-Functions.html#g-ascii-strtod http://developer.gnome.org/doc/API/2.0/glib/glib-String-Utility-Functions.html#g-ascii-dtostr http://developer.gnome.org/doc/API/2.0/glib/glib-String-Utility-Functions.html#g-ascii-formatd

Sven

Sven Neumann writes:

Hi,

Roger Leigh writes:

Sven Neumann writes:

Note to the gimp-print developers: You should consider to stop using scanf() and similar locale-dependant functions to read your config files. Setting LC_NUMERIC to C is a workaround but it's rather ugly and easy to forget.

What should be used instead (given that Standard C does not have locale objects)?

http://developer.gnome.org/doc/API/2.0/glib/glib-String-Utility-Functions.html#g-ascii-strtod http://developer.gnome.org/doc/API/2.0/glib/glib-String-Utility-Functions.html#g-ascii-dtostr http://developer.gnome.org/doc/API/2.0/glib/glib-String-Utility-Functions.html#g-ascii-formatd

I wish we were able to use Glib :-(

From: Roger Leigh
Date: Sat, 13 Mar 2004 20:29:09 +0000

Sven Neumann writes:

> Roger Leigh writes: >
>> Sven Neumann writes:
>>
>> > Note to the gimp-print developers: You should consider to stop using >> > scanf() and similar locale-dependant functions to read your config >> > files. Setting LC_NUMERIC to C is a workaround but it's rather ugly >> > and easy to forget.
>>
>> What should be used instead (given that Standard C does not have >> locale objects)?
>
> http://developer.gnome.org/doc/API/2.0/glib/glib-String-Utility-Functions.html#g-ascii-strtod > http://developer.gnome.org/doc/API/2.0/glib/glib-String-Utility-Functions.html#g-ascii-dtostr > http://developer.gnome.org/doc/API/2.0/glib/glib-String-Utility-Functions.html#g-ascii-formatd

I wish we were able to use Glib :-(

Just to make it clear: the reason we don't use Glib in the core is that it isn't part of the standard load on a lot of platforms (in particular, OS X). We've had enough issues on OS X with Ghostscript, which is *necessary* (there's no workaround whatsoever) in a lot of cases; OS X users want a single binary blob. We've made a conscious choice that we're going to play as well as possible with the working methods of OS X users. OS X users are already suspicious enough of the UNIX core (command line geeks) and don't want to be reminded of the fact. They see their computers as appliances.

I suppose there would be an option to bundle a binary of Glib in with Gimp-Print, but that would certainly complicate matters some. In general, we want to stay on the trailing edge with non-core functionality, such as utility libraries and language features.

I tried a while back to install Gnumeric on my SuSE 8.1 (not even 18 months old) systems, and it was a horrible mess indeed. I had to install more or less the entire GNOME stack, and that caused other problems with older Gnome 2 stuff in SuSE. I did get Gnumeric to work, but too many other things fell apart as a result and I had to back it out. Gimp-Print is core printer functionality for a lot of people, and they won't be too sympathetic to issues like this. If there's no way around it, we can crib code, which we would then have to maintain.

If the problem's with the Print plugin or libgimpprintui, we can obviously afford to use Glib 1.2 (there are lots of GIMP 1.2 users out there, and I don't want to break them).

Hi,

Robert L Krawitz writes:

Just to make it clear: the reason we don't use Glib in the core is that it isn't part of the standard load on a lot of platforms (in particular, OS X). We've had enough issues on OS X with Ghostscript, which is *necessary* (there's no workaround whatsoever) in a lot of cases; OS X users want a single binary blob. We've made a conscious choice that we're going to play as well as possible with the working methods of OS X users. OS X users are already suspicious enough of the UNIX core (command line geeks) and don't want to be reminded of the fact. They see their computers as appliances.

I really don't want to get into an argument with you but glib-2.0 (or rather 2.2 and soon 2.4) works just fine on MacOS X, is easy to install through fink or darwinports and it would help you to avoid a good deal of code duplication.

I tried a while back to install Gnumeric on my SuSE 8.1 (not even 18 months old) systems, and it was a horrible mess indeed. I had to install more or less the entire GNOME stack, and that caused other problems with older Gnome 2 stuff in SuSE.

gnumeric is a GNOME application. Of course it needs a full GNOME stack. We are talking about glib here, which has no dependencies.

If the problem's with the Print plugin or libgimpprintui, we can obviously afford to use Glib 1.2 (there are lots of GIMP 1.2 users out there, and I don't want to break them).

glib-1.2 doesn't have the functionality you need in order to handle the problem this thread started about. Besides that, it is not any longer maintained and it is missing support for Unicode and UTF-8 and you can hardly get away without that nowadays.

Sven

From: Sven Neumann
Date: 14 Mar 2004 01:33:10 +0100

Robert L Krawitz writes:

> Just to make it clear: the reason we don't use Glib in the core > is that it isn't part of the standard load on a lot of platforms > (in particular, OS X). We've had enough issues on OS X with > Ghostscript, which is *necessary* (there's no workaround > whatsoever) in a lot of cases; OS X users want a single binary > blob. We've made a conscious choice that we're going to play as > well as possible with the working methods of OS X users. OS X > users are already suspicious enough of the UNIX core (command > line geeks) and don't want to be reminded of the fact. They see > their computers as appliances.

I really don't want to get into an argument with you but glib-2.0 (or rather 2.2 and soon 2.4) works just fine on MacOS X, is easy to install through fink or darwinports and it would help you to avoid a good deal of code duplication.

Fink and Darwinports are simply not options for mainline OS X users. Mac users want to literally buy a machine and turn it on. Think about what happens when you buy a lamp, you plug it into the wall and turn it on. They're amazingly close to that, with things like Airport.

From a user engineering standpoint, it's a tour de force.

Fink Commander (a GUI interface to Fink) is quite difficult to set up. It's not trivial for me, and I understand things like CVS, and I know the relationships between the different packages. Macintosh users don't, and they absolutely don't want to. We've had this discussion before in a different context. I don't think that most people in the free software world really understand this point.

From an software engineering standpoint I want to avoid code

duplication. From a user perspective, architecture and implementation don't help them get their job done.

> I tried a while back to install Gnumeric on my SuSE 8.1 (not even > 18 months old) systems, and it was a horrible mess indeed. I had > to install more or less the entire GNOME stack, and that caused > other problems with older Gnome 2 stuff in SuSE.

gnumeric is a GNOME application. Of course it needs a full GNOME stack. We are talking about glib here, which has no dependencies.

Fair enough.

> If the problem's with the Print plugin or libgimpprintui, we can > obviously afford to use Glib 1.2 (there are lots of GIMP 1.2 users > out there, and I don't want to break them).

glib-1.2 doesn't have the functionality you need in order to handle the problem this thread started about. Besides that, it is not any longer maintained and it is missing support for Unicode and UTF-8 and you can hardly get away without that nowadays.

I think we have a problem when something goes from current to obsolete in 18 months. I upgrade my systems roughly every 3 releases; SuSE spaces releases 6-8 months apart, so we're talking an 18-24 month cycle. Note what happened when Microsoft tried to drop support for Windows 98 (which is somewhat older); even they were forced to backtrack; a lot of people are still using Windows 95 and earlier because it works for them. Dropping support for GIMP 1.2 simply means that people won't be able to use Gimp-Print 5.0 with it.

I want Gimp-Print to be at the bleeding edge of printer quality and support, on both current and older printers (we still get a lot of questions about printers such as the Epson 3000 and even the 600, which is at least 6 years old). Note that theoretical support for a printer is useless if it won't run on somebody's system, so we've deliberately been very conservative about adopting newer support technologies.

Hi,

Robert L Krawitz writes:

Fink and Darwinports are simply not options for mainline OS X users. Mac users want to literally buy a machine and turn it on. Think about what happens when you buy a lamp, you plug it into the wall and turn it on. They're amazingly close to that, with things like Airport.

From a user engineering standpoint, it's a tour de force.

Afak, you can build binary images from darwinport packages with a single command. If you provide such an image file to your users, it's a matter or dragging the file onto the finder and the software is installed, ready to be used. But certainly you know about this and I assume that this is the way you are offering the gimp-print software to MacOS X users. It would be easy to include glib2 as part of this gimp-print image file.

I think we have a problem when something goes from current to obsolete in 18 months.

That's a rather long time and since you are developing a new version of gimp-print at the moment, you should seriously consider to base it on libraries that are current and not something that dates back to the year 2001. A lot has happened since then. I don't have glib-1.2 installed any longer on any of the computers I am using. You can expect that this will be the case for most if not all distributions emerging over the next months.

Sven

From: Sven Neumann
Date: 14 Mar 2004 02:50:09 +0100

Robert L Krawitz writes:

> Fink and Darwinports are simply not options for mainline OS X > users. Mac users want to literally buy a machine and turn it on. > Think about what happens when you buy a lamp, you plug it into > the wall and turn it on. They're amazingly close to that, with > things like Airport. >From a user engineering standpoint, it's a > tour de force.

Afak, you can build binary images from darwinport packages with a single command. If you provide such an image file to your users, it's a matter or dragging the file onto the finder and the software is installed, ready to be used. But certainly you know about this and I assume that this is the way you are offering the gimp-print software to MacOS X users. It would be easy to include glib2 as part of this gimp-print image file.

That's what I meant; that would be a possibility. We would just need to make sure it didn't collide with anything else. I prefer to minimize the amount of stuff we install in the background, but that could conceivably be an option. Whether it's worthwhile is a second question.

> I think we have a problem when something goes from current to > obsolete in 18 months.

That's a rather long time and since you are developing a new version of gimp-print at the moment, you should seriously consider to base it on libraries that are current and not something that dates back to the year 2001. A lot has happened since then. I don't have glib-1.2 installed any longer on any of the computers I am using. You can expect that this will be the case for most if not all distributions emerging over the next months.

It's a long time for developers who are used to living on the bleeding edge. It's not a long time for end users who don't want to upgrade something that works. Like I said, note that even Microsoft was forced to backtrack when they tried to force people off Windows 98.

On Sat, Mar 13, 2004 at 09:11:02PM -0500, Robert L Krawitz wrote:

From: Sven Neumann
Date: 14 Mar 2004 02:50:09 +0100

Robert L Krawitz writes:

> Fink and Darwinports are simply not options for mainline OS X > users. Mac users want to literally buy a machine and turn it on. > Think about what happens when you buy a lamp, you plug it into > the wall and turn it on. They're amazingly close to that, with > things like Airport. >From a user engineering standpoint, it's a > tour de force.

Afak, you can build binary images from darwinport packages with a single command. If you provide such an image file to your users, it's a matter or dragging the file onto the finder and the software is installed, ready to be used. But certainly you know about this and I assume that this is the way you are offering the gimp-print software to MacOS X users. It would be easy to include glib2 as part of this gimp-print image file.

That's what I meant; that would be a possibility. We would just need to make sure it didn't collide with anything else. I prefer to minimize the amount of stuff we install in the background, but that could conceivably be an option. Whether it's worthwhile is a second question.

Why not just statically link to glib 2 when you make the OS X binary build? Seems that'd solve this whole issue nicely.
-Yosh

Hi,

Robert L Krawitz writes:

Afak, you can build binary images from darwinport packages with a single command. If you provide such an image file to your users, it's a matter or dragging the file onto the finder and the software is installed, ready to be used. But certainly you know about this and I assume that this is the way you are offering the gimp-print software to MacOS X users. It would be easy to include glib2 as part of this gimp-print image file.

That's what I meant; that would be a possibility. We would just need to make sure it didn't collide with anything else. I prefer to minimize the amount of stuff we install in the background, but that could conceivably be an option. Whether it's worthwhile is a second question.

Such an image file is kept seperate from the rest of the system. So there's no chance that whatever library you add there could collide with other software on the system. Assumed that I understood this correctly, but that's what I have been told by MacOS X developers...

Sven

Hi,

Frank Noack writes:

Its the same problem that i had before. It works fine with build in language (en) if i use it in german it fails. Now i can print with Turborint but without ppd-file. I show at http://gimp-print.sourceforge.net/

Did you update to gimp-print 4.2.6 yet ?

Yes i did :-)
And it works, but not with using ppd file. With LANG=en it works completly

Well, we, as the GIMP developers, have a couple of options to workaround this problem:

(a) Run the print plug-in with LC_NUMERIC set to C. This will change how numbers are displayed in the user interface. For some locales, there's no difference, some will differ in the use of the decimal separator and for other locales, there might be other changes.

(b) Temporarily switch LC_NUMERIC to C while running any gimp-print calls. I have no idea if this is feasible. Someone would have to check if this can be done in a sane way.

We used to do (a) for all plug-ins and the core in GIMP-1.2 but it was a lousy workaround and we are happy that we finally got rid of it. Now that the GUI is properly localized, it might be confusing to have a single plug-in that displays numbers differently. Solution (b) however is error-prone. Any comments anyone?

Sven

On Mar 14, 2004, at 12:54 pm, Sven Neumann wrote:

Such an image file is kept seperate from the rest of the system. So there's no chance that whatever library you add there could collide with other software on the system. Assumed that I understood this correctly, but that's what I have been told by MacOS X developers...

Not quite correct. There're concepts that permit having several versions of some resource around without conflicting called a framework, another would be an application bundle. Depending on what exactly one wants to achieve one is more suitable than another. If you want to provide resources for several applications you can only use frameworks which are a pain in the butt to manage, especially without using XCode. Application bundles are easier to create and very useful, but they'll only work in a selfcontained fashion.

So if one wants to create a selfcontained GIMP package, an application bundle would be more than nice. However this package needs to contain all possible plugins and other stuff, later extension is not trivially possible.

Servus,
Daniel

From: Sven Neumann
Date: 13 Mar 2004 13:10:08 +0100

Frank Noack writes:

> Its the same problem that i had before. It works fine with build in > language (en) if i use it in german it fails. Now i can print with > Turborint but without ppd-file. I show at > http://gimp-print.sourceforge.net/

Did you update to gimp-print 4.2.6 yet ?

Frank, have you tried the patch I sent you? This is the last outstanding 4.2.7 release stopper and I'd like it tested so that we can proceed with our release.

From: Frank Noack
Date: Sun, 21 Mar 2004 12:04:34 +0100

Am Freitag, 19. März 2004 03:38 schrieb Robert L Krawitz: > From: Sven Neumann
> Date: 13 Mar 2004 13:10:08 +0100 >
> Frank Noack writes:
> > Its the same problem that i had before. It works fine with build in > > language (en) if i use it in german it fails. Now i can print with > > Turborint but without ppd-file. I show at > > http://gimp-print.sourceforge.net/ >
> Did you update to gimp-print 4.2.6 yet ? >
> Frank, have you tried the patch I sent you? This is the last > outstanding 4.2.7 release stopper and I'd like it tested so that we > can proceed with our release.

Yes i updated. The patch did not work for me, but i downloadet revision print-ps.c,v 1.26.2.6 2004/03/19 02:35:54 from the cvs tree. I compiled it with the src.rpm ghostscript-library-7.07.1rc1 from suse and now it works fine. I can print and i can use the ppd files. Thanks for your help, and sorry for my late answer. But i am not an big patcher and my english is .... Its a hard way for me but i like it.

Thanks!