User talk:Chmod007/Alternate version proposal

Thanks for the Garamonds comments. Of course I did intend GFDL, but kind of mistook it. As for the source code of course i have it and thought about uploading it on SVG, but knew that wikipedia does not support it. I intend to as soon as the wikinews discussions on Wikimedia cool down start a debate over the adoption of some Wikitex features, from the Wikisohpia guys. Specially the SVG filter and the Music plugin. I plan to write a small usability review on those features soon, along with some proposals. I suppose you were aware of wikitex... --Alexandre Van de Sande 02:06, 29 Oct 2004 (UTC)

Some related discussions
Hi, I just thought you might like to look at some of these discussions, which may be relevant to your thoughts/proposal: - IMSoP 18:18, 31 Oct 2004 (UTC)
 * Tightening of upload restrictions: this was to fix a security issue, since some browsers allow all sorts of weird exploits with files that happen to look like other ones. Additional formats could certainly be added, especially if some validity checks could be put in place, but some formats (e.g plaintext source code) would be hard to protect from this exploit.
 * Additionally, I imagine some files (e.g. complex binary formats, like maybe Visio or PhotoShop) may well open another can of worms, in that they may have the potential to harbour trojans and viruses; I don't know how much we need worry about that, but it would be worth bearing in mind if we were to actively encourage the use of any such formats. (It would probably be a bad idea, for instance, to encourage Microsoft Word files, given the number of WordBasic/VBA trojans/viruses there have been over the years).
 * State of SVG support: this mailing-list thread discussed some of the problems current browsers have with rendering SVGs. Not that this means we shouldn't upload them as source-files, but it may be a while before we can reliably serve them in-line, other than by automatic rendering to PNG.
 * Multimedia: currently, this mainly discusses sound (it includes a proposed replacement for Sound), but is intended to also cover other multimedia content we may want to include. Free vs proprietary and lossy vs lossless are certainly key points when considering any multimedia policy.

why tiff?!
isn't a lossless compressed format like png (which is also supporeted by more browsers than tiff a better option? en:user:plugwash
 * Not necessarily. TIFF supports 48 bit images, is one thing. It is a much more versatile format in many respects. For images that don't need the richness of that format (and most don't to be fair) PNG would be an excellent choice. TIFF supports compression too, btw (LZW and JPEG, though the latter would not be wise to use if quality was the main objective). &mdash; David Remahl 03:07, 15 Nov 2004 (UTC)
 * For the record, PNG supports 48 bpp color too. Fredrik | talk 22:14, 15 Nov 2004 (UTC)
 * Oh, I wasn't aware of that, but sure enough it's in the spec. Nice. Supported by libpng etc? &mdash; David Remahl 22:42, 15 Nov 2004 (UTC)
 * I'd be surprised if libpng didn't. There probably aren't many apps that make use of the feature though. Fredrik | talk 23:02, 15 Nov 2004 (UTC)

original format OR reversable to original format without loss
imo this should be the goal for source material type images.

e.g. if you take a picture with a digicam that saves it as a jpeg then the original jpeg form the camera is what should be uploaded NOT a decompression from it

but if the camera original is a 24 bit tiff then it could be converted to png and still be able to be converted back to its original form without loss so it should be converted to the more widely supported option. Plugwash 21:07, 21 Nov 2004 (UTC)
 * Absolutely, that's the spirit of my proposal. The alternate version should be as close to the original as possible. If the original is edited, it may be necessary to upload several versions, or perhaps a rich format such as psd where the original graphics can still exist in hidden layers. &mdash; David Remahl 21:19, 21 Nov 2004 (UTC)