
PEP – An open source PDF editor for Mac - threcius
https://macpep.org/
======
wolfium3
I have a dream... that one day people will name their projects with names that
don't exist on google yet.

If you search for PEP now you'll find python enhancement proposals, and the
"Philippine Entertainment Portal" and the stock code for PepsiCo.

~~~
tzs
I wish that once people do name their project, they would assign it a 128-bit
random number in lower case hex, and include that number on any web page that
they would like people searching for their project to find.

That way once I know that say PEP the PDF editor exists and find its 128-bit
number (let's say that is 379dd864b16eaca3ce94c15a6bdfcc73), at least I can
subsequently toss a +379dd864b16eaca3ce94c15a6bdfcc73 on my searches to
effectively let the search engine know I want PEP the PDF editor results
rather than PEP the python enhancement results or PEP the entertainment portal
results or PEP that refreshing beverage company stock symbol.

"xxd -l 16 -p /dev/urandom" is a handy way to get a 128-bit random hex number.
A UUID generator works, too, although they usually include some punctuation
you will need to delete and you might have to lower case their output.

~~~
MaxBarraclough
> I wish that once people do name their project, they would assign it a
> 128-bit random number in lower case hex

We already have something similar: URLs.

~~~
wtetzner
Except a URL only points to one resource. The idea here is that this
identifier would exist on any resource related to PEP (maybe even in URLs).

~~~
notatoad
>Except a URL only points to one resource

isn't that exactly what this is asking for though? A URL can by definition
only point to one resource. So if you include that URL with every other
reference to the project (in the app descriptions, blog posts about it, etc)
then you always know you're talking about the same thing. It makes a lot more
sense that any resource related to this PDF editor should include a link to
"[https://macpep.org](https://macpep.org)" instead of including some random
128 character string. Any resource related to python peps should include a
link to "[https://www.python.org/dev/peps/](https://www.python.org/dev/peps/)"
(which all PEPs do, by virtue of having a url that's a subdirectory of the PEP
index URL)

------
strogonoff
A GUI app for manually crafting PDFs is one thing, but a _library_ instead
would enable countless developers to create software capable of producing PDF
deliverables as output, possibly improving the accessibility situation too.

I would gladly sponsor the development of a reliable library that allows to
programmatically produce compliant, accessible tagged PDFs with arbitrary
layout[0], correctly printable and viewable by mainstream software.

(Considering it is a difficult, yet to be solved problem, I’d have to know the
qualities of the approach that distinguish said library from not-quite-capable
attempts that already exist before I commit my personal funds.)

I would not mind if said library’s developers release an entirely paid end-
user GUI software based on it, as long as the library itself remains under
active maintenance.

[0] Supporting commonly used paged media typesetting features such as headers,
footers, page numbers, running headers.

~~~
tkfu
Are you familiar with Prawn [1]? Perhaps I just haven't bumped up against its
limitations yet, but in my experience it's exactly what you're asking for. Of
course, it's in Ruby, which isn't to everyone's taste, but it's the best tool
out there that I've found.

[1] [https://github.com/prawnpdf/prawn](https://github.com/prawnpdf/prawn)

~~~
strogonoff
Prawn was considered and IIRC unfortunately it has very limited styling
support.

It looks like there are only commercial and quite expensive options for
programmatic generation (Antenna House: XSL-FO, Prince: CSS). Apart from that,
the one option that works appears to be Apache FOP. It’s built on Java and
uses XSL-FO, which is somewhat limited and seemingly on the way to becoming
outdated.

~~~
phonon
[https://weasyprint.org/](https://weasyprint.org/) is quite nice, though has
limited header/footer support (for now).

------
mdaniel
> its own PDF engine, built from scratch

Just be careful, many larger teams have taken on that PDF spec, and it has not
ended well for them:
[https://nvd.nist.gov/vuln/search/results?form_type=Basic&res...](https://nvd.nist.gov/vuln/search/results?form_type=Basic&results_type=overview&query=pdf&search_type=all)

and it seems to be one of the main actors in what are termed "polyglot" files:
[https://truepolyglot.hackade.org/](https://truepolyglot.hackade.org/) (of
which my favorite is:
[https://news.ycombinator.com/item?id=18344778](https://news.ycombinator.com/item?id=18344778)
_0x15 is a laser-projectable PDF that 's also a ZIP containing, among other
things, another PDF that is also a Git repo of its own source code._ )

------
Gys
Adding a roadmap with potential features would be nice. Otherwise one is
actually asking for financing a personal pet project. A list of existing
alternatives (incl MacOS Preview) could be added and an explanation why this
project will be different (or ideally: better).

~~~
narwally
Isn't Preview limited to just annotations, or does it also do editing?

~~~
JKCalhoun
Aside from annotating, Preview can crop, reorder, rotate, delete, and insert
pages in a PDF.

But at its core, it does not "non-destructively" edit the dictionaries and
object graph of the original PDF. Instead, it replays the original PDF into a
new PDF context.

------
planb
Hi, developer of a PDF scanning app for macOS (PDFScanner) here. I always
toyed with the idea of developing a PDF engine from scratch but the spec
scares me. Kudos for being that brave! Just curious: Why did you choose
Objective-C for a new lib?

~~~
threcius
Helllo, good question, and the answer is simple, I am more familiar with
Objective-C and I get used to it.

~~~
pier25
Aren't you worried about Apple killing ObjC down the line?

~~~
prewett
Their whole UI is written in ObjC, they've got two decades of Mac apps in
ObjC, and they wrote a whole new language to interface cleanly with ObjC but
with nicer semantics, so I'm guessing ObjC isn't going anywhere.

But even if Apple does remove it, everything apart from the UI would still
compile in GCC's ObjC compiler. The guts of this project is the PDF engine,
not the UI, and that would still work. TeX is written in a language that
pretty much only Knuth uses, and it's still very much working.

~~~
armadsen
More than just their UI, fundamental parts of Apple's OSes are written in
ObjC, including very new components like ARKit, CoreML, and the Metal API.
Apple continues to write tons of new Objective-C code every day. Of course
Swift is making inroads inside Apple, but Objective-C has to be well supported
for a very long time to come.

I've been writing Objective-C for 15 years, and continue to do about 60-70% of
my work in ObjC (the rest is mostly Swift). I'm not particularly worried about
my code being unusable anytime soon. When Apple starts making a real effort to
wholesale migrate away from ObjC, I will too.

~~~
pier25
What about Cocoa? You think it still makes sense to invest dev time in a Cocoa
app?

~~~
armadsen
That's a little more ambiguous. Until very recently I was primarily a Cocoa
developer (took a full time iOS dev job a few months ago), and it still makes
up a significant portion of my side work, so I'm biased. But right now, the
alternatives are SwiftUI and UIKit/Catalyst. SwiftUI nicely integrates with
AppKit/Cocoa, but anyway, it's in pretty rough shape on the Mac at the moment
(see
[https://news.ycombinator.com/item?id=24472063](https://news.ycombinator.com/item?id=24472063)
for example). Catalyst is (IMO) basically garbage if your goal is to make a
great Mac app. Its purpose is to allow easy porting from iOS to Mac, not to
create truly good _Mac_ apps.

Obviously, the presence of these two technologies, and Apple's pushing them is
evidence that Cocoa may be on its way out, but it's not deprecated, and is
still officially the recommended way to build true Mac apps. Undoubtedly it's
SwiftUI (not Catalyst) that will eventually displace it, but especially on the
Mac, SwiftUI is not really ready for production yet.

~~~
pier25
I agree with all your points.

I considered getting into Cocoa dev but between the lack of resources and the
probability that Apple will kill it in the not so distant future, it didn't
make much sense.

Better wait a couple of years until the mud settles.

~~~
armadsen
I think that's eminently reasonable. As someone with 15 years experience doing
Cocoa dev, the intention to be a Mac dev indefinitely, and hundreds of
thousands of lines of existing Cocoa and Cocoa Touch code, it's just going to
be a slow transition. But there's no pressing reason to just stop writing any
new Cocoa code (I literally wrote some since my last comment :-P). If I were
starting now, I'd probably focus on SwiftUI with the assumption that it will
be the way to start most new projects within the next few years.

------
arusahni
For a second I thought this was a Python Enhancement Proposal.

~~~
Paianni
Reminds me of a resolution of GDPR I had when I first heard of it.

'German Democratic People's Republic'

~~~
zaarn
It would be the Federal Republic of Germany. Or the Democratic German Republic
if you think of the east block.

------
bluedino
The UI for all of this guys apps is very strange...is this some sort of web-
wrapper for OS X or custom views or what?

~~~
threcius
Hi, i am the guy, and almost all view are custom views (native Cocoa/Objc),
except that some of them (like in the About window) are WebView with
HTML/CSS/Javascript.

------
AndyMcConachie
The one problem I consistently have with PDF forms on the Mac is an inability
to change the font size in text fields. My work even pays for me to have the
professional Adobe suite and that specific functionality doesn't exist. If
someone could solve this problem I would probably give them some money.

~~~
threcius
Just noted down your requirement in my Apple Notes, I think I will take a look
at it later while render and editing PDF forms.

These kinds of comments are what i am looking for, thank you.

------
itsEtai
Very cool!

I currently use adobe acrobat to make pdfs accessible
([http://www.w3.org/TR/WCAG20-TECHS/pdf](http://www.w3.org/TR/WCAG20-TECHS/pdf)).

Are you planning on building in accessibility tools?

------
MKais
The PDF file format specification has 971 pages.
[https://www.iso.org/standard/63534.html](https://www.iso.org/standard/63534.html)

~~~
threcius
Just create a simple PDF example by using TextEdit's export function, and open
the PDF with a plain text editor, you should be easy to figure out what's
going on in PDF.

------
nisuni
The apps by the same author are very, very interesting:
[http://www.pixelegg.me](http://www.pixelegg.me)

------
svnpenn
If someone knows something like this for Windows, I am currently offering a
bounty:

[https://softwarerecs.stackexchange.com/questions/19011](https://softwarerecs.stackexchange.com/questions/19011)

I am willing to increase the bounty, but I only have 297 rep currently

