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

The Editable PDF Initiative

editablepdf.org

Post reply on HN
Print view View original

51–60 of 162 posts

Re: The Editable PDF Initiative

#51

Post by calvinmorrison »

9nGQluzmnq3M wrote: post #43

I'm going to add an unsolicited plug for PDFEscape, which effectively lets you "edit" any PDF: https://www.pdfescape.com/ It's an online service that lets you upload PDFs, then edit fields, add text, upload and paste images like your signature, etc. Perfect for filling out tedious paper application forms without having to deal with printing & scanning. I have no connection other than as a satisfied user, and in fact…

SO to apples PDF veiwer. I don't own a Mac but I use my coworkers. Take a paper write your signature, then the webcam will scan, de crust and add your signature on a doc!

Re: The Editable PDF Initiative

#52

Post by burtonator »

The fact that PDF is immutable is a huge advantage.

In Polar we have taken the perspective that immutability is an advantage and is going to be the basis for our group collaboration around documents.

We ended up building out annotations on top of PDF including text highlights and area highlights which can then be commented on:

https://getpolarized.io/docs/annotation-sidebar.html

Some of our users keep asking for editable documentation and I think the main win here could just be using markdown which I'm thinking about adding.

The biggest thing that's needed though, for scientific use, is latex. Fortunately, there are plenty of markdown implementations with latex support.

PDF is amazingly good for printing documents but honestly 90% of the complex printing requirements aren't needed for regular use.

Re: The Editable PDF Initiative

#54

Post by jolmg »

e1ven wrote: post #38
Ididntdothis wrote: post #20

Earlier quoted context omitted.

Problem is that PDF does not preserve content in a machine readable format. It’s a one way street. Once converted to PDF you can’t convert to another format without losing a lot of content and formatting.

That's exactly what I like about it. My ideal PDF is essentially a PNG file with selectable/searchable text. It's a great WORM format. Every added feature makes it worse.

Why is it desireable for it to not be machine readable? What could possibly be the advantage in that?

Re: The Editable PDF Initiative

#55

Post by jolmg »

microcolonel wrote: post #22
jolmg wrote: post #5

Earlier quoted context omitted.

What's a better format for displaying and printing documents consistently and with selectable text? > It doesn’t adapt to screen sizes That is a feature. I expect my PDFs to display with pixel-perfect consistency everywhere. There are other formats that adapt to screen sizes. HTML is good for that, if we ignore how people break that with styling.

The claim that text is selectable in PDFs is often dubious.

Well, I meant that the format supports it. I merely mentioned it so nobody would reply with something like PNG.

Re: The Editable PDF Initiative

#56

Post by diegof79 »

Adobe Illustrator files (.ai) are PDF compatible files, so you can view them with a PDF reader like preview. The file still contains all the data to be edited in AI. I guess it means that PDF format is already designed to hold extra data that can be used for editing. But since pdf has many use cases, I don’t think that it will change much for editing. You still need a tool compatible with the original editor. However it will be interesting if docx like ai files could be displayed in a pdf viewer, it will save a lot of time dedicated to export/save as pdf.

Re: The Editable PDF Initiative

#57

Post by piadodjanho »

The PDF file format is anachronous.

When the format was created, computers only had a few KBs of RAM. Yet the format should be capable of editing documents with thousand of pages. The format solves this issue by delegating the memory management to the user.

Also, the file was made with the assumption it was suppose to be printed, not shared. It is easier to hide parts of the document instead of removing the data.

A funny trivia. The PDF is suppose to be read from the end of file. That's why some documents need to fully downloaded before they can display the first page. Of course, nowadays most PDF are linearized and load, at least, the first page right away.

Over the years specification got so complex it became very hard to implement a minimal editor, viewer, parser or generator. If the format was simpler, it would be possible to make "save as PDF" more accessible.

I've other issues with the typesetting and the way color is handled (it has a printer first approach), but I think this post got too long already. I just want to point out the spec supports so many pointless features such drawing in 3D space, movies, audio, HTML support, etc.

Finally, I don't understand why most people are against a revision on the PDF format despite clearly having very little knowledge on how it works. I think multi person edition of the same entry with some version control can be useful. By the way, the format kinda let many people edit the document at once, as long as they are not working in the same part.

