+oem5hCq0M2YtR==zBi (3491B)
1 Return-Path: <develop!nextmime@ebony@sblab.att.com> 2 Received: from thumper.bellcore.com by greenbush.bellcore.com (4.1/4.7) 3 id <AA17475> for nsb; Fri, 25 Sep 92 21:30:21 EDT 4 Received: from att.att.com (att-out.att.com) by thumper.bellcore.com (4.1/4.7) 5 id <AA23256> for nsb@greenbush; Fri, 25 Sep 92 21:30:19 EDT 6 From: develop!nextmime@ebony@sblab.att.com 7 Received: from ebony by develop (5.59/25-eef) 8 id AA28800; Fri, 25 Sep 92 14:08:15 PDT 9 Received: by ebony (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) 10 id AA00975; Fri, 25 Sep 92 14:13:02 PDT 11 Date: Fri, 25 Sep 92 14:13:02 PDT 12 Original-From: develop!nextmime@ebony (NeXT MIME Prototype) 13 Message-Id: <9209252113.AA00975@ ebony > 14 Received: by NeXT Mailer (1.63) 15 To: @develop:sblab!att!thumper.bellcore.com!nsb 16 Subject: More richtext questions/comments 17 Cc: robb@develop 18 Mime-Version: 1.0 19 Content-Type: multipart/mixed; boundary=tmrob 20 Content-Length: 2579 21 22 23 --tmrob 24 content-type: text/richtext 25 26 27 <Indent> 28 29 <IndentRight> 30 31 <bigger> 32 Nathaniel, 33 <nl> 34 35 <nl> 36 I think the biggest problem with point size in the mail I sent you earlier was my own 37 <nl> 38 misinterpretation of the rtf "fs" command. It was not documented in my (sparse) 39 <nl> 40 RTF documentation but I guessed from context that it was point size. I've done more 41 <nl> 42 experimenting since then and concluded that it is consistently twice point size. So 43 <nl> 44 instead of a mixture of 12 to 24 point my previous message to you was 24 to 48 point. 45 <nl> 46 I didn't see it here because I either read it with metamail and no font software, or looped 47 <nl> 48 it back and read it on the NeXT where everything reversed itself. 49 <nl> 50 51 <nl> 52 It should be fixed here: 53 <nl> 54 This is 12 point. 55 <nl> 56 57 <bigger> 58 This is 14 point. 59 <nl> 60 61 <bigger> 62 This is 16 point. 63 <nl> 64 65 <nl> 66 67 </bigger></bigger> 68 This is back to 12 point. 69 <nl> 70 71 <nl> 72 I do have some followup questions. Can I close a "bigger" environment with a "smaller" 73 <nl> 74 and vice-versa? I was doing that but for safety's sake I now use, e.g. "/smaller" when 75 <nl> 76 growing and the current point size is less than 10, but "bigger" when growing and the 77 <nl> 78 current point size is 10 or greater. Is this necessary? 79 <nl> 80 81 <nl> 82 I also have a question about external-body messages. If I have a multipart message it 83 <nl> 84 would be nice to make the first external-body segment ftp, with parameters that would 85 <nl> 86 cause it to essentially mget all the files, so later segments could be local-file. To do that 87 <nl> 88 I really want the first ftp call to mget all the files, create a subdirectory on the user's host, 89 <nl> 90 and put the files into the subdirectory. One way to do that would be to make the NAME 91 <nl> 92 on the ftp access type the basename of the directory containing the message and make 93 <nl> 94 the MODE "directory" or "recursive" or some such. But it needs to be something well 95 <nl> 96 defined for all the MIME readers. Any thoughts on this? 97 <nl> 98 99 <nl> 100 Finally, I'm pursuing the problem where WIN/3b munched my Content-type line. 101 <nl> 102 I t's Wollongong rather tha attmail, but I haven't heard back yet from Wollongong. 103 <nl> 104 A "content-length" caption was added in as the content-type line was mangled, 105 <nl> 106 so I suspect WIN/3b sendmail has its own private interpretation of content-type. 107 <nl> 108 Until then I've shortened my boundary down to 5 lower case characters so this 109 <nl> 110 message shouldn't cause the trouble the last one did. 111 <nl> 112 113 <nl> 114 Thanks for your help, 115 <nl> 116 Marty 117 <nl> 118 robb@sblab.att.com 119 <nl> 120 121 </bigger><smaller><smaller><smaller> 122 123 --tmrob-- 124