For several reasons, a lot of "webmaster guides" (like Google and Yahoo!'s webmaster guides/guidelines) repeats several times that it is better to always put the width and height attribute of the img tag.
One of the most obvious reason is that the elements in the page won't seem to be "jumping around" to a new location after every picture is loaded (always setting the correct width/height sure gets rid of this behavior). And there are other reasons to follow these guidelines / best practices.
So:
if we consider that these are indeed good practices
if there are a lot of pictures and they are changing often
if pictures aren't changing between two .war re-deploy (that is: there's no user-contributed picture)
if we don't want to manually edit all these width/height attributes
How do we automatically/programmatically serve HTML pages where every img tag have their width/height attribute correctly set as the best practice recommend?
We have a more complicated build process, where all the .jsp, .css, .html, etc. are optimized.
.css files with lots of includes are collapsed in a single file (another major one if you're into website optimization, just use Chrome's developer tools or YSlow! and check the difference with and without .css collapsing)
.jsp and .html files have all their image width/height set at build time
images are given unique names and are set as foreover cacheable (not unlike what GWT is doing for the JavaScript it generates, where unique identifiers are used). On the next build, they'll get new unique names and will be once again forever cacheable.
etc.
There a lot of reason to have a build process more advanced than just "compile and zip all your files".
To answer your question: we do a lot of Unx shell scripting in our build process. We process the .jsp, .css, .html etc. using some Unx shell power. And I can tell you that people would have a very hard time replicating what we're doing without having the possibility to combine the power of all those shiny shell commands :)
When the webapp starts up, we're recursively crawling the entire exploded .war looking for every single picture file and determining their width/height.
We're saving these infos as a mapping in "file-to-width/height" map. Later on, every single time we're generating an img tag we're calling a method that gives up back that picture's width/height.
The only "drawback" is that the map lookup and width/height attributes generation are performed at runtime.
Related
We have a web application which produces 2-3 images after an algorithm is run. We want to return these images to the user. I thought the best design would be to store the images outside the project code base: in an external folder like the /tmp directory.
First off, do you agree with this design decision? I feel like the project code base would get bloated every time we run the algorithm. My boss wanted me to store the images inside our webapp, but I made a good case for storing them in the /tmp directory.
Secondly, is it possible to return multiple images (most likely 2 or 3) in a single JAX-RS resource method? I've never seen this done, so I'm inclined to think I should write a generic resource method for returning an image given the filename.
I would really appreciate feedback on both questions. Thanks in advance :)
We have a web application which produces 2-3 images after an algorithm
is run. We want to return these images to the user. I thought the best
design would be to store the images outside the project code base: in
an external folder like the /tmp directory.
First off, do you agree with this design decision? I feel like the
project code base would get bloated every time we run the algorithm.
My boss wanted me to store the images inside our webapp, but I made a
good case for storing them in the /tmp directory.
The design decision question is pretty opinion-based, I think. I'll give you my thoughts, but I can't say that this part is an "answer", it's just an opinion.
As I mentioned in a comment, from my perspective, web pages have a pretty standard way of serving images (even if the client is now fancy AJAX requests). There is a single URL for a single image. I wouldn't try to deviate from that.
Where you decide to host them is up to you. I'd probably use a web server such as nginx (as opposed to an application server), which is optimized for serving static content like images, js files, etc.
I feel like the project code base would get bloated every time we run the algorithm.
This part confuses me. You are producing image files. This is just data. It isn't code and it doesn't really inflate the code base. If you mean consuming disk space where you store your code, sure, host it somewhere else.
Secondly, is it possible to return multiple images (most likely 2 or
3) in a single JAX-RS resource method? I've never seen this done, so
I'm inclined to think I should write a generic resource method for
returning an image given the filename.
It's possible in a sense of the word. You could encode the images as text that would be used for embedded images. For example (stolen from a page explaining embedding images in html):
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAM0AAAD
NCAMAAAAsYgRbAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5c
cllPAAAABJQTFRF3NSmzMewPxIG//ncJEJsldTou1jHgAAAARBJREFUeNrs2EEK
gCAQBVDLuv+V20dENbMY831wKz4Y/VHb/5RGQ0NDQ0NDQ0NDQ0NDQ0NDQ
0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0PzMWtyaGhoaGhoaGhoaGhoaGhoxtb0QGho
aGhoaGhoaGhoaGhoaMbRLEvv50VTQ9OTQ5OpyZ01GpM2g0bfmDQaL7S+ofFC6x
v3ZpxJiywakzbvd9r3RWPS9I2+MWk0+kbf0Hih9Y17U0nTHibrDDQ0NDQ0NDQ0
NDQ0NDQ0NTXbRSL/AK72o6GhoaGhoRlL8951vwsNDQ0NDQ1NDc0WyHtDTEhD
Q0NDQ0NTS5MdGhoaGhoaGhoaGhoaGhoaGhoaGhoaGposzSHAAErMwwQ2HwRQ
AAAAAElFTkSuQmCC" alt="beastie.png">
You could return that data in the JSON response object as text. I wouldn't do that, but it is an option.
I'd just return a response object that has the URLs of where to get the actual images. That makes for a cleaner API.
The application I'm trying to build will have a lot of images displayed (in ImageViews), and I'm not fetching them from a server/online service as it will need to be used offline. I know I can just dump them in the res/drawable directories, but I was wondering if there's any way to optimize this. Is there a way to somehow compress these images (besides making them smaller, they're already as small as I need) or use some other sort of android tool to better store them locally on the device?
I could just be overlooking a well used feature, and if so, it'd be great if someone could point me to that.
Edit: If I were to compress the images somehow, I would need to decompress at runtime or something, and that would take another thread/loading time. I'm not sure how to do that either, so I'm just brainstorming various ways, and I thought someone here would've come across this at some point.
If you haven't already, this is a good read - http://developer.android.com/guide/practices/ui_guidelines/icon_design.html#design-tips
When saving image assets, remove unnecessary metadata
Although the Android SDK tools will automatically compress PNGs when
packaging application resources into the application binary, a good
practice is to remove unnecessary headers and metadata from your PNG
assets. Tools such as OptiPNG or Pngcrush can ensure that this
metadata is removed and that your image asset file sizes are
optimized.
Outside of all other compression logic the above would be the place to start. Also when you say "optimize" - do you mean optimize the way images/drawables are loaded in your app or just the amount of space (on disk) the app will consume?
I am using a java applet in my web project and some images are shown in this java applet.
I want to limit users to pull images from the web page. What are possible techniques for a client user to save images used in a java applet which is used in a browser session, except "print screen"?
Any ideas are welcome.
Thanks.
..What are possible techniques for a client user to save images used in a java applet
I don't know about typical end-users, but I'd do these things to circumvent several security strategies:
1. Hide them in the archives
Look at the source of the page
Discover the location of the Jars
Download each one by direct fetch
Rename them to .zip and expand them (quick & dirty), then..
Sell your images for causing me that much inconvenience to get them in the form I want.
That last part was sarcasm (mostly), but just wanted to make the point that if you put something in a Jar, people can get it out.
2. Hide them on the server
Use a packet sniffer to discover the image locations by URL.
Pull each image directly (etc.)
3. Encrypt the images
You might use techniques to encrypt the images, then obfuscate the code that decrypts them, but that would also fail against a determined hacker.
4. Screen grab
As mentioned already. 'Last resort' - crude, but effective.
..Any ideas are welcome.
Don't pursue such strategies. You won't achieve any form of security worth having, it will just irritate the user.
If the image is a bitmap inside of a jframe it'll be hard to capture it without resorting to a screen grab. Just like using it in flash the image file itself won't actually exist anywhere on the client.
I am creating an application that requires a lot of image thumbnails (~3000, 5-25KB). Because speed is essential I plan on loading these images into memory when the application starts. At runtime, new thumbnails will be downloaded and added to the collective.
I could store them all in a folder, but reading thousands of files into memory when a program starts hardly seems efficient.
My second option would be to save them in some kind of (compressed) archive. This would make storage itself and loading more efficient (I think). However, new files will be added regularly, and that will probably not go as smoothly as just saving them in a folder.
Is storing a cache of small files in a (compressed) archive a bad idea or not? Are ZIP files the way to go? Would I be better off using uncompressed archives (and if so, what kind)?
All image files will be JPEG's.
Thanks in advance!
EDIT: I am considering to drop the "load everything into memory on application start" thing. This would simplify my question a little. My initial idea to put everything in one big file now seems less beneficial, since the problem of many files in one directory can be solved by hashing into subdirectories.
Small files don't compress especially well, so you may not gain much compression.
While loading the files will be fast because they are smaller, decompression adds time. You'd have to experiment to see which is faster.
I would think the real issues would relate to the efficiency of the file system when it comes to iterating over all the little files, especially if they are all in one folder. Windows is notorious for being pretty inefficient when folders contain lots of files.
I would consider doing something like writing them out into one file, uncompressed, that could be streamed into memory -- maybe not necessarily contiguous memory, as that might be a problem. But the idea would be to put them all in one file. Then write some kind of index that ties a file name or other identifier to an offset from which the location of the image in memory could be determined.
New images could be added at the end, and the index updated appropriately.
It isn't fancy but that's what you're trying to avoid. An archive or even a file system gives you lots of power and flexibility but at the cost of efficiency. When you know what you want to do, sometimes simple is better.
I would consider implementing a solution that reads files from a folder, another that divides the files into subfolders and subsubfolders so there are no more than 100 or so files in any given folder, then time those solutions so you have something to compare to. I would think a simple indexed file would be fast enough that you wouldn't even need to pre-load the images like you're suggesting -- just retrieve them as you need them and keep them around once they're in memory.
All disk based storage, and most database, allocate space in chunks. The chunks on large capacity disks can be large. If you have 5kb files and a 32kb disk chunk you end up with 85% wasted space on your storage.
Using an archive won't compress jpeg much because the jpeg encoding algorithm already does that. It will however save you the wasted space on the storage media. It does make things more complicated and perhaps a little slower.
In my opinion I think that the zip file way it´s a bad idea, because you will slowdown everything with the process to load the zip file and unzip it to extract each image.
I think that the purpose of a thumbnail image is that by nature is small so your app plus hardware can load it as fast as possible. So I believe that it is a better idea to load each image as you need it.
Well, if you have small, "geometric" pictures, you may implement them as objects of type javax.swing.Icon rather than images to load from the filesystem.
http://download.oracle.com/javase/6/docs/api/javax/swing/Icon.html
http://download.oracle.com/javase/tutorial/uiswing/components/icon.html
So you will implement one or more objects which draw themselves onto a Graphics surface using the Graphics drawing primitives, instead of copying pixels.
If this is a web-application then the best performance boost you can get is setting good HTTP caching headers. Having a unique URL for every image (also different URLs for different versions of the same image) makes it possible to set VERY far future expire headers, because changing the image changes the URL leading into refetch.
I won't compress, because JPEG cannot be good compressed and it only costs CPU time.
I would recommend to simply store the images into filesystem and consider the use of libraries like jawr or implement your own caching strategy.
I know this question has already answered but I think you need more options other than zipping.
While zip is good, It's not really affect much for JPEG since JPEG has already compressed.
Other thing you may want to consider is :
Put the image in Content Delivery Network (CDN)
Compress components with gzip ( mean the server will automatically zip every response ) and you dont need to write any code to unzip it later - it's handled by the browser automatically.
Since you mention JPEG, you may want to use JPEGTran.Run jpegtran on all your JPEGs.
This tool does lossless JPEG operations such as rotation and can also be used to optimize and remove comments and other useless information (such as EXIF information) from your images.
jpegtran -copy none -optimize -perfect src.jpg dest.jpg
Use Image Sprites. Instead of asking browser to download many image at same time, ask the browser to only download one.
For the details read : http://developer.yahoo.com/performance/rules.html#opt_images
For the basic examination how to improve your website performance you can try install YSlow ( plugin to detect uneffecient code ) in Firefox.
Hope that helps.
I'm in charge of updating an existing java app for an embedded device (a copier).
One of the things I want to do is create a servlet which allows the download of all the files in our sandboxed directory on the device (which will include the application log files, local caches, etc). At the moment these files are all in a single directory with no subdirectories.
Basically what I'd like to do is as follows:
Log.log
Log.log.1
Log.log.2
SomeLocalCache.txt
AnotherLocalCache.txt
where each line is a clickable link allowing download of the file.
However, my HTML experience is basically nil, and my familiarity with the Java API is still fairly rudimentary, so I'm looking for some advice on the proper way to go about it.
I've read through all the samples provided, and here's what I'm thinking.
I can create a servlet at a specified URL on the device which will call into my code. Let's call this /MyApp.
I add another link below that, let's call it /MyApp/Download.
When this address it reached in a browser, it displays the list of files.
This list will have to be created on the fly. I can create an HTML template file and put it in the res folder (this seems to be the recommended method for the device in question), but the whole list of files/links will need to be substituted in at run time. Here's an example I found using <ol>+<li> tags for the list and <a> tags for the links. I can generate that on the fly pretty easily. Is that a reasonable way to go?
e.g.
<ol>
<li>
Log.log
</li>
<!--more <li> elements-->
</ol>
Clicking on an individual file will link to /MyApp/Download/File.ext which will then trigger the file download via my servlet (I've found this code which looks promising for the actual download).
The device will require users to log before they are allowed to access the /MyApp link or any sub-links, and I can additionally require that the logged in user be an admin before allowing file download, which together seems like sufficient security in this case (heavy security is not required for these files).
So am I missing anything big or is this a reasonable plan of engagement?
EDIT
Judging by this link when to use UL or OL in html? Many people are going to hammer the answer and comment below because they say it is important to put semantic information into the HTML.
My point is simply this -- the only difference is browsers will display one with bullet points (as OP seems to want) and one with numbers (as the OP does not want.) I suggest he change the HTML to the way he wants it to render, or leave it as is, and make some CSS changes.
Yes there is a semantic difference between the two... they will both still render in order as defined here http://www.w3.org/TR/html401/struct/lists.html Is the HTML the place to put semantic information? I think not, code that generated the HTML is the correct place. Your cohesion may vary.
I won't change my original comment for the sake of history.
END EDIT
Seems fine to me -- however <ol> is not really used any more, I'd go with <ul>. Don't worry, it is still ordered as you would expect.
The reason for this is the only difference between the two was browsers would automatically number (render with a number before) ordered lists. However, with CSS all the rendering control can be in the CSS (including numbering) and everyone is happy.
Hardly anyone uses the auto number anymore. In fact via CSS, lists can and are used for all sorts of crazy things, including CSS menuing systems.
Here's a summary you need to do:
You can use File#listFiles() to get a File[].
You can use JSTL c:forEach to iterate over an array.
You can use HTML <ol>, <ul> or <dl> elements to display a list.
You can use HTML <a> element to display a link.
You can use a Servlet to write an InputStream of a local file to OutputStream of the response. Remember to pass at least Content-Type, Content-Length and Content-Disposition along.
You can make use of request pathinfo to pass file identifier safely. E.g. map servlet on /files/* and let link point to http://example.com/files/path/to/file.ext and in the servlet you can get /path/to/file.ext by request.getPathInfo().
A basic and solid servlet example can be found here: FileServlet. If you want to add resume and compressing capabilities, then you may find the improved FileServlet more useful.
That said, most appservers also just supports directory listing by default. Tomcat for example supports it by default. You can just define another <Context> in Tomcat's server.xml with a docBase of C:/path/to/all/files and a context path of /files (so that it's accessible by http://example.com/files.
<Context docBase="/path/to/all/files" path="/files" />
That's basically all. No homegrown code/html/servlet needed.