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.
   5. LC Making thumbnails is a simple enough job that most authors should be able to manage, but it's also reasonable for them to request that an image editor or markup tech do it. We don't want to force authors to have lots of skills they don't really need.
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??
   5. LC The best estimate you can have for setting policy is likely to be no better than a rough order of magnitude, so I think targeting 56k is reasonable.
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...
   5. LC I agree with Magnus--"suitable" is only definable in the context of the article and the image itself. We can't offer fixed rules; we can only say things like "usable" and "reasonably sized" and have the author/editors decide the details for each case.
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. LC I would reword this to say "...if the image(s) are of reasonable size and are an integral..."
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.
   1. LC This is kind of ambiguous. This is a case where I think we need specific numbers--say, "in a format that can be reproduced legibly at 300dpi and that looks good at 600dpi."
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?
   5. LC SVG and EPS won't be served with Nupedia articles, but that doesn't mean they can't be stored as archived source code. Every serious drawing program exports EPS; requiring it is no hardship. If the author knows how to produce the PNG for the server, that's fine. If he doesn't, he can get help from us techies.

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!
   4. LC The information is the thing--how we present it is important, but can be changed at any time, as long as we have good source information.

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 ;)