[Pan-users] Re: Weirdness with multipart posts containing images

[Duncan]

"Keith Richie" <address@hidden>
posted address@hidden,
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