- Undo is not working. If you applied something it will be done. I had to reupload the pdf to again make the changes.
- I tried the text editing, it is having a defualt font family of `helvetica` and is automatically applied to the selected text once clicked and there is no way to undo or fix it.
In what scenario was undo not working? If you can provide that context, I can dig into it more as to what wasn't undoing properly.
For text editing, I see the issue with that for some of the fonts. Fixing now
Sorry for the trouble!
Apparently, the scanner(s) adopt some compromise setting that renders halftones OK, but gives all text a "dishwater gray" background.
If there are few pictures, I run the PDF through a quartz filter in Preview to threshold the text and later merge graphics pages with the "contact sheet" view from an un-threshold-ed image in Preview.app. This is slow and tedious.
Of course, computers are "smart," so they tell me, and should be able to recognize a picture from a block of text on the same page and render each one appropriately.
I used to do such editing of really important documents (like ads for pioneer computer products and gizmos like GENIAC and such)[0] pretty much by hand, splitting a PDF, if needed, into multiple images and hand/batch editing, then merging again.
I could use ImageMagick ... but it's not adaptive, as described above.
Geniac ad sample (imgbb.com)
[1]: https://scantailor.org/ [2]: https://github.com/scantailor/scantailor [3]: https://github.com/4lex4/scantailor-advanced
Unless BreezePDF is open source, (it is not) it is in violation of MuPDFs AGPL license.
The desktop app is only 58mb and uses effectively zero CPU, so it's about as far from bloatware as you can get.
Shoot me an email at joe@breezepdf.com — happy to jump on a call and walk you through it before you get it for your company.
Some features took a longggg time to do, such as table extraction, text editing, and (surprisingly) preserving positioning of elements (text, images etc.) when rotating the page in the downloaded file - PDF specification has a different orientation system than the web, so this was very intricate to get correct.
A lot of PDF editors have tools that all work independently, meaning you have to use each tool separately. My decision to add all the features I did while keeping it in one editor was because I felt that was a better user experience, but I means that all features become intertwined, which added a ton of complexity managing that.
A valuable feature of PDFs is wide and long compability. What I output now should be fully readable and usable on any system and in 20 or maybe 50 years. [0]
How do you have confidence that what you implement meets that specification? For example, if I edit the text, how do you know BreezePDF isn't subtley corrupting it? If I compress or flatten it, how do you know that about the output?
In fairness, it's a question for any file-based application, but PDF has a special status in it's universal availability and functionality.
[0] Is the timeframe in the spec somewhere?
Regarding your concern, if a manipulation of the PDF doesn't meet the standard specification, it won't render properly in a PDF viewer as it is in the present day, let alone in 20 years. All PDF viewers/editors worth their salt adhere to the PDF spec. So as long as the PDF specification stays the same, anything that renders correctly now in a PDF viewer will render correctly in the future.
For something like compression, if the file reduces in size and the PDF renders the same (minus expected potential minor quality loss), then you have evidence right there that it worked successfully.
I built BreezePDF with PDF spec adhering libraries, so everything should be up to standards.
Let me know if that answers your question!
