Nick here. We're super excited to officially launch PDF.js Express [1].
PDF.js Express wraps a modern React UI around the PDF.js rendering engine to enable PDF annotation, form filling, and signing inside your web app. We've also made some improvements to PDF.js text search, and taken a different approach to how the viewer uses the PDF.js rendering API, resulting in sharp graphics at any zoom magnification [2].
Based on our research, more than 70% of those who try to implement these features on top of PDF.js find it too difficult or time-intensive [3]. For those who are successful, supporting the new functionality is also challenging. To help these developers in achieving their short-term goals, and to support them as their needs evolve, we built PDF.js Express.
Check out the demo and let us know what you think or if you have any questions [4].
If you're helping fight COVID-19, it's free [5].
[1] https://pdfjs.express/blog/introducing-pdfjs-express
[2] https://pdfjs.express/pdfjs-vs-express
[3] https://pdfjs.express/blog/build-vs-buy
[4] https://pdfjs.express/demo
[5] https://pdfjs.express/blog/pdfjs-express-free-to-those-fight...
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 CSS or export it into an SVG.
Also, it is free. People open about 150,000 PDF files a month in it, but I hope it will get more popular in the future.
Demo PDF: https://www.photopea.com/api/img2/WEBSITE-ZLONIN-uprava.pdf
Photopea: https://www.photopea.com#%7B%22files%22:%5B%22https://www.ph... (press T and click into the text to edit it)
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. :)
That means, that PDF does not contain any DPI information. It is not needed at all. PDF rasterizer (e.g. a raster printer) can render it at any DPI. Photopea decodes and saves back bitmaps inside PDF in the original resolution. The rest is vector graphics.
2) For now, Photopea ignores embedded fonts. But it extracts the font name and in 98 % of cases, we already have the required font in our database of fonts, so we can render it identically.
Any chance you will package it for desktop? It would be great for Linux.
Perhaps packaging it with electron could be an option, but it's an additional burden (I know by experience) that I'm not so sure is worth it.
Nice to see that you have the Photoshop UI there so I don't have to relearn anything.
I've immediately posted it on HN (hopefully I won't be downvoted just for linking my own post).
Two suggestions: 1. Make it clear to users why install button is greyed out. I know it, but most won't. 2. Allow login with any oauth provider, not everyone likes to be tracked across the web
Is there a way to change resolution during editing? When I zoom in in Photopea, I can see individual pixels of text characters. With some PDFs pixels show up sooner, making text barely readable during editing.
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 really value the technology you have built, you have not allowed us to "pay-as-we-go". I am not interested in your trial and the trials of your competitors because you don't allow me to start with a $5/month plan based on volume of usage. And so, we have resorted to writing the wrappers around PDFJS ourselves, slowly and steadily over months and years. Even though we might end up spending the same amount over 2 years by doing these things ourselves, at least we will understand the technology and own it perpetually.
Just charge us based on volume, so your revenue can align with our revenue. It will create much larger traction among small developers. If you are not targeting that audience, I understand, but I contend that most people on places like HN are that audience. Be more like Crocodoc (the company Box acquired). I really don't want us to keep reinventing the pieces here because this is not our core competency.
1. Community edition - no direct support, maybe some enterprise features no available (like Sencha.com)
2. Hosted version - easier to PAYG with a lower price point per use (like Typekit)
3. One off purchases with updates for just 12 months. Updates then require licensing (like Sketch)
The other option is that you only got for enterprise and exclude the startup and indie developers. Enterprises tend to have no issue doing the right thing. If you're worried about smaller developers taking advantage, then you need to weigh up the long term benefits.
Just remember, if it's hard to do, it doesn't automatically make the wrong choice the right choice.
- 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 <script /> tag - An uglified script. I'd argue most JS developers can't unscramble these - you keep counters on number of requests - you disqualify (using some basic hashing method) run-ability of PDFJS Express based on the time the script was requested OR if an acknowledgement from a server fails. So say, if someone is using a cached version, the script will either not run at a certain point OR all the documents will be watermarked with "TRIAL".
This second way could also be the best way for getting people started immediately. Include a tag, see a watermark, but you are ready to go.
I would really like to know whether or not "PDF.js Express" is open source. Why? Because I've done a lot of work on react + pdf.js already (for a latex editor), and it's been high on my todo list to add annotation features. So PDF.js express significantly overlaps with something I'm very seriously planning to do...
The website says it is open source in one place, and then in other places it says it is a "commercial PDF web viewer that wraps around the PDF.js open-source rendering engine."
I didn't see any link to the source code or license anywhere on the site?
$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.
Your product looks pretty awesome. It's super polished for your initial launch! Congrats!
I'm curious how long it took to build the product and how large your team is? Do you have some initial customers?
I'm building a similar paid Javascript Library business (https://www.dropkiq.com/). I would love to connect if you want to share some ideas? Feel free to shoot me an email if you're interested: adam@dropkiq.com
Adam
If you're ever interested in licensing a version to work with custom grammars (not liquid), I'd be interested! (email: ted AT instabase.com)
I'll keep your email handy if we're able to help down the road with non-liquid grammars.
[1] https://pdfjs.express/blog/building-pdfjs-viewer [2] https://pdfjs.express/blog/build-pdfjs-viewer-ui
I'm not here to argue, just making an observation.
Website design is poor. You could definitely do with a designer to make it look nicer.
$5000ish a year is a weird price point. It's too expensive for a hobbyist or small dev shop, but too cheap for an enterprise to buy (when you consider the time of working on procurement problems you'll experience).
You either need to make it cheap, like $200/yr, or much more expensive. Right now you are in no mans land.
You also have a * next to limited support on pricing page, but I can't see what that explains.
Offering no refunds is strange and your copy comes off passive aggressive about this. Why? As a new service I'd be all about offering full refunds with no questions asked. Most people don't ask for refunds, and you can learn very important information when they ask for one.
Terms page is very short and doesn't have a lot of terms I'd expect for a product charging $5k/yr.
Don't worry about it not being open source; that's fine.
Really, in what way? In my view it's clean and simple.
> You either need to make it cheap, like $200/yr, or much more expensive. Right now you are in no mans land.
Another unsubstantiated statement. How much market research have you done on PDF libraries?
Pricing is a sensitive topic and many factors play a role in it. Too many to be assessed by an armchair expert.
> Don't worry about it not being open source; that's fine.
Where did OP express any worries about it not being open source?
[0] https://www.blendernation.com/2009/06/11/3dmagix-re-branding...
I don't see it in the Demo. Did I miss it ?!
They bundle both a Apache 2.0 "PDFJS-LICENSE" AND a "PDF.js Express Evaluation License.pdf" which seem to conflict with each other.
What is an ancient react UI?
For non-React users (and React users, for that matter), I started working on wrapping PDF.js up into a web component for use in any framework or in plain HTML or Markdown: https://www.npmjs.com/package/pdf-viewer-element
The idea is to make a `<pdf-viewer>` element that's as easy to use as if it were built-in to the browser.
As PDF.js Express shows, this is a pretty deep UI and feature area to tackle. My project is incomplete and doesn't have anywhere close to the features.
I think complex viewers are one of the ideal use cases for web components though. These components require a lot of work to do well, and we shouldn't have to re-implement them for every framework. The 3D gltf viewer, `<model-viewer>`[1] is another great example.
Congrats on your launch. Just wanted to tell you that there's another service called PDF eXpress that's in use for IEEE conferences to make sure the authors conform to the given template. I know it's not exactly the same name, but might be worth looking into viz. copyright or trademarks.
More info on PDF eXpress: https://www.ieee.org/conferences/publishing/pdfexpress.html
It 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.
Overall 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.
I cann add characters; but cannot remove them with DEL or RETURN keys cc https://ibb.co/zX4LQwL
Cheers
