The pstopxl CUPS filter fails on Mac OS X. The sed -r flag is not used in Mac OS X. The -E flag should be used for extended regular expressions. Changing all instances of 'sed -nre' to 'sed -nEe' corrects the problem and allows the pstopxl filter to work properly. Perhaps congifure could check to see if sed uses -r or -E and the /cups/pstopxl filter changed appropriately during build.
That would be a GNU sed (textutils/coreutils?) vs BSD sed issue. I suspect there are many GNU-isms which are not applicable to their BSD equivalents in the scripts, as ghostscript get more used on Mac OS X. We probably should stick to the opengroup posix specifications - there is one for "find", and a corresponding one for 'sed'. http://opengroup.org/onlinepubs/007908799/xcu/sed.html Hmm, it looks like -E is a BSD-ism and -r is an GNU-ism, but the script itself definitely needs one of them. Tough. We might have to do case OS) here.
Sorry, the relevant latest version of the spec, and the regular expression part: http://opengroup.org/onlinepubs/007908799/xcu/sed.html http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03 I would suggest re-write without requring extended regular expressions, just the basic facility.
The best solution is to replace the pstopxl shell script by a C program which uses the CUPS library to read out the relevant option settings. The program could have the same structure as pdftoraster.
(In reply to comment #3) > The best solution is to replace the pstopxl shell script by a C program which > uses the CUPS library to read out the relevant option settings. The program > could have the same structure as pdftoraster. Re-write to C program isn't happenning any time soon (and nobody is doing it), so I probably will see if I can fix the scripts as I outlined aove in comment 2.
commit r11446 tries to check if sed is GNU and if not, switch over to alternative behavior. So after the commit, systems with GNU sed would behave correctly as it did, but systems with an identifiable non-GNU sed such as Mac OS X would switch over to use the Mac OS X/BSD like options. This covers two of the main unix OSes. One other systems I checked was Tru64, on which the system sed does not support either form of extended regular expression syntax. This is likely the case for many older Unix systems; beside Linux (GNU systems) and Mac OS X, perhaps the next unix systems worth looking at is Solaris - somebody might want to report whether solaris ships GNU sed, has a system sed that works like Mac OS X, or a system sed that does not support either form (like Tru64). In any case, before the commit, the pstopxl assumes sed is GNU sed (and breaks on systems where the system sed behaves significantly differently); after the change it would assume any non-GNU sed works like BSD's, so that's an improvement. This change does not cover all legacy unix systems where the system sed does not support either form of extended regular expressions, nor where the system sed tries to behaves like GNU sed but is implemented independently.