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.