Re: The Editable PDF Initiative

#58

Post by e1ven »

jolmg wrote: post #54
e1ven wrote: post #38

Earlier quoted context omitted.

That's exactly what I like about it. My ideal PDF is essentially a PNG file with selectable/searchable text. It's a great WORM format. Every added feature makes it worse.

Why is it desireable for it to not be machine readable? What could possibly be the advantage in that?

Because I don't want anything to try to reflow the text, or adjust the kerning, or modify to use system fonts.

There are great systems for those already.

When I want a PDF, it's because I want a format that I know is always going to look the same.

A PDF is a great archive format. It's perfect for a scan of a document, or a printout.

I never want my viewer to add anything to it, I never want it to detect anything, I never want it to adjust anything.

Just render it exactly the same way, every time.

Re: The Editable PDF Initiative

#59

Post by kccqzy »

klint wrote: post #44
kccqzy wrote: post #36

Meh. Not being easily editable is a feature, not a bug. Sometimes you want to send out a finalized document and want to make 99% of the users unable to edit them. That's what PDFs are for. Imagine lawyers needing to send out a finalized contract. Or a graphic designer sending out the finalized design. Or an electronic book that has gone through the work of the author, the editor, and the publisher and needs no more c…

That objection, and others, are addressed in the project FAQ[1]. It's already possible to open and edit a PDF in various applications. [1] https://editablepdf.org/faq/ >But isn’t the whole point of PDF that you can’t edit it? No. The fact that standard PDFs are difficult to edit is more of an accident than a feature, as PDF’s roots are in printing, where only final-form documents needed to be transmitted. Many people…

The FAQ explains things well: making minor changes, although difficult is still possible. I have even personally changed multiple PDFs; I find qpdf to be a great tool for that. But making changes large enough to require reflowing the text is almost impossible.

I do not consider my objection addressed. If anything, that FAQ further emphasized the current difficulty of editing PDFs and they are only proposing to make things easier. So no one is really objecting to the fact that currently changing PDFs is hard. Whether or not that is desirable though, is a separate matter, one that the FAQ does a poor job explaining.

Re: The Editable PDF Initiative

#60

Post by kccqzy »

piadodjanho wrote: post #57

The PDF file format is anachronous. When the format was created, computers only had a few KBs of RAM. Yet the format should be capable of editing documents with thousand of pages. The format solves this issue by delegating the memory management to the user. Also, the file was made with the assumption it was suppose to be printed, not shared. It is easier to hide parts of the document instead of removing the data. A f…

> When the format was created, computers only had a few KBs of RAM. Yet the format should be capable of editing documents with thousand of pages. The format solves this issue by delegating the memory management to the user.

That's a good decision. Make the file format versatile and powerful. Don't constrain it by the limitations of contemporary hardware.

> Also, the file was made with the assumption it was supposed to be printed, not shared. It is easier to hide parts of the document instead of removing the data.

I agree it's made with the assumption of being printed, but that's part of the appeal—preserving visual fidelity of how the document looks. You can't send people a docx and expect them to see the exact same thing on their screen down to every detail.

And no it's not difficult to remove data. If you know exactly what to remove, it is quite easy to remove things. To remove text, find the Tj or TJ operators, remove them and their arguments. To remove an image, find the Do operator (occasionally BI, ID, EI) and remove it. You might have to perform decompression before doing that. For images, you might have to run another pass to delete the referenced object. But all these are all very easily automated.

> Over the years specification got so complex it became very hard to implement a minimal editor, viewer, parser or generator. If the format was simpler, it would be possible to make "save as PDF" more accessible.

The reason "save to PDF" is difficult to implement from scratch is not because of its complicated specification. Indeed parsers are quite easy to write. The real reason "save to PDF" is difficult to implement is because PDF wants visual fidelity; that comes at the price of specifying where exactly text should be placed, all the way from how paragraphs are flowed to how kerning of the letter is to be handled. Most applications do not care about these details. Most developers hardly have any interest in understanding line-breaking algorithms or interpreting font files to produce the right offsets and glyphs (think ligatures). These things are, rightfully, way beyond the business domain of typical applications and beyond the knowledge of typical developers.

Post reply on HN