There are a fair number of people using PDFX, and I'm not aware of any particular deficiencies in it. Except of course that it only works under Windows. The main problems associated with it have been related to the email feature, but I think the addition of the "Type 4" email option has provided a good SMTP-direct solution. (For those who insist on emailing via their email client, the problems that arise there have little to do with PDFX and everything to do with the security barriers and other restrictions of the clients.) But that's probably a digression, as you don't mention email as an objective. (If it is, EMAILX.SBX continues to be viable.)
There has been some talk of trying to produce a Linux-compatible equivalent to PDFX, but it's a daunting quest. Not so much because generating PDF from plain text is difficult - besides txt2pdf, there's even an A2PDF.SBX (ASCII to PDF) in the SOSLIB (based on the standard a2ps and p2pdf utilities) which does an acceptable job for basic text. The main difficulty is translating the //GDI graphic primitives into non-Windows equivalents.
I've glanced at the sanface.com stuff, but it seems to illustrate the difficulty just mentioned - it has all kinds of PDF-centric capabilities but they don't associate in any obvious way with the basic GDI primitives.
Probably Postscript would be the way to go in the sense of being feature-rich, capable, widespread, and PDF-friendly (via ghostscript). But again, it's way of looking at a page is entirely different than the Windows GDI approach.
(Actually, it should be noted that Windows GDI to Postscript converters must exist inside any Postscript Windows printer driver. The problem is that the logic is not only buried inside proprietary printer drivers, but entirely dependent on the Windows GDI environment and API, thus offering no easy way to port it to Linux, and therefore no advantage over the existing Windows PDFX driver.)
It has been difficult enough trying to eliminate the minor differences between printers and other output devices (previews, PDF, etc) in the Windows environment, where at least theoretically, they all speak the same language and go to the same church. The prospect of achieving that on the Linux/postscript side seems about as easy as recreating the Monty Python canon in Swahili. (The analogy is aided by the fact that for many people, the UNIX spool subsystem is about as confusing as Swahili. And from what I read, CUPS-PDF is particularly difficult to install and configure properly.)
It might actually be easier to translate the //GDI primitives to PCL, which at least shares a more consistent view of the page/graphic space (compared to postscript) and results in a file which can at least be tested against PCL printer, without requiring further drivers/converters/filters. That might be worthwhile, independent of PDF (i.e. providing //GDI support which isn't dependent on Windows). But that still leaves you needing another utility to convert to PDF.
All of which is
not to say categorically that it isn't worth doing, but that given the somewhat limited demand, it would probably make more sense to redefine the objective to make it easier to achieve. If we drop the idea of compatibility with the existing //GDI scheme, it becomes a lot easier. (In fact, it may already be done, since many people are already generating PDF output under Linux using existing utilities.)
When I start to think about the range of possible approaches, to the extent that the objective is closer to compatibility with the existing //GDI scheme, feeding it to a Windows machine doesn't seem like
that big of an obstacle. After all, unlike real printers, a single "PDF printer" should suffice for any size enterprise, since proximity to the printer isn't a consideration. And if you set up an AshLPD workstation somewhere on the network, you can just call it a "PDF network printer" and pretty-much ignore the details of it actually involving a foreign operating system. Compared to the circuitous route traveled by printouts going through the lpr/lpd subsystem via ghostscript/CUPS/filters/converters etc. (even in the case of ordinary printing to hardcopy devices), having the A-Shell spooler simply bypass all of that and redirect the file across the network to AshLPD doesn't seem materially more complicated or less pure.
If anyone is interested in taking on this project, my humble suggestion would be to consider writing an A-Shell print filter SBX (see
A-Shell Setup Guide > Printer Config > Init File > A-Shell Processing ). Such print filters have to be written in A-Shell/Basic, but that makes them quite portable, easy to install and distribute, and amenable to incremental improvements over time. A filter which converted a printfile (possibly containing a subset of the //PDFX or //GDI commands) into some standard format such as Postscript, PCL, or directly to PDF, would probably earn the developer a healthy measure of fame and appreciation (if not fortune).
