Created attachment 123749 [details] attachment-28476-0.html Version: 0.11.2 (using KDE 4.5.5) OS: Linux I downloaded a pdf file with text forms. I filled it with arabic text then I tried to print it. Unfortunately the Arabic text didn't show in the output. Reproducible: Always Steps to Reproduce: 1- download this simple form: http://www.omanet.om/arabic/press/9.pdf 2- filled with a random arabic text like: السلام عليكم 3- try to print it.
Correct, at least newer Okular versions will warn you that this file has XFA forms and that they are not supported.
*** Bug 236302 has been marked as a duplicate of this bug. ***
Not being able to properly process XFA forms forces me to reboot into windows again and use Adobe Reader. So I consider this a vital issue not only for Okular, but for Linux as a whole. So implementing XFA support should be highly prioritized.
FWIW, there's not much we can do here. Support needs to be added to poppler, which is tracked with https://bugs.freedesktop.org/show_bug.cgi?id=14265
I believe this should not be marked as resolved until this feature is implemented in poppler, and Okular supports it. Lots of passport/government applications require one to fill up XFA forms.
Bug trackers track actionable work. If 100% of the required work is in Poppler such that Okular will gain the feature for free, then there is no work required in Okular and hence this bug report does not track anything and should be closed. If on the other hand Okular will need some work to adopt the feature once it's implemented in Poppler, then it's appropriate to keep this bug open to track that work. I suppose technically once XFA support is added to Poppler, at the minimum we'll need to remove the banner that warns you that XFA forms are unsupported, so we can keep this open to track that. But to reiterate, the bulk of the work needs to be done in Poppler, not in Okular.
*** Bug 299816 has been marked as a duplicate of this bug. ***
*** Bug 413852 has been marked as a duplicate of this bug. ***
Just a reality check, XFA forms are 99.98% never going to be supported unless you come by a few hundred thousands euros. XFA is also deprecated in PDF 2.0 so whoever is giving you those kind of files, you should tell them to stop producing them.
Regarding your "reality check" does the support depend on this money due to some technical resource cost or for you to consider supporting it. Telling government agencies to regenerate millions of forms in a new format is like asking all of kde to switch to meson overnight when it adds very little to the end product beyond being a newer build system. Asking them to stop producing them also doesn't eliminate old/legacy docs. I am not trying to be critical of anyone but I have never seen an explanation on why this is a problem and it isn't very fair that when someone Google's the "XFA forms are not supported" error they end up here with no explanation other than "ask poppler to support it and then we can" and now "it'll cost money" but no mention of why. On November 5, 2019, at 16:10, Albert Astals Cid <bugzilla_noreply@kde.org> wrote: Comment # 9 on bug 263042 from Albert Astals Cid Just a reality check, XFA forms are 99.98% never going to be supported unless you come by a few hundred thousands euros. XFA is also deprecated in PDF 2.0 so whoever is giving you those kind of files, you should tell them to stop producing them. You are receiving this mail because: You voted for the bug.
The pdf spec is 1000 pages, the XFA spec is 1600 pages.
Thank you Albert that clarifies things for me and most likely others that look back on this. On Wed, Nov 6, 2019 at 7:10 AM Albert Astals Cid <bugzilla_noreply@kde.org> wrote: > *Comment # 11 <https://bugs.kde.org/show_bug.cgi?id=263042#c11> on bug > 263042 <https://bugs.kde.org/show_bug.cgi?id=263042> from Albert Astals Cid > <aacid@kde.org> * > > The pdf spec is 1000 pages, the XFA spec is 1600 pages. > > ------------------------------ > You are receiving this mail because: > > - You voted for the bug. > >
Created attachment 123750 [details] attachment-32018-0.html
After Albert explanation, I don't see a reason this bug should be open here. Actually after knowing that 1. It's now deprecated officially 2. It's an 1600 pp of proprietary format I would go and close my bug at poppler too, https://gitlab.freedesktop.org/poppler/poppler/issues/364 It wasn't deprecated officially when I filed mine. Even if there is enough money and resources we shouldn't bring the dead to life again. Let it die with peace for free.
Sounds good to me. :)
IMHO it's fine to close this here, as it was before, if it belongs to poppler. But let's not pretend that we can snap our fingers and all the "deprecated" forms and their users (often slow moving enteriprises and, more important for everyday life, hovernment institutions). We shouldn't act like the CUPS project, which is deprecating the old PPD format, condemning a lot of hardware (which is supposed to last for long time) to obsolescence. For sure it would take a lot of money to implement this format and its support is not probably going to happen, but that does not mean that it wouldn't be useful and that it must die just because it's old.
I wonder if it is feasible to aim for some form of partial support? A lot would be gained already if poppler were simply able to render the text on a page, without any fancyness or even interactivity.
There's non-Free apps on Linux that let you work with XFA files if you really really need to, use your favourite search engine to find them.
(In reply to Albert Astals Cid from comment #18) > There's non-Free apps on Linux that let you work with XFA files if you > really really need to, use your favourite search engine to find them. And PDFium, which is used e.g. by Chromium, has some support for XFA. When I looked at this a while ago (probably about two years ago) and tested a few files, that turned out not to be far from ideal, but that *might* have changed in the meantime. (Back then, XFA support was not enabled by default, but there was a compile option).
*** Bug 416081 has been marked as a duplicate of this bug. ***
*** Bug 423846 has been marked as a duplicate of this bug. ***
*** Bug 425030 has been marked as a duplicate of this bug. ***
in contrast to okular, evince seems to support xfa. How did they do that if it is so complicated?
Please can you attach such a pdf with XFA forms that works in evince and not in Okular?
Created attachment 130675 [details] some official pfd with xfa forms which can be opened in evince. The headline says all.
(In reply to Reissner from comment #25) > Created attachment 130675 [details] > some official pfd with xfa forms which can be opened in evince. > > The headline says all. It can also be opened with Okular
hm.... but okular gives a warning.. at least in my version.
http://mca.gov.in/MinistryV2/companyformsdownload.html#compl check this link please. This website is india government companies registrar and ALL documents are xfa pdf files which run on adobe reader. https://www.quora.com/How-many-companies-are-there-in-India?share=1 according to this, around 1.2 million companies are registered in india. that means at least 1.2 million people who are involved with the affairs of these companies need adobe reader and by extension, windows. i have tried to open these files on okular and evince and mupdf i think but none works. Do you know how much corporate acceptance open source software would get in a place like india with something as common as being able to file pdf files on a linux install.
*** Bug 443472 has been marked as a duplicate of this bug. ***
(In reply to 2wxsy58236r3 from comment #29) > *** Bug 443472 has been marked as a duplicate of this bug. *** OK. I ask once more here: Is it possible to use XFA viewer from Firefox 93 (or its principle etc.) in Okular? See https://hacks.mozilla.org/2021/10/implementing-form-filling-and-accessibility-in-the-firefox-pdf-viewer/ etc. Thank you.
HTH someone... I just filed a bunch of forms with the US Gov't which makes extensive use of XFA; so we can't expect XFA to disappear anytime soon. What I tried on various forms, including https://www.uscis.gov/sites/default/files/document/forms/n-400.pdf okular: waste of time even trying evince: some support; but useless. Some issues: - only first page allows input into ID number fields at top of each page - input fields to the right of checkboxes don't work xournal: painful; but only viable solution I've found short of using a pen. - type, select, move into correct position - adjust font in some cases ("123456" vs "1","2","3","4","5","6") - no "align" feature Tip: examine entire form for repeat/similar fields and use copy/paste/align on such fields to save much time. xournalpp: found this moments ago. Lots of new features. Some preferences imply this is still work in progress; but nothing new that would have made it any better/easier than xournal for this form. oodraw: does not render the raw form correctly. Any other options?
(In reply to pf from comment #31) > Any other options? Foxit Reader for Linux
Adding to comment 31 masterpdfeditor5 https://code-industry.net/free-pdf-editor/ - only first page allows input into ID number fields at top of each page - some fields appear to be inactive dropdowns and don't allow input Not worth checking further.
(In reply to Yuri Chornoivan from comment #32) > (In reply to pf from comment #31) > > Any other options? > > Foxit Reader for Linux Thanks, but same issues as with masterpdfeditor5 (comment 33); so xournal or xournalpp are still the only somewhat workable options for US(other?) gov't forms which are not likely to eliminate XFA in foreseeable future. HTH
(In reply to pf from comment #31) An option is to use Firefox 93 (which now supports XFA [1]). However, for the test file [2]: - Textboxes and checkboxes are working - Dropdowns are not working [1] https://www.mozilla.org/en-US/firefox/93.0/releasenotes/ [2] https://www.uscis.gov/sites/default/files/document/forms/n-400.pdf
Altough PDF standard deprecates this feature, it is too widely used to not provide a solution for it ! Also, it will take a looong time before official documents will be edited with other, more recent, standard. I voted in favor of an implementation ...
*** Bug 453951 has been marked as a duplicate of this bug. ***