FreeBSD Equivalent To Adobe Acrobat

Polytropon freebsd at
Wed Jul 12 14:52:28 UTC 2017

On Wed, 12 Jul 2017 09:04:59 +0000, Carmel NY wrote:
> On Wed, 12 Jul 2017 00:45:56 +0200, Polytropon stated:
> >On Thu, 6 Jul 2017 12:57:02 +0930, Shane Ambler wrote:
> >> On 04/07/2017 10:02, B J wrote:
> >>   
> >> > I tried several and those you mentioned might have been among them.
> >> > None of them appeared to fill in blanks, assuming, of course, I did
> >> > things right in the first place.  For each one, I would get a
> >> > message, embedded in the file I was looking at, which said
> >> > something about me having to use Acrobat.  
> >> 
> >> Could depend on the specific pdf file, pdfs can have some adobe only 
> >> features such as XFA and javascript, as these aren't part of the 
> >> official spec I expect they aren't supported in free software.  
> >
> >At least XFA seems to be supported by Okular, but normal forms
> >(text input fields) are supported by Evince and Okular; gv and
> >xpdf do not support them, but usually can read and print the
> >forms (with blank fields of course).
> The OP wanted the ability to edit; in his case "fill in the blanks, in
> a PDF document. How does printing a document with blanks achieve this
> goal?

It doesn't, and I didn't claim it did. You know I'm not a native
speaker, but it should be clear. The core message is that both
gv and xpdf are able to open the file, instead of reporting an
error, crashing, or displaying nonsense. This illustrates as well
that it is at least _possible_ to create PDF files with forms
that can be used in both ways: for filling using the PDF viewer
(and saving the result), and for printing the form and filling
the fields in a "pen & paper" manner.

In this case, a file with text fields was provided for testing.
Both Okular and Evince work for this case. Problem solved. :-)

> >So the "Acrobat Reader" or whatever it is called this year is
> >not really needed anymore, except you get really non-standard
> >PDF files that require special proprietary commercial software.
> >I haven't tried to get the "Windows" version of the mentioned
> >reader running with wine, maybe that is possible for such kinds
> >of "worst case PDF file"... ;-)
> It is called, "Acrobat Adobe Pro DC". By the way, what is a
> "non-standard" PDF file anyway. I have never run into one.

Thanks for the clarification. I usually don't track the naming
conventions of all imaginable kinds of software and their
changes through time, but I will try to remember that one,
until the next name change. :-)

I usually understand the term "non-standard PDF" as a PDF file
that contains extensions which are not part of the commonly
available implementations of PDF processors. Those might be
very special cases from one of the standards as well as a
proprietary extension of a standard which only a specific
program understands (and implements as intended). For all
other PDF processors, such extensions will cause problems,
such as incorrect rendering, or no renering at all, or in
best case, just missing functionality.

In the case of xpdf and gv, those simply don't implement editing
capabilities for forms. But forms is not the only thing, there
is also scripting and "logic" within PDF files that require
a more advanced PDF processor to be used.

> By the way, are you aware that there are 8 recognized PDF standards.

Yes, that is sort of a problem... and I've actually dealt with
a few of them (especially PDF/E, PDF/X, and PDF HC).

> There is simply no other software application that I am aware of that
> offers the ease and efficentcy of working with all the various PDF
> types like Adobe's latest PDF reader/editor.

In many settings I was working in, several Adobe products were
used in combination, mostly on Mac OS X, fill in current naming
here. ;-)

So "within that industry", exchange never was a real problem,
and with the introduction of Linux desktops, at least opening
and working with files became easy due to tools like Evince and
Okular. It all depends on the complexity of the tasks you want
to solve, where a PDF file is the end product. Luckily, you can
choose your tools depending on the task... well... at least in
most environments you can... ;-)


The ability to at least print a PDF file with text fields is
quite welcome when the creator of the file delivered a defective
product. I have seen such crap more than often, built by corporate
as well as by government, where the file opens, and you are supposed
to fill the blanks, but the fields are set to "inactive", or they
are located outside of the document (no idea how they got it
that way), or where you cannot print the result because printing
has been deactivated, or where you cannot save your inputs. In
such cases, customers were happy that they could print the whole
form, fill in the information with a pen, made a copy for their
own filing purposes, and sent the original (printed and filled)
sheets to the organisation that requested (or demanded) it. The
ability to do so saved a lot of time. Have you tried calling a
governmental agency or a corporate entity and telling them that
their PDF files are shit and cannot be worked with as they tell
you to? "But we are ISO-9660 certified!" Good luck.

Again: Problem solved. :-)

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

More information about the freebsd-questions mailing list