philjohnson

Sorry about that! Fixing now

Well, if you aren't a developer you're not going install a PDF editor by going to GitHub, especially if having a desktop app means downloading the code yourself. Also, all of these you listed were created within the last 6 months, which is after when BreezePDF was initially created anyways. Lots of options out there, everyone can choose however they see fit!

Last year there were a couple features, but it was pretty limited. In the year since, I've added a ton more features, created desktop app and CLI. So it was a major overhaul since last time, which is why I posted it again

Agree

Great point

Got it, thanks for the explanation! When I add OCR I'll add the ability to search the OCR'd text within the document very soon when the downloadable version goes live. Stay tuned! I'll follow up in this thread once it's ready.

Glad to hear! Yes, OCR is definitely coming, though it'll be in the one-time payment downloadable version. I'm curious, what is your use case?

Yes you can inspect it, just inspect source. Since everything runs in the browser, it's all inspectable.

Thanks! It's not on GitHub because I don't desire for it to be redistributed by others. I will be releasing a downloadable desktop version (as a Progressive Web App) with even more features for a nominal one time payment. It makes the most sense to do it this way because having some monetization is good motivation to keep improving the product, while people still getting the benefits of running it completely locally.

Besides, most people working with PDFs aren't developers who wouldn't be able to host it locally on their own.

Yes, that's a good way of framing it. Though technically the files are executed in the browser. Will be releasing downloadable desktop version soon.

you're welcome!

thanks!

Yes, though both of those send documents to their server which might be a concern for some people. And most people working with PDFs wouldn't know how to setup stirling locally.

BreezePDF doesn't send any data to the server, and for even further assurance, I'll be releasing the editor as a downloadable desktop version very soon.

Seems cool! Thanks for sharing. Even though it's MIT licensed it's written in Java, so unfortunately I can't borrow any code, but it's nice for inspiration.

Got it. The functionality that your after is something I'm definitely considering. It could have broad applications.

I'm curious where you land on this after planning, would it be okay to follow up? You can send me a note through the contact form on the BreezePDF homepage or let me know the best way to get in touch. Cheers

I’m glad it can be of use!

Hopefully it will soon, the site is brand new :)

Thanks!

As of now I don’t plan on open sourcing. I think open sourcing software that I plan to monetize would create bad incentives. There are several companies of note that were very permissive early on with open source, and eventually after the product was built in large part by the community, they closed sourced it. I think it’s more honest to not open source it in the traditional sense, as there’s no chance of close sourcing a product that the community would have helped build for free.

What I’m thinking at the moment, to fully answer your question, is to have a downloadable version for a fair, one-time price. As of now I think this approach provides the best balance between monetization and having full trust in the software and the ability to modify the software as you wish.

Yeah there is currently a bit of overlap, but even with my software in it’s current state, it has password protecting a PDF, merging PDFs, reordering pages and adding input fields, all of which Firefox doesn’t have.

And, I’m just getting started with this, lots more features to be imminently!

You’re welcome, and thanks for the kind words.

Yes, lots of new features coming as well as a downloadable desktop version.

A table is definitely something I will add! Thanks for the suggestion.

Stay tuned!

Not sure if you're referring to external or internal links but external ones are indeed preserved when once you download the modified PDF.

I've updated it so that external links are also clickable when viewing the PDF in the editor. Working on getting internal links to be clickable and function as well.

Let me know if this fits what you're after

Based on my understanding of what you're saying, here's my idea that I could build:

You would add variables in the interface, and there would be a secure sandbox in the client where you can call the API of your headless CMS, and with an sdk you could create PDF programmatically assigning the respective variables with values from your headless CMS API response. Then a button to print them. This keeps everything fully private in the browser while automating the process.

Would that work? For reference, what would you expect to pay for this if you wanted to go this route?

Wrapping fixed! So now it only goes to a new line if you hit enter, which is probably the best approach. So the text should render the same in the editor as it does when it downloads.

Thanks for the feedback, and let me know if you run into any more issues!

Sorry about that. Would you mind sharing the console logs? Perhaps it's showing an error that I can use to debug and fix. Thanks!

The service worker functionality can be expressed as a PWA! Based on the comments I'm thinking of heading in that direction.

As far as touchscreen PDF editing, that is 100% doable and something I plan on adding soon. Touchevents are supported natively in the web

