> Did you recompile it without -DCRLF as I suggested? That fixed it for
> me - you may be doing something wrong.
> Imposition and booklets for PDF - http://www.quite.com/imposing/
I did. I put the "#" exactly one space in front of the -DCRLF in the
/user/local/atalk/etc/afpd/Makefile. I even tried deleting the -DCRLF.
I checked the Makefile (main one) for the DESTDIR, it is
I deleted all the files and directories in /usr/local/atalk and saw that
they were recreated after the make and make install.
I checked the date of the afpd and atalkd to insure they were the ones
created at the most recent make.
I check my rc.local to be sure I was calling the rc.atalk that is in the
I rebooted after a make/make install.
If I'm doing something wrong I'd sure like to know what.
I'm using Freebsd 2.2.7 and netatalk1.4b2+asun2.1.1
The words that are ringing in my head right now come from John Doherty
who lambasted me a while back about messing with dicey solutions when he
suggested I just get over it and get a real server.
I think John is/was right. I've wasted so many man hours on a user
supported-sometimes it works-sometimes it doesn't OS that it is starting
to become clear to me why Sun gets the money they do.
I will still continue playing with this because it's interesting to me
but I give up hope at this point that it is a viable solution for a
professional prepress department. I have to move on, time is money.
I certainly appreciate any and all help I've received but, it remains
broken. If anybody can see in my statements above, how I could have
overlooked some simple thing, I'd owe you bigtime.
This is a major problem. The contents of a postscript file have been
altered by simply copying them to a server disk. That is scary.
And to the programmers of netatalk I hope you make it much easier to
turn this off. PostScript is the backbone of commercial prepress and
PostScript files are TEXT files.
Altering the contents of any file is in my opinion a bad thing. A server
should remain neutral in file handling and just take the data and store
it. This concept of translating the line endings in a PostScript file
can't have any good effects for anybody. There have been many dos to
unix utilities that can handle this on a file by file demand. To have it
the default in a networking os is a failure by the original programmers
to observe the importance that we as users place on knowing our data
hasn't been altered.
To anyone considering using netatalk I caution, beware. The first time
your postscript file won't rip and spits out an "offending command:" you
will have to wonder if you are a victim of this problem.
I believe open source products have a place in our future. I really
believe that this will eventually corrected. I for one, can't wait.