Why are you going through the step of printing the PDF file to a PostScript file? Ghostscript is already capable of accepting a PDF file as input.
Its not possible to say what the problem 'might' be without seeing the original PDF file and the PostScript file produced by your driver. My guess would be that whatever application is processing the PDF hasn't embedded the font, or that the PostScript driver hasn't been able to convert the font into something suitable for PostScript, resulting in the font being missing in the output, and the pdfwrite device having to substitute 'something else' for the missing font.
Ghostscript (more accurately the pdfwrite device) is perfectly capable of producing a decent PDF file when the input is PDF, but your input isn't PDF, its PostScript!
To be perfectly honest, if your original PDF file isn't 'searchable' its very unlikely that the PDF file produced by pdfwrite will be either, no matter whether you use the original PDF or mangle it into PostScript instead.
The usual reasons why a PDF file are not 'searchable' are because there is no ToUnicode information and the font is encoded with a custom encoding and deos not use standard glyph names. If this is the case there is nothing you can do with the PDF file except OCR it.
The reason is because I have this printer that accepts the files from the users and it doesnt know if they're printing a word or pdf file and always converts it into postscript(because of PS driver). I don't have to use PS but it seems like this is the best when I want to create a pdf later. The original pdf is searchable, but I just saw now that they have fonts that say "embedded subset" when i use acrobatreader, could that pose a problem?
Possibly yes. I would guess that the original file has ToUnicode CMaps, which convert the text into Unicode. There is no equivalent in PostScript, because PostScript is intended for printing so knowing the Unicode equivalent is not helpful. As a result this information is discarded when you print to PostScript. If the fonts use a non-standard Encoding (very likely with subset fonts) then fundamentally you've lost the searchability right there. Try converting the PDF file directly as a test, I expect it will work. This is a flaw in your workflow I'm afraid.
Is there any other way to grab a file from a printer and convert it into a pdf then? (regardless of what the input is (word or pdf)). Are there printer drivers that doesn't do anything to the file? then I could probably see if the file is a pdf and don't do a conversion and just send it straight through.
Bascially, no. When an application displays its content on screen, it does it by making drawing calls to the Operating System (Windows, Mac, Linux, etc). What you see on-screen isn't what's in the file, its what the application draws. When you print, the OS translates those drawing commands into the language of the printer (PostScript, PDF, PCL etc). That's what the printer driver is for. You need to look at the file format before opening it with an application and printing it, once you print it, you've lost all the original information.