https://developer.mozilla.org/en-US/docs/Web/API/Touch_event...

This is a great idea. I was actually just suggesting PWA with opt-in updates in another comment I was just replying to, so it's affirming to hear someone else suggest it as well. Love the changelog piece.

Now the question is if people would be willing to pay. Perhaps it could be a nominal one-time payment to get the PWA and updates for up to a limited amount of time, or monthly amount to get updates indefinitely.

And maybe the URL accessed web version stays free with the core features, and PWA has benefits of both offline and some extra features.

Would you be willing to pay for something like this?

Thanks!

The "offline only" app could be a PWA where you can access if if you're offline but I could even enforce disabling network requests in the code itself. Seems like the most straightforward solution to me. Could even make updates opt-in. Would keep it lightweight and easily accessible for anyone.

What do you think of this? Would you be willing to pay for this, or are certain features you'd be willing to pay for? Curious you're thoughts.

Thanks, and cool project you've built!

Yeah, you're right on that it's perception problem rather than tech. It's interesting because it's much less intuitive to inspect the code/network requests for a desktop app which on it's face seems less transparent than something on the web, but the kicker is that there is no URL that you're accessing it from so it feels safer.

I'm thinking now actually if I did a PWA? I think it has the psychological benefit of feeling of an offline desktop app (which it can function as), but is lightweight and less maintenance than an Electron app, while still having the benefit of automatically updating when I make improvements without needing to manually make updates.

Where I'm struggling on the open-source question is that in the PDF use case most of them are not developers and don't know what open source is let alone host it lol. And most businesses can probably afford to pay a nominal fee to host it themselves and modify it if they wish, which many companies offer. It would be different if the product was something like a database or code package where it's always going to be a developer using it.

While open source might actually have more "freedom" for people to modify it for free initially, in a way it can be more honest for a developer with any commercial intentions to not open source something while offering paid ways to modify the source code, as we're seeing more and more that companies start out with a very open source product that they then revert once the community has helped develop it. Not that it needs to happen that way, but with commercial aspirations one needs to be careful as something becomes popular, it becomes too tempting to take back once open-source parts.

Forgive the wall of text here, I'm thinking out loud haha. Appreciate your comment!

Me :)

It runs on an very inexpensive VPS. There's no VCs or anything with this and since all processing happens on the users device, my costs won't really change at all.

Still figuring out potential monetization. Is there anything you'd pay for?

Thanks!

> trust All fair points that you're making. I see no reason I would change my mind to send PDFs to the server, but I understand your concerns. If I'm reading in between the lines of what you're saying, that the way to alleviate these concerns is to make it open source?

I think that's a compelling argument, but to play devil's advocate if most people realistically working with PDFs aren't developers and thus wouldn't go to GitHub to host it themselves, then what would change for them to have a self-hostable option? If I released a desktop version, might the average person would see that as "private" and have any privacy concerns relieved, whether it was open sourced or not?

There is always a degree of trust you put in any company's software you use, and it's up to the company to be good stewards of that trust. If they break it, it's always bad for business anyways. But there is a point that if it was open source, those who have the desire to do so can continue using it without any concerns, which is fair.

> anyone can see the html/javascript Yes minified javascript is not the same as open source, but mine is not minified. Plain HTML, CSS and vanilla JS. So given that and since all the editing happens in the browser, the entire source code is inspectable for anyone who wants to see.

Given that the average person editing PDFs is not tech savvy, and as you said they don't really know the difference between software options, then given that what do you see as the utility of open-sourcing, from a business or even public good perspective? Genuine question.

> Though, maybe I'll add something where you can pay to get the desktop version I can see why someone would think that, but really at this point I'm figuring out what/if there is a monetization method here, and I'm not set on a particular path. I don't have any agenda to just make it free then close it off. That'd probably be a bad business decision anyways. I'm not sure if desktop is something to charge for, or if desktop and the whole thing is better to be free and open-source along with premium features that people can optionally pay for that are outside the core scope. I'm still thinking through it.

Ideally, I'll make all core features open-source while there are also some extra features people are willing to pay for. I'm just still wrestling with even just from the public good perspective, for the vast majority of people that won't host it themselves how would they benefit from open-source versus the core features just being free?

Curious if you have any response to what I've laid out here.

Appreciate your thoughtfulness!! You've given me a lot to think about.