Subject: [netatalk-admins] CRLF

From: Jan Dockx <[email-masked]>
Date: Thu, 25 Jun 1998 09:55:18 +0200

An experience that is worth sharing:

When first installing netatalk, I had a long talk with myself deciding
whether or not to activate eol-translation (-DCRLF in afpd Makefile). I
found no convincing reason to choose one or the other. Both seemed to have
advantages and disadvantages, but none definite. There is no real problem
when you use a text editor that deals with different file system standards
transparently, like BBEdit, and will not put "anonymous" binaries on the
server to be used by a Mac.
I decided to enable translation, because it was the default in the package.

Now I have a definite reason why it should _not_ be enabled: pdf files.
Adobe Acrobat pdf files have TEXT/CARO as file type and creator, and get
translated. But the format doesn't allow that: opening valid pdf files from
a netatalk server with eol-translation enabled shows blank documents.
So I advise you to disable the eol-translation, and advise distributionists
to change the default.

Jan

Jan Dockx - assistent               ([email-masked])
K.U.Leuven, Department of Computer Science
Celestijnenlaan 200 A 03.28; 3001 Heverlee; Belgium
tel.: ++ 32/16/32 76 56                   fax.: ++ 32/16/32 79 96
<http://www.cs.kuleuven.ac.be/~jand/>
+---------------------------------------------------------------+
  "There's some joke making around about some mathematician
   that said that 1000 chimpansees in 1000 years sitting at
   1000 typewriters would eventually write the works of
   Shakespeare. And the snap around the joke is that the Web
   proves this is not so."
                                Kurt Vonnegut about the Internet
                                in "Vonnegut's Timequake; All
                                Things Considered, September 22,
                                1997; National Public Radio"

---

From: "Gerry.Tomlinson" <[email-masked]>
Date: Thu, 25 Jun 1998 09:47:08 +0100 (BST)

> So I advise you to disable the eol-translation, and advise distributionists

The type should not be TEXT. The Distiller produces pdf files with
type/creator PDF /CARO.

	Gerry

---
[email-masked]
Computing Officer
Department of Computing Science, University of Newcastle, Tel: +44 191 222 8139
Newcastle upon Tyne, NE1 7RU, United Kingdom.             Fax: +44 191 222 8232

---

From: thomas <[email-masked]>
Date: Thu, 25 Jun 1998 10:29:44 +0200 (CEST)

same with ps from quark-print ... 
there also you should get rid of crlf-translation

---

From: David Hamm <[email-masked]>
Date: Thu, 25 Jun 1998 15:58:29 -0400 (EDT)

I've allways felt that it was strange to have networking software also do
conversions.  The -DCRLF feature has caused a number of problems for me
too.  The solution might be to modify AFPD so that it only does CRLF
translation on cirtan directorys.

---

From: Vivek <[email-masked]>
Date: Fri, 26 Jun 1998 13:11:16 +0100 (BST)

> > Adobe Acrobat pdf files have TEXT/CARO as file type and creator, and get

That is strange - they seem to be set as 'PDF /CARO' here... which as you
can imagine, works fine. Odd. I've found a useful trick is to set the
default translation to BINA/UNIX, so you only get translation on files
specified by a Mac as being TEXT/<blah>. Solved all of my CRLF problems.

-- 
fsck -f -b 8193 /dev/cortex

---

From: Kadinger Andras <[email-masked]>
Date: Fri, 26 Jun 1998 16:21:22 +0200 (CEST)

> specified by a Mac as being TEXT/<blah>. Solved all of my CRLF problems.

However, some versions of Word from the Gates empire were reported to
create files with type TEXT, save their proprietary binary format into it,
and then change the type to the correct one; this case would be a point
against using CRLF, at least in it's current form. I wonder, what happened
to my CRLF_TWOWAY patch (making even translated files binary compatible
when read again on the Mac), which could be extended also to eliminate
gotchas like the one described above by translating on-disk data when
changing type (this would be slow, but at least would 'unbreak' some CRLF
issues). Who knows, someone even might want to extend it to translate
between charsets in text file data (of course, with configuration
possibilities).

Is anyone interested in having the above features?

Sincerely,
Andras Kadinger
[email-masked]

---

From: Sak Wathanasin <[email-masked]>
Date: Fri, 26 Jun 1998 18:47:09 +0100

In reply to Jan Dockx's message of the 25/06/98 at 09:55 +0200,

> Adobe Acrobat pdf files have TEXT/CARO as file type and creator, and get

PDF files have type/creator PDF /CARO here. Did you get them off some PeeCee
box?

-DCRLF works just fine for me as long as I set the default mapping to be binary
(in the AppleVolumes.system file. It allows me, for example, to view "read me"
files with "vi" or SimpleText as the mood takes me.

Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [email-masked]
Phone: (+44) 1203 419996                    Fax: (+44) 1203 690690

---

From: Vivek <[email-masked]>
Date: Tue, 30 Jun 1998 15:30:32 +0100 (BST)

> between charsets in text file data (of course, with configuration

Having CRLF work automagically both ways so that files mistranslated one
way could be fixed by putting them back through the other way... sounds
useful.. how would this work, flipping \r --> \n and \n --> \r for a
file of type TEXT every time it went through afpd?

-- 
No good deed goes unpunished.

---

From: Andras Kadinger <[email-masked]>
Date: Tue, 30 Jun 1998 17:22:10 +0200

[I snet this to Vivek before, but as Chip Mefford might suffer from the
same problems, I resend it to the list.]

> file of type TEXT every time it went through afpd?

Exactly. When You write into a file with type TEXT, afpd would convert
the data, and write it \r <--> \n excanged to the disk, and would swap
back when reading. The current implementation does \r --> \n in the one
way, and \n --> \r in the other.

Although swapping makes translation binary transparent, and therefore is
generally beneficial, current netatalk 'canonizes' line endings, that
is, it makes all line endings to be the same, while swapping does not;
this might upset people in obscure environments, where 'canonization' is
required. Also, in itself this does not solve problems like the one
described with Word; for that, on-disk translation is needed.

Unfortunately I can not find the patch on my machine, but I sent it to
the list before, so it should be in the archives. Alternatively, I can
re-create it if You ask me.

Sincerely,
Andras Kadinger
[email-masked]