This week's book giveaway is in the Cloud/Virtualization forum. We're giving away four copies of Mastering Corda: Blockchain for Java Developers and have Jamiel Sheikh on-line! See this thread for details.
I am developing a webpage in which the user can make changes like highlighting an image, adding a comment and so on. What I want is when the user clicks on a submit button a PDF file of the web page with the changes is generated, so that I can send it to the user through email. Any help?
Most operating systems can print a page to a PDF directly - MacOS and Windows 10 natively, and Linux via a freely available Print-to-PDF driver. So it sounds a bit like you intend to reinvent the wheel.
So if you want to do that on the server side, you're going to need something which simulates that process. I have no doubt that you can find that thing on the web, and I recommend that you do look for it there. Trying to write it yourself would not be a simple process.
To be precise, in Linux, the "universal" print format is PostScript, and PDF is just PostScript in a metadata wrapper. So creating PDF's from Linux web browsers is trivially done via the standard Print dialog. It is the print driver's responsibility to convert PostScript to device-specific code such as HP PCL. The GhostScript program is what usually does this, in fact.
In Windows, it was more the reverse. Graphics output was in Window Metafile Format, which was really just a capture of raw Windows GDI commands, and the Windows print drivers would convert to raw device codes almost immediately instead of when the job was presented to a printer. Which was a pain, since you couldn't easily re-route such a job to a different brand of printer if you needed to. For a while there was, however, a booming market in third-party printer drivers that would "print to PDF".
By Windows 10, Microsoft had caught on, and printing to PDF is now built in, even though their approach is pretty weird.
I should note that unlike most devices, where a "driver" was the OS-to-hardware interface, in printing, the "printer driver" is more often a translator that sits between the original print request and the physical driver for the parallel (LPT) port, USB, or whatever.
So getting a PDF out can be as simple as displaying a printable web page.
The bigger problem is that web client programs are forbidden to run the printer directly without explicit user click-the-OK-button approval, much less saving as a PDF or emailing.
What you can do is save the user's indications in some format on the webapp server, merge that data into your prototype display, render it as PDF (using a Java PDF library) and then have the server do the emailing. So you're either talking about a fairly complex servlet or a servlet that sends a request to an offline processor using something like MQ, depending on how you like to partition things.
Some people, when well-known sources tell them that fire will burn them, don't put their hands in the fire.
Some people, being skeptical, will put their hands in the fire, get burned, and learn not to put their hands in the fire.
And some people, believing that they know better than well-known sources, will claim it's a lie, put their hands in the fire, and continue to scream it's a lie even as their hands burn down to charred stumps.
Forget this weirdo. You guys wanna see something really neat? I just have to take off my shoe .... (hint: it's a tiny ad)