<br><br><div class="gmail_quote">On Wed, Apr 29, 2009 at 1:30 AM, Nicu Buculei <span dir="ltr"><<a href="mailto:nicu_gfx@nicubunu.ro">nicu_gfx@nicubunu.ro</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 04/28/2009 04:05 PM, Schrijver wrote:<br>
> Hi,<br>
><br>
> I have been eying the discussions about thumbnails; I also read it on<br>
> the roadmap:<br>
> ĎAdd graphical thumbnails to all clip artí<br>
><br>
> But I donít really understand how this works now, There is no script<br>
> that programatically produces thumbnails server-side? So the thumbnail<br>
> has to be added to the upload, i.e. as an extra PNG file?<br>
<br>
</div>Currently this is the ugly way we have to take. But I heard someone was<br>
working on it, have no idea what happened.</blockquote><div><br>I'm pushing for the SVG Thumbnail previews (without technical knowledge or time to learn :-( ...). However, browsers are behind. Out of necessity we currently upload the png first, then the svg. It doubles the work, and when svg thumbnails are finally implemented, it will make the work we currently do a waste of time. Well, maybe not a waste but seemingly pointless.<br>
<br>BUT, from that point on any uploading will be easier :-D† <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">

> What is the current method of implementing them than?<br>
><br>
> Question 2: †Are the thumbnail files the same as the preview images?<br>
> (the ones you see when you click to see the details of an image)<br>
<br>
</div>Yes.<br>
<div class="im"><br>
> Because I was going to suggest for those to be much bigger, like 512px<br>
> or something; but that would not go well together with being thumbnail</div></blockquote><div><br>At the moment, the current version, uses the same png file for the thumbnail as the preview, as the actual png, only scaled down (or up if it is smaller). It means that when someone uploads a large png, the computer who browses the clipart, still downloads the larger file, but scales the image to suit whatever view you are currently looking at.<br>
<br>This is important to note for a few reasons. It's especially noticable for me, as I am on dialup. Even though we are moving into the broadband age (the world is not there yet), I think we still need to be considerate of broadband usage, and user time (dialups). <br>
<br>Reason #1. One file = multiple views. This is a good thing. More explained below.<br>Reason #1b. Scalability. It's good.<br>Reason #2. Less broadband usage.<br>Reason #3. Less time for dialups.<br>Reason #4. Previews look good<br>
<br>And these are why I am pushing for (working) SVG thumbnails. SVG thumbnails reduces multiple handling (e.g. it removes the necessity for uploading a png, perhaps in multiple sizes), it can handle many different viewing sizes while still looking good, it lessens the broadband usage and time, both for viewing and downloading. (Remember that when you view a picture on the net, you are also downloading it at the same time.)<br>
<br>Current PNG thumbnails counter all these good things and make more work than necessary, plus more broadband usage.<br><br>I'm lazy. I want svg thumbnails. :-P :-D† ;-)<br><br>In the new OCAL version there was talk about making a small png thumbnail, a
250h px preview and the svg. I'm hoping that an svg-png converter
script will be completed soon , so that we don't end up making three
images. (Someone Else is writing the script.) It might be wishful thinking at this stage, but I would love to see svg thumbnails implemented in the new version, otherwise known as a "preview toggle" - one that allows the browsing logged-in-user to switch between svg OR the automatically generated png previews. † <br>
<br><a href="http://summerstyle.net/openclipart.org">http://summerstyle.net/openclipart.org</a><br><br>†<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
<br>
</div>People are lazy, providing large raster versions would discourage people<br>
to get the vector versions, thinking that what they get is "good enough".<br>
</blockquote></div><br>You are correct.<br><br>What we face is a combination of "re-educating" people on how and when to use vectors vs the standard way of doing things ("chains") placed on people because of the way graphical users have been trained...via photoshop/other programs PLUS bad coding habits that some web-developers have gotten into. Like you said - laziness. It does not only extend to the downloaders of OCAL but also the designers of "art" and uploaders - myself included.<br>
<br>The problem is time. Who has time to relearn designing, when you have a family to look after, projects to run, and a business or three to look after? When you've used photoshop/PSP/MSpaint/raster programs for years, and dont understand vectors? When the printers accept a limited range of files? Joe Public People are <u>still</u> using Frontpage or MSWorks or Publisher for their documents. They don't care about web standards, or portability, or scalability. They just know "it works". That in turn forces designers and other graphical users to use or find conversion programs and spend more time than necessary. <br>
<br>Anyone want to be a teacher? ;) I know I'll be teaching my kids and peers about Inkscape and vectors.<br><br clear="all"><br>-- <br>Cheers<br>Chovynz<br>