Hey William, Sure makes sense. I just didn't want to spam the list with back and forth conversation about the issues etc. However here's what I sent to one of the people who responded.
Here's the issue we're running into, using both poppler-cpp and another PDF library designed for writing/creating PDFs we've built a "PDF Editor" of sorts. Editor is likely the wrong name, more like PDF appender. Our system targets lawyers who do real estate transactions. Part of their job is to actually create the mortgage documents that the bank sends them (adds the client name, property description, amount, interest etc). This is tedious and the PDFs rarely change but you just never know. Our system gets the PDF and does a hash (excluding the doc info) and then stores that. We then show the client over a web interface an image of each page where they can drag/drop fields. We then write out the content of that field for that file to the PDF and voila, a mortgage document in 2-3 seconds instead of sometimes 4 hours. Everything above works great and has been in use for a couple of years. Here's where it becomes problematic. We have about 10-15 forms (of hundreds) that contain XFA forms with Javascript that then takes 1 or 2 form fields and outputs a barcode. I can't remember the kind. When we try to process that, depending on the PDF, we either get the "Use Adobe blah" as the pdf output though more rarely. Or we get the images of the PDF just fine but because we ignore if forms exist, and can't interact with a XFA forms anyway, we don't know the barcode is there etc. I've done a bit of research, and have the XFA 3.3 spec. I realize there are issues because the xml ns refers to a non-existent domain/url. I've also seen that Xpdf 4.x has an XFAForm.c but have yet to see if it can handle these kinds of forms. So what I'm looking for is enough of support in poppler that I can know that the form exists and some how automate the extraction of what the barcode would be. Better yet would be maybe a list of form fields with names. Even better would be the ability to set those fields' data instead of us writing "over top". But I would be happy with the first part. I'm willing to do some or most of the work to be honest but if someone was able to do it faster and for a decent price I'd love that even more. I am relatively new to the PDF spec so if I'm doing I'd pay for 'rapid response help' so I'm not sitting staring at the same code for days. If porting the Xpdf 4.x XForm over is a good start then great, or whatever the best way would be I'm all ears. Thoughts or problems with this? Sincerely, -- Nathanael On Tue, 2020-03-03 at 22:23 +0000, William Bader wrote: > If you can say exactly what you need, if you post it on the list, one > of the maintainers might have suggestions how to do it (which could > be important if you want the changes to be accepted so you don't have > to maintain your own poppler fork) or someone on the list might have > done something similar privately that could be a starting point for > what you need (and would help with the cost and timelines). Regards, > William > > From: poppler <poppler-boun...@lists.freedesktop.org> on behalf of > Nathanael d. Noblet <nathan...@prolegis.ca> > Sent: Tuesday, March 3, 2020 4:12 PM > To: poppler@lists.freedesktop.org <poppler@lists.freedesktop.org> > Subject: [poppler] Contract / Consulting > > Hello, > > I'm wondering if there are any developers on this list that are > willing/interested in some consulting/contract develop related to > poppler? If there is I'd love to have a quick private conversation > about our needs and get an idea of cost/timelines etc. The work we'd > pay for would be for poppler so not closed source or anything like > that. > > Sincerely, _______________________________________________ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
