Nupedia Work Area/Image policy

I. Types of images

1. Large photographs, usually JPEG.
2. Self-made line drawings, usually PNG.

II. Necessity for thumbnails

1. Thumbnails are needed for large photos.
   1. LS Comment: Who makes the photos? When are they made? How do we check that they're OK?
   2. MM I am talking about, say, a hi-res PD pictures of a frog for a zoology article.
   3. LS Ah, I didn't say what I meant to say! Who makes the thumbnails? When are they made? How do we check that they're OK?
   4. MM Oh! I'd say the author should be encouraged to do this, but it won't be too hard on the markup crew, right? I mean, since the integration of the thumbs is done in markup, so should the thumbnails.
2. Thumbnails are needed if the total amount of images in the article significantly increases download time.
   1. LS Comment: That's the case when I try to download your article, Magnus; my Russian ISP says I am connected at 38K.
   2. MM I'd say we can expect most people to work at least with 56K modems, which would take less than a second to load the PCR image, for example.
   3. LS I disagree. I'm not sure we can expect this, anyway. What sort of statistics are available on this? And you know, of course, that even 56K modems don't always work at 56K.
   4. MM Agreed. But we certainly have to set a minimum? Or should we create articles based on their ability to be transfered by using morse code??
3. Thumbnails are needed if the image(s) would visually dominate the article otherwise.
   1. LS Comment: Magnus, that's also the case for your article, isn't it?
   2. MM The plasmids article, perhaps.
   3. LS OK, then we'll need suitable thumbs for that. But we also need to define "suitable thumb"!
   4. MM "Suitable" will differ from image to image. I'd say we start with a thumbnail 64 pixels width, and increase it by 64 until it doesn't look like dirt on the monitor anymore...
4. Thumbnails are NOT needed if the image(s) are integral part of the article and need to be viewed together with the text.
   1. LS Comment: This is contrary to the previous rules, isn't it? I mean, what if an image is absolutely huge, and requires a long download time, and also visually dominates the article, but is also integral to the text?
   2. MM Well, after reasons for having thumbnails, this one for having none. This will be an individual-case-scenario, anyway, unless we set a KByte limit for images or something.
   3. LS Whatever we do, we must set clearer rules.
   4. MM Also, I forgot an important point : IMHO, we should have different standards for brief, medium and long articles. Whoever wants to read the long version of an article, will probably take some more time to load images. Also, a long article with "full" images can load once, and then you can save it and go offline, if you pay per minute. With thumbnails, you'll have to read, click, save, click, save,...
5. If none of the rules applies, it should be the choice of the author, with a possible veto from the copyedit/markup crew.

III. Hi-res formats

1. All images should be available in a format that looks nice on a printout.
2. All photos should be available as hi-res JPEGs.
3. All line drawings should be available in a vector format.
   1. LS Comment: Moreover, there should be world peace and a girl for every boy. :-) But how do we do it? Lee? Your opinion? What is the procedure for the average image-laden Nupedia article?
   2. MM I am working on a PHP script right now. I can already create a thumbnailed and a normal version from the same source, together with a JavaScript/non-JavaScript option!
   3. LS Sounds good!
   4. MM I now have also a SVG version. Just at home, but it works!
4. a. The SVG format will become web standard, but currently has some bugs.
5. b. Postscript is virtually bug-free, but requires a plug-in on Windows machines.
   1. LS Comment: We conclude that SVG and PS are simply not going to be used in Nupedia articles, at this time--correct?
   2. MM Well, what do we do about the hi-res version, then? Leave it for later?
   3. LS I'm afraid I don't understand the question ("what do we do about the hi-res version").
   4. MM If the only options I see for hi-res images are SVG and PS, and you say we won't use either, then I conclude that we won't have hi-res versions now. Correct?

IV. Multiple article versions

1. Each article should, at some point, be available as a "screen" and a "printable" version. Eventually, there might be a "thumbnailed screen", "screen", "printable", and "PDF" (or "RTF" or...) version.
2. a. One way to do this is to manually create every version of the article at markup time. Works short-term only.
   1. LS Comment: almost certainly a bad idea, I think.
   2. MM Yes, which is why I vote for posting the articles "as they are" for now and change them once we agree on a solution ;)
   3. LS That's what I told myself while posting your first article!
3. b. The other way would be to create the desired version "on the fly" by a PHP script. This would allow for combination with other settins, like "popup notes"/"footline notes".
   1. LS This is not something I can worry about; I'll leave it up to interested programmers (and I'll hope there are some!
   2. MM As I said, I'm already pretty far with it! But I can't integrate it into the system on my own, so someone would have to do the merge for me.
   3. LS Molodyets! Ausgehzeichnet!

Another question: please read the present policy guidelines. How does it need to be altered so that our conclusions above are made official Nupedia policy?

1. I'll worry about that once my scripts work ;)