Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PEP – An open source PDF editor for Mac

macpep.org

Post reply on HN
Print view View original

71–80 of 113 posts

Re: PEP – An open source PDF editor for Mac

#71

Post by prewett »

pier25 wrote: post #56
threcius wrote: post #10

Earlier quoted context omitted.

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

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

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.

Re: PEP – An open source PDF editor for Mac

#73

Post by strogonoff »

awinder wrote: post #64
strogonoff wrote: post #20

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…

How would your approach differ from something like RMarkdown or similar? Still trying to nail down the differentiation.

At first approach it seems to be substantially different from what RMarkdown is intended for, though maybe I am not seeing some outside-the-box ways of using it.

What I would like is more oriented around creating documents according to particular layout specs. Documents (books, technical documentation) that can be created using InDesign, but this time programmatically[0].

As content should be authored using semantic markup (for accessible PDFs to be produced), and styling & layout capabilities should be flexible enough, I can see how HTML+CSS paradigm could be viable (and would allow reusing many useful parts from web stack, such as self-containing components).

If going with CSS, the latest spec is close but does not yet seem to be there as far as proper print media layout capabilities. A viable path could be extending an existing engine (Chromium?) specifically where it renders for print media, enabling rendering to accessible tagged PDF, and likely even introducing new styling capabilities making the spec a superset of CSS.

(This all under assumption that it is at all feasible to achieve proper accessible PDF output using browser’s print capabilities.)

[0] I know about variables & data import in InDesign, that is still dependent on GUI so not quite applicable.

Re: PEP – An open source PDF editor for Mac

#74

Post by tgbugs »

tzs wrote: post #14
wolfium3 wrote: post #9

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.

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 +379dd864b16eaca3ce94c15a6bdfcc…

This solves the namespacing problem and allows creators and consumers to use different names if they want. Searching based on the creator's original name for a project becomes a mess because there will be a very large number of HelloWorld applications out there. Interestingly enough the google web store sort of already does this. The issue that comes up fairly quickly though is how to deal with the relationships between different packaged and published versions of what is nomalinally the same code base, or even forks/branches of the same code base. Maintaining a verifiable and discoverable chain for published artifacts without completely confusing users or exposing them to various malicious attacks (change a single byte in the middle of that random string and you have a nice off-by-one attack). Lots of infrastructure would be required to pull this off, but it would be great if it could be built.

Re: PEP – An open source PDF editor for Mac

#75

Post by d4mi3n »

wolfium3 wrote: post #9

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.

I usually solve this by giving the big G (or the big Duck) more info to work with in the query: https://duckduckgo.com/?q=pep+pdf+mac

Re: PEP – An open source PDF editor for Mac

#76

Post by awinder »

strogonoff wrote: post #73
awinder wrote: post #64

Earlier quoted context omitted.

How would your approach differ from something like RMarkdown or similar? Still trying to nail down the differentiation.

At first approach it seems to be substantially different from what RMarkdown is intended for, though maybe I am not seeing some outside-the-box ways of using it. What I would like is more oriented around creating documents according to particular layout specs. Documents (books, technical documentation) that can be created using InDesign, but this time programmatically[0]. As content should be authored using semantic…

I know nothing of InDesign so that's likely where my problem understanding came in :). At work, we have a lot of data-defined reports that will generate daily based on real-world conditions. These reports then go out to business users internally but they're nicely done because they'll occasionally get shared with external audiences. The way the team structured it, which I thought was fairly slick, is they built a bunch of RMarkdown reports that output to LaTex as an intermediary format. Then there's custom LaTex stuff in the pipeline that makes layouts & styling transferable and sharable between the reports. From LaTeX you can go to a number of outputs like html and pdf and it's (I'll probably catch flack for laypersons explanation) maybe a more print-oriented layout/typesetting system, versus html/css which came later. This felt maybe more relevant before than now :)

Re: PEP – An open source PDF editor for Mac

#77

Post by Lammy »

tkfu wrote: post #31
strogonoff wrote: post #20

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…

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

Check out HexaPDF too, also in Ruby: https://github.com/gettalong/hexapdf

Re: PEP – An open source PDF editor for Mac

#78

Post by fiddlerwoaroof »

wtetzner wrote: post #23
MaxBarraclough wrote: post #16

Earlier quoted context omitted.

> 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.

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).

That’s not a problem, you just add a meta or a link tag that points to “the” url for your project (maybe og:app-id Or a link with rel=“app”)

Re: PEP – An open source PDF editor for Mac

#79

Post by 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...

and it seems to be one of the main actors in what are termed "polyglot" files: https://truepolyglot.hackade.org/ (of which my favorite is: 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. )

Re: PEP – An open source PDF editor for Mac

#80

Post by armadsen »

prewett wrote: post #71
pier25 wrote: post #56

Earlier quoted context omitted.

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

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…

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.

Post reply on HN