"Keith Richie" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Mon, 10 Mar 2008 15:04:48 -0400:
> Now that you mention *parts*, it seems like that's exactly what it is. > > The images that are prompted to be downloaded are not split into > multipart segments, but lumped together. The larger posts that are > split, can be viewed just fine. > > Every image posted as a single segment over 5000 lines is prompted to be > downloaded. > > I thought there was some kind of standard that states each segment can > only have so many lines? Well, I don't believe it's a standard, or if so it seems to be observed more in the breach than not, but there are some practical limitations, altho they don't depend on absolute line count unless the news admin in question is rather incompetent. The practical limitation is that many bundled and low-end services aren't all that reliable with larger posts. Small posts (by bytecount, not lines) get thru just fine, while larger ones are delayed or never show at all. Keep the part sizes small enough (the pattern with too big ones is that the smaller last part will often show up, while the others don't), and it avoids the problem as all parts show up together. Many folks therefore try to limit their posting size to fit under whatever the threshold is for their target audience. The line count problem has to do with encoding. MIME/Base64 and UUE encoding traditionally kept line lengths to 80 characters (minus the terminating CRLF sequence, so 78 chars) for compatibility reasons, even tho the standards required the ability to deal with 1000 char line length (again, minus the terminating CRLF, so 998). One of the things yEnc does to eek out that last bit of encoding size efficiency is use line lengths at or near the maximum 1000 chars -- that's two bytes less encoding overhead for each line thereby avoided. Thus, yEnc encoded lines are normally more than 12 times the previous customary length, making any general measure of size by line count pretty much worthless, since it can easily be a factor of 12 off one way or the other, depending on which encoding style is assumed. So for binary posts and an individual poster or group of posters using similar software, line count may be a meaningful indication of part size, but it simply isn't reliable to use it in general. (Of course, line count does have somewhat more meaning for text posts...) BTW, pan lets you choose the display columns, lines, bytes, neither or both. If your display width makes it inconvenient to display both, lines for text and bytes for binaries makes the most sense. Of course, that's where the ability to run multiple pan instances, each with its own settings and storage dir as set by the PAN_HOME environmental variable, comes in handy. As I've mentioned before, I run three separate instances here, text, binary, and test (for groups I'm just trying out before I subscribe). -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/pan-users
