Java Forum / General / October 2006
browser screen capture with java applet
mikeyjudkins@yahoo.com - 29 Sep 2006 19:33 GMT I have an idea involving Java that Im trying to determine the feasabilty of. I would like to know if it would be possible within a java applet embedded within a webpage to take a screenshot of the webpage from which it is sitting in (or another frame possibly), create a jpeg image of this and then upload it using a form post request, or prompt the user to save it to disk. Is this possible and how long do you think it would take for an intermediate java developer to complete?
Andrew Thompson - 29 Sep 2006 23:28 GMT > I have an idea involving Java that Im trying to determine the > feasabilty of. I would like to know if it would be possible within a > java applet embedded within a webpage to take a screenshot of the > webpage from which it is sitting in (or another frame possibly), create > a jpeg image of this and then upload it using a form post request, or > prompt the user to save it to disk. All this is possible. What is the purpose of it?
>...Is this possible and how long do > you think it would take for an intermediate java developer to complete? I don't know. I've encountered and dealt with parts of this, applets, signed applets, and creating screenshots using the robot, but not posting the completed image back to the server.
Even then, the problem is only half done, as you need to successfully deploy the applet in the user's browser, in a trusted environment.
Being tied to signed applets, it is not a project I would recommend for anyone less than a developer that is 'well versed' in applets (most 'intermediate developers' that had not had much to do with applets would have a hard time getting it to work).
Andrew T.
mikeyjudkins@yahoo.com - 30 Sep 2006 02:09 GMT Thanks for confirming. Id be happy to discuss the idea with you if you're interested (send me an email). Just wanted to know for now if it would be possible. Im not so concerned about the requirement that the user must manually "approve" the applet, if thats what is meant by signed applets, since the deployment would be aimed at a small(ish) audience.
Mike
> > I have an idea involving Java that Im trying to determine the > > feasabilty of. I would like to know if it would be possible within a [quoted text clipped - 24 lines] > > Andrew T. Andrew Thompson - 30 Sep 2006 02:38 GMT > Thanks for confirming. ... Thanks for refraining from top-posting in future.
>...Id be happy to discuss the idea with you if > you're interested I am mildly interested, especially in anything to do with applets. Feel free to make more posts ..
>...(send me an email). No. Or rather - only at consultancy rates, usenet OTOH, is free.
Further comments below...
> > > ...I would like to know if it would be possible within a > > > java applet embedded within a webpage to take a screenshot of the [quoted text clipped - 3 lines] > > > > All this is possible. What is the purpose of it? Still wondering..
This may be important for a number of reasons, including determining the answer to 'is an applet the best way to go about achieving the desired result?'
> > >...Is this possible and how long do > > > you think it would take for an intermediate java developer to complete? > > > > I don't know. ...
> > Even then, the problem is only half done, as you need to > > successfully deploy the applet in the user's browser, in a > > trusted environment.
>...Just wanted to know for now if it > would be possible. Im not so concerned about the requirement that the > user must manually "approve" the applet, if thats what is meant by > signed applets, Yes.
>...since the deployment would be aimed at a small(ish) > audience. That vastly simplifies the task, that you have a small audience, and they are willing to give their active approval to this app.
Can you also specify minimum Java version? What about the browser make/version? (I'm guessing yes to the former, no to the latter, but will only know when you answer the question above..)
Andrew T.
mikeyjudkins@yahoo.com - 30 Sep 2006 06:36 GMT > > > All this is possible. What is the purpose of it? I am exploring the idea of developing a web-based service aimed at web designers/developers which allows you to view your page design within multiple browsers and platforms to ease cross platform design headaches. The closest thing to this right now is a site called browsershots.org. There are also a number of more intricate pay services aimed at enterprise level use. But there are some issues with these and also areas in which I think my model would be differentiated and in many cases better than the above services. Anyway the purpose of the applet would be to do the job of the actual image capturing on each "target" browser and then to send this image back to the server for the requestor to see.
> Can you also specify minimum Java version? Each target browser would be run by a host (in a distributed network) who would have received in advance precise instructions for running the applet which does the screen capture. I think that would address the minimum Java version.
> What about the browser make/version? > (I'm guessing yes to the former, no to the latter, > but will only know when you answer the question > above..) It would require that the applet support a wide range of browsers and platforms (Mac, Windows, Linux, with the full range of modern browsers) as this is pivital to the concept of the service.
My background is with front end design/PHP/Perl, but not so much the Java side. So, pending some more investigation, I may be looking for an applet developer to assist. I was considering checking elance, but, if any of this sounds interesting, Im open to collaboration. Im sure someone out there already has 90% of the work done already.
Mike
Andrew Thompson - 30 Sep 2006 08:45 GMT > > > > All this is possible. What is the purpose of it? > [quoted text clipped - 9 lines] > "target" browser and then to send this image back to the server for the > requestor to see. All that could be done from within a webstarted application*, and it will be easier to deploy, and lower maintenance.
* Except perhaps for determining the shape/size of current browser window - if that's relevant. A Java applet could ask via JS for the size of the content area of a browser window.
> > Can you also specify minimum Java version? > > Each target browser would be run by a host (in a distributed network) > who would have received in advance precise instructions for running the > applet which does the screen capture. I think that would address the > minimum Java version. Once Java hit version 1.3 - the WebStart files allow you to specify a minimum Java version to run the app., Java WebStart takes care of prompting the user to download/install it - then runs the app.
> > What about the browser make/version? > > (I'm guessing yes to the former, no to the latter, [quoted text clipped - 4 lines] > platforms (Mac, Windows, Linux, with the full range of modern browsers) > as this is pivital to the concept of the service. This is where you are going to run into problems with the applet. Is it expected to be up and running in a separate browser window to the target window?
You mentioned frames, so the other possibility is to embed the applet in a hidden frame and the content page in a different frame. But frames and cross-domain(?) web pages are a nightmare in themselves, let alone throwing applets into the mix.
Will a screenshot of 'the entire screen' serve the purpose of your end users (this decreases the complexity of determining what to get a screencapture of), or did you want to trim it to just the rendered area? If trimmed, would user interaction be considered reasonable (e.g. "drag a 'crop box' around the image of your page")?
> My background is with front end design/PHP/Perl, but not so much the > Java side. So, pending some more investigation, I may be looking for an > applet developer to assist. I was considering checking elance, but, if > any of this sounds interesting, Im open to collaboration. Im sure > someone out there already has 90% of the work done already. I doubt there is any money to be had from this, in itself (In case that is where you wanted to take it). It would seem there are already too many free services about that offer something similar or other services that are 'good enough for the purpose'.
As another trend, developers of HTML are tending (slowly) to move toward more valid (semantically marked-up) HTML with simple styles that are kept in CSS files stored externally (so they can be hidden form old browsers) and also validated. As that progresses, the motivation to 'check it in a dozen browsers' becomes ever less.
Andrew T.
Simon Brooke - 30 Sep 2006 10:19 GMT >> > > > All this is possible. What is the purpose of it? >> [quoted text clipped - 47 lines] > frame. But frames and cross-domain(?) web pages are a > nightmare in themselves, let alone throwing applets into the mix. You could do a single-pixel applet without greatly affecting the layout of the page. I think that would be the easiest approach.
 Signature simon@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/ Copyright (c) Simon Brooke; All rights reserved. Permission is granted to transfer this message via UUCP or NNTP and to store it for the purpose of archiving or further transfer. Permission is explicitly denied to use this message as part of a 'Web Forum', or to transfer it by HTTP.
Andrew Thompson - 30 Sep 2006 12:17 GMT > >> > > > All this is possible. What is the purpose of it? > >> > >> I am exploring the idea of developing a web-based service aimed at web > >> designers/developers which allows you to view your page design within > >> multiple browsers and platforms to ease cross platform design > >> headaches. ..
> > All that could be done from within a webstarted application*, > > and it will be easier to deploy, and lower maintenance.
> You could do a single-pixel applet without greatly affecting the layout of > the page. I think that would be the easiest approach. For the developer, maybe, but not for the people wanting to test a web-page!
Using this approach*, the applet element needs to be inserted into each page that requires rendering.
You also need to ensure the user is not running an anti-spam or other browser plug-in that removes 'tiny or invisible' page elements, for that to work as expected.
And ensure that each browser (for which a page render is required) is correctly configured to run trusted applets.
* But then, if the image needs to be 'pixel perfect', one can only assume that a 1x1 pixel applet will throw out the page layout by ..at least 1 pixel. .....
> > ...you are going to run into problems with the applet. > > Is it expected to be up and running in a separate browser > > window to the target window? Note that the <applet> element does not need to be written into the web page(s) of interest, using this approach. The trick is to ensure the web page is on-screen and on-top.
> > You mentioned frames, so the other possibility is to embed > > the applet in a hidden frame and the content page in a different > > frame. .... ..and this is a second applet based strategy that gets around the problems of the 'in the page' approach, but also introduces others..
Andrew T.
mikeyjudkins@yahoo.com - 01 Oct 2006 03:20 GMT > > > All that could be done from within a webstarted application*, > > > and it will be easier to deploy, and lower maintenance. Just read about webstart and that sounds like the right way to go.
> > You could do a single-pixel applet without greatly affecting the layout of > > the page. I think that would be the easiest approach. Im envisioning the applet would be run within a separate frame or window (Im starting to favor the window approach since then its less complex (for example, sites which disallow frame sourcing via javascript, plus the issues of rendering the browser interface around the actual page design). This "piggyback" window would not only run the applet but also have information about requests coming in (updated with AJAX) from those wanting to view pages on the "host" machine.
About the potential for this to make money, Im not sure at this point either, its just an idea I had (among others) that Im evaluating. Browsershots.org seems to be having fairly good demand at this point (new requests coming in by the minute, and they just celebrated their one millionth screenshot since earlier last year). This is surprising in itself considering you have to wait "up to 30 minutes" to get all your screenshots back. I also dont think it would necessarily need to be a pay site to make money (there are other ways I can think of).
Andrew Thompson - 01 Oct 2006 07:53 GMT > > > > All that could be done from within a webstarted application*, > > > > and it will be easier to deploy, and lower maintenance. [quoted text clipped - 11 lines] > applet but also have information about requests coming in (updated with > AJAX) Aahh.. someone might correct me if I'm wrong, but a need to use JS rules out WebStart, no access to JS (at least, not before Java 1.6 and ..Rhino) .
Have you seen a webstarted applet? E.G. <http://www.physci.org/pc/jtest-applet.jnlp>
I am sure an application (or webstarted applet) might have access to the same basic functionalities, but there would be different (and I imagine more efficient and robust) API's for it.
>....from those wanting to view pages on the "host" machine. I must admit I am still not entirely clear - where are these browsers?
If the client or end user can - go to an HTML form - enter the URL of a page, - post the form off to a server that .. - contacts further machines (not the client's) for the actual process of the screenshots*, - then deliver the screenshots back to the client in a web page. ..where is the need for the client to either have Java, or assign any trust?
In this scenario, the browsers are on machines directly 'owned and controlled' by the provider of the service, so it stands to reason that they can be 'configured as required' (no tricky anti-spam plug-ins etc.), also, the providor can do whatever is needed (launch each browser using JNI..?) to interact with the target browsers in a programmatic way.
* To be useful, we want the rendering in as many browsers (make and version) on many OS's (make and version) as practical.
> About the potential for this to make money, Im not sure at this point > either, its just an idea I had (among others) that Im evaluating. [quoted text clipped - 3 lines] > in itself considering you have to wait "up to 30 minutes" to get all > your screenshots back. That paragraph indicates to me that you know more about it than I do. I was largely extrapolating from personal experiences of 12 months ago or more (an eternity, in 'computer years').
>...I also dont think it would necessarily need to > be a pay site to make money (there are other ways I can think of). That's a good point - get a major sponsor, and the site is set.
Andrew T.
mikeyjudkins@yahoo.com - 02 Oct 2006 06:30 GMT > Have you seen a webstarted applet? > E.G. <http://www.physci.org/pc/jtest-applet.jnlp> Checked it out. Im on a fairly old G3 Mac that I just dug out of my closet, so it told me I had to manually install an up-to-date JRE (after attempting to do so automatically). But I got the idea.
> >....from those wanting to view pages on the "host" machine. > > I must admit I am still not entirely clear - where are these browsers? Heres where my model differs a little bit from ordinary services of the same nature. First you have what Ill call the end user, which is the person who is requesting the screen shots. They wont need to run this applet and it will just be a form with the URL of the page they want to get screenshots from in various systems, very simple for them. Then you have a second type of user, I will call them the "listeners" since their job is to just run this screenshot applet in the background of their system and listen for requests which are rleayed from the server by way of end users. These would be ordinary users just like me and you. What they do is hit a URL at the service site, which I will call the "listening" URL, and the service registers what their browser and system is based on the http request header. Thats what tells the service how to route an incoming end user request to them. I would also capture some sort of on unload event with the applet (Im speaking in JS terms here, there's probably onother term for the event which is fired when the user closes the applet window) which would then unregister this person as a "listener". In this model, there is no central server which is running all the platforms and systems. just a big network of listeners.
You might wonder what motivation would these people have for listening. Well if I got it to make any money there could be some sort of revenue sharing, with a revenue counter possibly within the applet or the html window running the applet. 01 cents, 02 cents, 03 cents, maybe more if you run a non-common system, since those listeners would be in demand. All you'de have to do is sit back and run this applet in the background or on your unattended computer and you have a little supplemental income :)
Andrew Thompson - 02 Oct 2006 08:50 GMT > > Have you seen a webstarted applet? > > E.G. <http://www.physci.org/pc/jtest-applet.jnlp> > > Checked it out. Im on a fairly old G3 Mac that I just dug out of my > closet, so it told me I had to manually install an up-to-date JRE > (after attempting to do so automatically). But I got the idea. That's odd. The JNLP file marks the application as '1.2+', as far as I understood, any Java that understands a JNLP file (1.3+) should be OK to run it.
The irony is that it is really a Java 1.1 compatible application, try the direct link - it might load and run for you. <http://www.physci.org/pc/JTest.jar>
I glanced at the rest - it sure fills a lot of gaps in my understanding, I'll read it more carefully later.
Andrew T.
Simon Brooke - 30 Sep 2006 10:14 GMT >> I have an idea involving Java that Im trying to determine the >> feasabilty of. I would like to know if it would be possible within a [quoted text clipped - 12 lines] > the robot, but not posting the completed image back to > the server. Posting the completed image back to the server is not at all hard; you need to create an HTTP post request with a content-type of multipart/form-data; see RFC1867. Compared to all the problems with signed applets I'd see this as the easy bit.
 Signature simon@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
;; All in all you're just another nick in the ball -- Think Droid
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|