Earlier quoted context omitted.
I was asking "robocop2018". Are you him?
I am not "him" :) though I work at PDFTron As Nick says the project is open source ( https://github.com/PDFTron/webviewer-ui ). Express is available under under dual AGPL/commercial license ( similar to iText and lot's of other popular OSS )
Show HN: Pdf.js Express – PDF annotation, e-signatures, and form filling
71–80 of 136 posts
Re: Show HN: Pdf.js Express – PDF annotation, e-signatures, and form filling
#72I spent about three years building the support for PDF into my graphics editor https://www.Photopea.com . While other editors "add stuff on top of PDF", Photopea "chews through" each byte of a PDF, and tries to make as much sense of it as possible. You can rewrite the existing text (with the same formatting), edit bézier curves, edit gradient fills. You can edit bitmaps on a pixel level. You can see the parameters as…
Any chance you will package it for desktop? It would be great for Linux.
Re: Show HN: Pdf.js Express – PDF annotation, e-signatures, and form filling
#73It handles chopping up the pdf into pieces on the server as well as storage of annotations and some other stuff. We just got done integrating this in to a big MEANS stack app and hit a ton of challenges both client side and server.
On the client side we wanted to customize the annotation dialogs which required a ton of hacking.( we upload images and video snippets and role based access to annotations. We wanted to load two PDFs side by side and sync scrolling (Notta). On the server we had to wrap their api in a proxy so we could store annotations in Elastic etc. it was great in a lot of ways but a ton of work in other areas.
Generally how do you compare?
How are viewer modifications handled?
Great job getting the product out the door. This is a great space.
Re: Show HN: Pdf.js Express – PDF annotation, e-signatures, and form filling
#74The form fill demo only prints a bitmap. Is that intentional? The quality is completely unacceptable.
Yes, unfortunately the printing is done with a bitmap because of the lack of browser APIs to print scalable canvas content. It looks like our default print quality is a bit on the low side though, so we'll probably change that. You can use the API to increase the quality as well https://pdfjs.express/api/WebViewerInstance.html#setPrintQua... , for example instance.setPrintQuality(2).
Re: Show HN: Pdf.js Express – PDF annotation, e-signatures, and form filling
#75I spent about three years building the support for PDF into my graphics editor https://www.Photopea.com . While other editors "add stuff on top of PDF", Photopea "chews through" each byte of a PDF, and tries to make as much sense of it as possible. You can rewrite the existing text (with the same formatting), edit bézier curves, edit gradient fills. You can edit bitmaps on a pixel level. You can see the parameters as…
But it does indeed import each element of the PDF as a separate layer, and you have PDF export with options to leave text as-is, rasterize text, or vectorize it.
Two questions:
1) Does it set the resolution of the Photopea file, and the default resolution to re-export the PDF, to trying to detect the original resolution of images in the PDF? So that by importing and exporting, you're going to have a PDF of approximately the same quality and filesize?
2) Are you able to handle embedded fonts, including subsetted fonts? I assume that in that case you would vectorize it and wouldn't be able to type new characters... just want to know if I'm wrong in assuming that?
Thanks again a million times over for Photopea. It remains my absolute #1 inspiration of what one developer on their own can do. Never ceases to amaze. :)
Re: Show HN: Pdf.js Express – PDF annotation, e-signatures, and form filling
#76Earlier quoted context omitted.
The biggest challenge to pricing based on volume is the exercise of tracking usage. In a typical SAAS product determining usages is fairly linear. For PDF.js Express because you would be deploying from your environment we would not have an accurate way to measure usage. Fundamentally I agree with you - you should pay for what you use. Unfortunately at this time we are not able to implement that effectively. Also keep…
Good point. What if you have two models: - One: the model you have right now. this is for organizations where the value outweighs the price tag. - Two: Smaller organizations are generally also more willing to compromise on JS/asset bundling and performance. Why don't you give them: - a hosted JS solution where they just have to include a tag - An uglified script. I'd argue most JS developers can't unscramble these -…
Re: Show HN: Pdf.js Express – PDF annotation, e-signatures, and form filling
#77I'm all about the open core business model.. but are you guys affiliated with the core pdf.js team? $440 / month is pretty hard to swallow. I love that you guys included a build vs buy section, but I think it's going to be difficult to land clients at this price point because higher end clients are more likely to choose the build vs buy option. Anyhow, the product itself looks well structured. Congrats & best of luck…
This is a commercially supported solution so the price is actually not bad ( given alternatives )
Re: Show HN: Pdf.js Express – PDF annotation, e-signatures, and form filling
#78Overall looks like a great solution, and definitely a gap in the market. On a side note, I hit the "Try for Free" button on the home page and got a 404.
Re: Show HN: Pdf.js Express – PDF annotation, e-signatures, and form filling
#79What is an ancient react UI?
Re: Show HN: Pdf.js Express – PDF annotation, e-signatures, and form filling
#80I have a startup and we are highly reliant on PDF rendering in our application. But here's the thing, Nik: your pricing model doesn't make sense to me. In general, most PDF SDK models don't make sense. I have searched a lot over the years, and am left consistently disappointed. You charge the same amount to large commercial customers as you do to small startups, who are trying to save every penny. Even though I reall…
The biggest challenge to pricing based on volume is the exercise of tracking usage. In a typical SAAS product determining usages is fairly linear. For PDF.js Express because you would be deploying from your environment we would not have an accurate way to measure usage. Fundamentally I agree with you - you should pay for what you use. Unfortunately at this time we are not able to implement that effectively. Also keep…