1. https://github.com/OnedocLabs/dev-local>
2. https://marketplace.visualstudio.com/items?itemName=mathemat...>
161–170 of 191 posts
1. https://github.com/OnedocLabs/dev-local>
2. https://marketplace.visualstudio.com/items?itemName=mathemat...>
One of the features I wish I had with htmldocs was the ability to automatically store generated documents in my own S3. I'd rather not introduce another cloud to my data stack just to host PDFs.
Back in the days, I used to use XSL-FO [0] and it was okay. It was not very precise but it rarely if ever broke, and was perfectly integrated with an XML/XSLT solution. Yeah, this was a long time ago.
Last month I used html-to-pdfmake [1] and it's also not very precise and more fragile, but very efficient and fast.
Yet another approach would be to pro grammatically generate .rtf files (for example) and use Pandoc [2] to produce PDFs (I have not tried this in production but don't see why it wouldn't work).
[0] https://en.wikipedia.org/wiki/XSL_Formatting_Objects
Earlier quoted context omitted.
Giving credit where it's due, I can appreciate Microsoft for introducing XPS as an alternative to pdf. There was a time, when not every software had "export to pdf". So, having a "print to pdf" meant installing (often pirated) Adobe Acrobat or installing a sketchy free(ware) printdriver software downloaded from sourceforge. MS adding xps print driver to windows enabled sharing docs consistently (within windows ecosys…
Indeed, we need to give credit to MS for what they did. However, it didn't catch up as you mentioned, maybe due to timing, skepticism toward MS, or the complexity of moving from Adobe to MS for PDF management. I will dig a bit into it and come back later if I find anything interesting.
Why does your dev-local repo[1] README have a link that's described as being the Adobe PDF viewer extension for VS Code but actually link to an extension that uses pdf.js by a company called Mathematic[2]? 1. https://github.com/OnedocLabs/dev-local > 2. https://marketplace.visualstudio.com/items?itemName=mathemat... >
May be this is just me but this looks extremely costly to me! It will cost $2,500 to generate 50,000 PDFs. Are edits/corrections additional cost?
I second this. Maybe I'm missing something in the value proposition, but we already generate PDFs from .docx/.html templates using open source libraries and Docker microservices. Do not misunderstand. A Stripe for generating PDFs can be great, but for a small team, $0.50/PDF is way more than I can afford (after all, you can create a small number of PDFs without too much fuss). Maybe you are oriented towards large com…
But isn't that 100x what they're actually charging--at least for an enterprise account? Their pricing page says "from $0.005/doc." (Though I'm not sure how much work "from" is doing there.) Pro tier is, admittedly, more like $0.12 per document (assuming you use your full quota). But still much less than $0.50/
I'm generally very confused by the various assertions in this thread about their pricing. What am I missing?
Why does your dev-local repo[1] README have a link that's described as being the Adobe PDF viewer extension for VS Code but actually link to an extension that uses pdf.js by a company called Mathematic[2]? 1. https://github.com/OnedocLabs/dev-local > 2. https://marketplace.visualstudio.com/items?itemName=mathemat... >
Earlier quoted context omitted.
In the long term, ~$0.005 per page (as opposed to document, which I assume hatchedlake meant) say on a mortgage document (~300 pages per) it adds up. The other alternative, which is to build this in-house (say 3 months and custom build, edge cases, such goodies), is more desirable (for us).
I was looking at https://www.onedoclabs.com/pricing which says $0.005 per document, not page.
Useful service and a large problem space. Congrats and all the best. As someone who is a target customer, my 2 cents: a. If this is a strategic value for my pipeline (and it is), we are going to code it ourselves, only because we can host it inside our fences. Critical customer data and hence. b. The pricing is way off and is not reflective of the cost or value (for us). Even if it was 1/10th of the prices you charge…
FYI: the open source state of the art in this area is Playwright (the successor to Puppeteer) with Paged.js ( https://pagedjs.org/ ). I highly recommend that everyone check out and donate to paged.js, it's a fantastic project with lots to like. It certainly blows commercial alternatives like Prince XML out of the water. That forms a solid foundation that I find it hard to imagine paying for. The things where you migh…
I think https://github.com/diegomura/react-pdf is closer to what this company is doing. In fact their open source library, https://github.com/OnedocLabs/react-print-pdf , seems like a higher-level library that sits above react-pdf. Reminds me a lot of the set of react-pdf based components I built for a corporate job where letting users create PDFs was a huge part of the value proposition. They're solving a really coo…