Read/Write PDF

[cy...]

if only LabVIEW can read and write PDF files, since it is already an open format. needless to say for the function of writing in report generation, but reading from PDF can also provide: text, picture or even CAD data that can then be used from automated mass data entry, QC vision inspection (CAD vs fabricated), augmented reality visualization of measurements (temperature, stress, vibration, etc) and much more...

if only...

[wiebe@CARYA]

The PDF format is open, but there's no specified way to build a PDF document. The PDF format is for correctly displaying text and graphics, not for word processing.

This makes it really hard to read PDF documents consistently.

Consistently and reliably being able to modify PDFs would be even harder.

Writing PDFs is possible with several (LabVIEW) toolkits. I made one from scratch, so I do know a thing or two about the PDF specification...

IMHO, These kind of tasks belong in add-ons, not in LabVIEW.

[cy...]

for read, populating the references, properties and value (with read/write access) is sufficient, let the user sort out formatting and other issues by themselves

for write, values can be updated directly using names if it is a form, or from a reference map populated from the read. although this could be worked around perhaps using RGT or office invoke, would not be as easy for end-users as allowing end-users to managed their own reports/forms

not suggesting a full suite of functions and features similar to that of other software, but an out-of-the-box distributable starting point at least. the additional value-adding add-on can come from the community thereafter

*I am speaking from the POV of working on source code involving other external parties, where add-ins can become a problem; currently dealing with vision involving picture pdfs

[wiebe@CARYA]

>not suggesting a full suite of functions and features similar to that of other software, but an out-of-the-box distributable starting point at least. the additional value-adding add-on can come from the community thereafter

Even a starting point would be a hell of a job. It would only work under the right conditions at best.

PDFs are very, very difficult. E.g. finding a text seems simple, but even after parsing and deflating the streams, the text doesn't need to be in the stream. After all, several encodings can be used, and the encoding to an embedded font subset could really be anything a PDF generator choose to use.

Same goes for character positioning. Nothing is stopping a generator to add text from right to left, or completely random. Obviously, formatting text can completely mess up the stream text.

Good news is, I do have this starting point.

I have (primitive) PDF reading functions for testing my PDF generation. All the above became very clear, and then some.

>*I am speaking from the POV of working on source code involving other external parties, where add-ins can become a problem; currently dealing with vision involving picture pdfs

The use case is clear. I got this question a lot over the years.

For a user, this is a very good idea.

Forms could indeed be a way out. The main problem for me is that I have no idea how to use forms, from a workflow perspective. For instance, I don't have any way to create a form. Some for signing PDFs and a few other topics.

Note that PDF Forms are a different specification, complicating things, although there will be overlap. 

[cy...]

@wiebe, thanks for the input. no objections if it is an addon but a free and open one 😉 

I do not mean to read the text/data directly, but rather the populating the objects of its references, type, properties (name, value, etc) etc. user (as in LV user) can use property nodes to read/write as variants. some common encodings can be included as examples for starters.

some common methods such as save a copy, etc would also be nice, at the end for report generation purposes

currently, since my case is graphical, perhaps the workaround is "manipulate" the pdf as an image, how nice if there is a property node with its variant output being a 3D RGB array 😁

[cy...]

there are some benefits of having the starting point or core functions included, it can offer some degree of cohesion minimally; and unformatted text and raster image can be good reasons to have the core functions developed

other parties can offer additional value through chargeable addon with more advanced functions such as lossless conversion of the pdf RAW data to LV types (vice versa), processing, manipulation, etc. since the generator format varies with the software from different fields, independent field-dedicated team can maintain their own add-ons (vector graphic, CAD, etc), but all developed around the same core