Hi,

John Culleton writes:

some thngs are improved in 2.0 with respect to the handling of PostScript files, but some annoyances remain. Since my major use of Gimp is the refinement of PS images I thought I might list them.

Refining PS images with GIMP is a very bad idea. It's either the wrong file format or you are using the wrong tool for the job.

1. When importing a PS file the default resolution is 100. I routinely scan and use images at 150. Once I change the resolution the new number persists for the session but the next sesson starts all over again with the default.

http://bugzilla.gnome.org/show_bug.cgi?id=63610

Persistent plug-in settings need to be addressed more generally. Not likely to happen for 2.2 since it depends on the PDB revamp.

3. If i bring in a PS file, modify it in some way, and then just "save" the file what I save is the original unmodified file (or perhaps nothing at all?) If I hit "save as" then the modified file is saved, after some conversation.

If you open a PS in GIMP, it is rasterized and it's impossible to save an unmodified version. The file is modified on load already.

4. The save PS defaults to 5 units of offset, x and y. I must zero these out individually.

5. I save PS files as EPS. The default is PS. I must change it on each run.

6. The default unit of measurement is millimeters. I must convert it to inches on each run.

See above.

If my changes could just be made persistent from run to run tht would be great. Or if I could have access to the module where the Postscript reading and writing takes place then perhaps I could change some defaults in the code. Can anyone suggest what that module's name is?

plug-ins/common/postscript.c

I strongly suggest you change your workflow. If you want to edit scanned images, then don't use Postscript. If you need to edit PS, then use a tool that handles Postscript. GIMP is the wrong tool here.

Sven

So far, all you need seems to resolve if the plug-in can just remember the last values used.

I will see for that. Meanwhile, feel free to check http://bugzilla.gnome.org/show_bug.cgi?id=138583 and add your comments - it is were I am keeping track of the enhancements I plan to make for the postscript plug-in.

Your file? gimp/plug-ins/common/postscript.c

Regards,

JS ->

On Saturday 10 April 2004 02:36, John Culleton wrote:

some thngs are improved in 2.0 with respect to the handling of PostScript files, but some annoyances remain. Since my major use of Gimp is the refinement of PS images I thought I might list them.

1. When importing a PS file the default resolution is 100. I routinely scan and use images at 150. Once I change the resolution the new number persists for the session but the next sesson starts all over again with the default.

2. Similarly, I always work in grayscale with PS files. The default is color. I can't change the default in any permanent way.

3. If i bring in a PS file, modify it in some way, and then just "save" the file what I save is the original unmodified file (or perhaps nothing at all?) If I hit "save as" then the modified file is saved, after some conversation.

4. The save PS defaults to 5 units of offset, x and y. I must zero these out individually.

5. I save PS files as EPS. The default is PS. I must change it on each run.

6. The default unit of measurement is millimeters. I must convert it to inches on each run.

If my changes could just be made persistent from run to run tht would be great. Or if I could have access to the module where the Postscript reading and writing takes place then perhaps I could change some defaults in the code. Can anyone suggest what that module's name is?

Hi,

"Joao S. O. Bueno" writes:

So far, all you need seems to resolve if the plug-in can just remember the last values used.

I will see for that. Meanwhile, feel free to check http://bugzilla.gnome.org/show_bug.cgi?id=138583 and add your comments - it is were I am keeping track of the enhancements I plan to make for the postscript plug-in.

None of your enhancement solve the real problem here which is that Postscript is the wrong file format. GIMP will never be able to handle Postscript files good enough that one would attempt to use GIMP to open and manipulate them. With your changes, GIMP will be able to create better Postscript files, but that still doesn't make Postscript the right format for storing scanned image data.

Perhaps it would be better to remove that kludge of calling GS to be able to open Postscript files and make the postscript plug-in write-only. Way too many users are tricked into believing that GIMP would be able to manipulate Postscript files.

Sven

Hi,

John Culleton writes:

Now I could of course scan to an pnm or png image instead of Postscript. (I could still save as Postscript from Gimp.) Which would be preferable for input to Gimp, pnm or png?

PNG would be very well suited and I really don't understand why you used PS in the first place.

(In earlier Gimps I could of course scan directly from Xsane into Gimp but this option disappeared with Gimp 1.3/2.0 and an early reappearance seems unlikely. )

Now I am slowly starting to become angry. Why do you spread such misinformation? You are on this list for a while now and you should know that XSane works with GIMP 2.0 after a few trivial modifications. If the XSane maintainer is really unwilling to do a release of XSane that works with GIMP 2.0, then it would be just a matter of asking me or any other GIMP developer to provide a patch for it.

As a point of interest, some pages in my workflow are not scanned but are created by the mup music typesetting program. These are also in PostScript form. Since they are true typeset PostScript and not a bitmapped image they are about 10% as large as the comparable scanned image presented as a ps file.

It's probably not such a good idea to edit these files with GIMP then. Opening them with GIMP will rasterize the fonts. The result will be OK if the resolution is well choosen but it will be comparably poor if you decide to change the print resolution later.

To summarize, I can scan to png or pnm instead of PostScript and import that into Gimp. But I need eps output for my present method. If I switch to pdftex then I could utilize png output.

Are there advantages to using e.g., png throughout?

PNG files are probably smaller but there are no fundamental reasons against using EPS as the output format.

Sven

* Sven Neumann [04-12-04 15:32]:

Now I am slowly starting to become angry. Why do you spread such misinformation? You are on this list for a while now and you should know that XSane works with GIMP 2.0 after a few trivial modifications. If the XSane maintainer is really unwilling to do a release of XSane that works with GIMP 2.0, then it would be just a matter of asking me or any other GIMP developer to provide a patch for it.

A patch is available @ xsane.org: http://people.debian.org/~jblache/misc/xsane-0.92_gimp2.0.patch

His comments:

2004 Mar 21: What about support for gimp-2.0? I got a patch for xsane to add support for gimp-2.0. It is really large and I will need some time to look through it and test it with different gimp versions before I apply it to my sourcecode. But here you can download the xsane-0.92_gimp2.0.patch by Julien Blache. Please give positive and negative feedback about this patch to me. I am also interested in experiences with this patch with gimp-1.0.x and gimp-1.2.x versions.

Hi,

John Culleton writes:

OK, please don't be angry. I raised this issue before, was referred to the Xsane maintainer, and got a discouraging reply from him. He had two patches in hand, one short and one longer, and didn't seem to be in a hurry to implement either one. If you have a patch that will solve the problem I would be happy to have it.

Well, I tried to handle it the right way which is to pass the patch to the maintainer instead of publishing it. Looking at the XSane homepage shows that Oliver Rauch published the patch in the meantime:

http://www.xsane.org/

He claims the patch would be rather large but if he would take a closer look he would probably notice that the patch changes autogenerated files. The actual change is tiny.

Sven