I recently researched and discovered my own PHP solution to achieve this with FOSS. The FPDI PHP class can be used to import a PDF document for use with TCPDF or FPDF PHP classes, both of which provide functionality for creating, reading, updating, and writing PDF documents. Personally, I prefer TCPDF because it provides a wider range of functions ( TCPDF vs FPDF ), a richer API ( TCPDF vs FPDF ), more usage examples ( TCPDF vs FPDF ) and a more active community forum ( TCPDF vs FPDF ).
Select one of the previous classes or another to programmatically process PDF documents. Focusing on both current and possible future results, as well as on the desired user experience, decide where (for example, the server is PHP, the client is JavaScript, and both) and to what extent (using the function) your interactive logic must be implemented.
Personally, I would like to use a TCPDF instance obtained by importing a PDF document via FPDI to iteratively validate, translate to a common format (XML, JSON, etc.) and store the resulting view in relational tables designed to store data related to desired level of hierarchy of documents and details. The necessary level of detail is often dictated by a specification document and its mention of both current and possible future results.
Note. . In this case, I highly recommend translating documents and storing them in a common format to create a layer of abstraction and transparency. For example, a possible and unanticipated future achievement may be to provide the same functionality for users who download Microsoft Word documents. If the downloaded Microsoft Word document was not translated and saved in a common format, then you will almost certainly need to update the web service API and the dependent business logic. This ultimately leads to the storage of inflated, suboptimal data and inefficient use of development resources in the development, development and support of several translators. It would also be inefficient to use server resources to translate outgoing data for each request, in contrast to translating incoming data into the optimal format only once.
Then I expanded the tables of the base document by developing and linking additional tables for persisting data about specific document resources, such as:
Supported Versions / Editing / Deleting
- what
- Page header
- Text
- Picture
- Page (one, many or all)
- Location (relative - text anchor, absolute x / y coordinates)
- File (relative or absolute directory or URL)
- Brush (drawing)
- Page (one, many or all)
- Location (relative - text anchor, absolute x / y coordinates)
- Form (x / y coordinates for redrawing a line, square, circle, user, etc.).
- Type (pen, pencil, marker, etc.)
- Weight (1px, 3px, 5px, etc.)
- Color
- annotation
- Page
- Location (relative - text anchor, absolute x / y coordinates)
- Shape (line, square, circle, custom, etc.)
- Value (annotation text)
- A comment
- Purpose (page, other text / image / brush / annotation object, parent comment - streams)
- Value (comment text)
- When
- Who
After some, all or more of the document and its resource data are saved, I would develop, document and develop the PHP web service API to expose the CRUD and PDF document loading functionality for the user user interface, business regulations. At the moment, the remaining work is now on the client side. Currently, I have relational tables that store both the document and its resource data, as well as an API that demonstrates sufficient functionality for the consumer, in this case, client-side JavaScript.
Now I can develop and develop a client application using the latest web technologies such as HTML5, JavaScript and CSS3. I can download and request PDF documents using the web service API and easily output the returned generic format to the browser, but I decide (maybe HTML in this case). Then I can use 100% native JavaScript and / or third-party libraries for DOM functionality, creating vector graphics to provide drawing and annotation functions, as well as access and control the functional and stylistic attributes of the currently selected text and / or image of the document. I can provide real-time shared experience using WebSockets (before the mentioned WebService API is not applied) or a semi-delayed, but still fairly simple experience using XMLHttpRequest.
From now on, the sky is the limit, and the ball is in your court!