Description: LO Writer produces and exports excellent pdf forms. However, it is not possible to multiply two fields in a row and place the answer in a third field, or to add and subtract fields in a column of cells. I would like to: 1) multiply two fields in a row. For example: item x quantity -> cost 2) add several fields in a column into a sub total. Currently, I produce forms in LO, but then use Scribus to add simple arithmetic. Unfortunately, Scribus only does multiplication and adding, before javascript has to be used. If LO could make this capability available, it would be a serious contender for fillable forms. I know from my efforts with Firefox, Chromium, Okular, Foxit and the Document Viewer in Linux Mint that consistent behaviour is a nightmare. Actual Results: Add fields to writer document. Set format of fields - number, integer, real, currency and currency symbol. Create arithmetic links between them, with output in another field. Export to pd for fdf. Expected Results: Exported form will work in Firefox, Chromium, Okular, Foxit, Acrobat Reader, etc. Reproducible: Couldn't Reproduce User Profile Reset: No Additional Info: I do not understand. This is a feature request.
Can you please provide a Scribus-made form doing simple arithmetics without javascript?
Created attachment 190326 [details] Files to produce working fillable pdf form. Open zip file, which contains the route to create a working fillable pdf with addition and multiplication. Scribus cannot do subtraction and multiplication, without user generated javascript. I suspect that there is embedded javascript in the fully working pdf.
(In reply to Mike Sapsard from comment #2) The ODT in your file does not do any arithmetics. So are you asking for "translate to PDF what is already working in ODT", or are you asking for something else?
Although LO can do arithmetic in Base and Calc forms, this cannot be exported to pdf for a standalone fillable form. I would like to be able to create a fillable pdf form with arithmetic, in Write, that can be sent out to other people to fill in. In the files that I sent, LO exported Demo_Arithmetic.pdf from Demo_Arithmetic.odt. Scribus then imported Demo_Arithmetic.pdf and translated it to its own format - Demo_Arithmetic.sla. I was then able to add the arithmetic using a simple window with click to select functions to add the arithmetic. The file was then exported again as Demo_Arithmetic_from_Scribus.pdf. So, the first pdf file contains no arithmetic, and the second one does.
Created attachment 190333 [details] Scribus interface for arithmetic This is a screenshot of the Scribus interface for adding the capabilty. I believe that it must use javascript underneath. Unfortunately, it does not allow anything more than addition or multiplication of fields.
This has been brought up on ask.LO before: - https://ask.libreoffice.org/t/dynamic-pdf-fields/96101/4 - https://ask.libreoffice.org/t/math-calculations-in-pdf-forms/12208/4 I understand comment 4 to be the current workaround "recipe" to use a layout created in LibreOffice, export as PDF, open it in Scribus to then add the calculated fields (which uses JavaScript) and export again to PDF. Adobe Acrobat (Pro and Sign as far as I can tell) also allows creating those too. So I guess the enhancement request is twofold: - support calculated fields in a form created with Writer document (is there anything in ODF for that?) - support their export as PDF (In reply to Mike Sapsard from comment #4) > Although LO can do arithmetic in Base and Calc forms, this cannot be > exported to pdf for a standalone fillable form. Any chance you could also attach an example Calc file that has such form controls?
IMO: 1. There is no built-in means to do calculations in form fields in LibreOffice, other than writing own macros. LibreOffice *must not* put into PDFs anything absent in the source document itself, so any document with simple form fields (but without macros) must never obtain any scripting capability on export - because LibreOffice is not a PDF authoring tool, but its PDF export is designed to just store the document in another format, as is. 2. Even if there is a macro in the document, it is not a LibreOffice task to serve as a AI to convert *programs* from one programming language (say, Basic) and one document model (namely, LibreOffice/UNO document model) into another language (JavaScript) and another document model (PDF API). Not only the two document models are completely different; not only the correct automatic translation of this kind is yet impossible even for most sophisticated AI available currently. It is also a new security risk, which mitigation would be put on TDF. And then, it would still rely on an implementation of this API in other PDF viewers, giving raise to bugs like "your PDF doesn't calculate in Reader X"... WONTFIX IMO. Ref: https://opensource.adobe.com/dc-acrobat-sdk-docs/acrobatsdk/pdfs/acrobatsdk_jsapiref.pdf https://helpx.adobe.com/acrobat/using/javascripts-pdfs-security-risk.html
Dear Mike Sapsard, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping