[NTG-context] Re: form field issues
I apologize in advance for the length of the following explanation: I am certainly implicated by the positions taken to ban those who use AI from the ConTeXt discussion list, positions that are clearly based on a moral judgment—which does not (yet) apply to the use of washing machines, scooters, hair dryers, pizza selling machines, cell phones, computers, and other machines that run on electricity and would contribute (I use the conditional) “to the relief of the human condition.” (Lord Chancellor F. Bacon). I am coming to participate modestly in the debate, as I began to do. I completely agree with Pablo when he emphasizes the need to declare the use of AI when it is used. I did not do so (although I reread the summary produced by my questions to detect any inconsistencies) and I was wrong, even though my primary objective was not at all to propose an eternal truth that sprang from a brain other than my own, but to provide information, synthesized by a computing device. After all, we are entitled to consider AI as an additional tool about which everyone is free to have their own opinion, but which has a slight tendency, and certainly a flaw in some cases, to imitate human knowledge: in fact, I do not recommend asking AI to write a chapter of a book (on non-technical subjects), because the result is a set of platitudes that call into question the “I” in “AI”! But if a technical device can also assemble data and propose viable solutions, after verification, undoubtedly as quickly and in some cases much more efficiently than any other device, I don't see why we shouldn't examine it. There have been moral debates in certain circles about the uses of certain operating systems. If anyone here uses Windows as a platform for their work with ConTeXt (or for other purposes), or prefers an iMac, or a Fedora or Ubuntu-type platform, there is no reason to call for the immediate formation of resistance leagues against the hegemonic and abusive nature of such a system used preferentially and to proceed with a kind of “purge” (I write this word with trembling fingers on the keyboard, as it is a term that has been used in connection with terrifying actions). Nevertheless, the fear of AI, or more likely the generally skeptical and slightly fearful approach to what could become the structuring framework of human relations (and the dependence of human beings on all these calculation processes), makes me realize that the general exponential development of technology under the pressure of digitization makes us forget the now ancient nature of the lifestyle change caused by the use of electromagnetic energy. A German philosopher powerfully lamented the ravages in modern societies of “Zuhandenheit/Vorhandenheit” (In short, demanding immediate availability of whatever we believe we need; making just about everything available for consumption—this was the philosopher's criticism of the onslaught of modern technology.) As Hans so aptly puts it, who seems to me to be rather moderate and temperate at this early stage of the discussion, the question is not whether you used a screwdriver, an electric screwdriver, or called in a craftsman to install a camera in your garden, but why you did it. Hans doesn't use this example, but he points out too modestly that the key (as in any other field) is to remain as reasonable as possible. Especially since the use of various programming methods (via Perl, Python, Java, etc.) consists of different approaches aimed at “automating routines” that we don't want to have to do and redo over and over again by hand. There is something mechanically artificial about this—for example, using a Perl script on a very long text—which is not intelligent (neither “smart” nor ‘brilliant’), but “clever.” My opinion is that “tricks” (which are produced by “clever” minds) should be stored in the toolbox, and not at all in the library, however impressive they may be. Finally, I don't know if examining thousands of X-rays by a machine trained to detect tumors at an early stage allows a doctor to make a definitive diagnosis, or if it's a matter of fluctuating probabilities. In any case, I don't know whether I should file to suit in justice against this doctor and have him struck off the Association of Oncologists because he himself has not had the long experience of viewing thousands of X-rays. Similarly, what would we think of a restaurant chef who, after being awarded the medal for best chef in Belgium, admitted that the recipe that impressed the jury was suggested by ChatGPT — a recipe suggested by ChatGPT that he “would have adapted according to his own sensibility”? “He's a fraud!” might be one possible response. I don't know if the AI that examines the thousands of legal texts produced by the European administration is capable of giving legal advice that is “never” absurd. But it is possible that a team of lawyers could verify the conclusions
[NTG-context] Re: form field issues
On 12/18/2025 11:54 PM, vm via ntg-context wrote: Maybe this is the time to put a *complete ban* of any AI generated text postings to this forum now that we still can. Before you realize it you'll be wasting your time in replying to a machine who's sole purpose is to keep you distracted form your work. Anyone who gets caught ought to be banned, for ever. As this forum is for (real) people to share and exchange thoughts and information. One cannot really put a ban on this. We don't put as ban on other technologies either. It's more about not using ai the wrong way. The problem is that, as a tool, generative ml can have its use although it can interfere badly with creativity. So it's about using with care and I have confidence that users here take care it it. After all, we're not in a competitive space here (looking for the next typesetting hype every few years). Also, people will likely get bored about ai at some point and companies relying it it will fade away, as history shows us even large ones seldom survive that long. So, take a manual or an example snippet: one can use these tools to write (generate) one, but where does the content come from .. at some point one has to feed the system. Can you still call it your work and call yourself an author? I definitely don't want to end up in editing stuff that i could as well as written from scratch. The term author has th be recallibrated then. The same has always been true for programming: with the exception of science based algoritms beyond my imagination (think perlin noise) it's more efficient to just look atthe problem, think of a soluition and wrote one (at least for me) and then I don't care if I spend more time on it than someone else would. How would I know anyway. For the record: some time ago Frans G and I had good laught about his conversation with chat that ended up with funy mixups of context and latex syntax (commands, color specifications etc) but chat was very pleased about the positive feedback which was then not applied. He turned it into a MAPS article. How are users supposed to know the truth, that is the question. But also keep in mind that one can find rather weird *human* comments on ther web (like SE) on e.g. context from non-users that makes one wonder if they ever looked at it or are capable figuring out tex (beyond their narrow scope) at all. And those are indeed humans, maybe even considered experts. Part of the problem is that anyone can write / bash / complain / suggest anything these days and some actually could have benefit from cheecking-by-ai first. When I first ran into what was assumes ai, it actually was called 'expert systems' (prolog, lisp times) and as far as i understood experts were supposed to be involved, not web scrapers. So .. no ban needed as I'm not too worried here. Now back to extending manuals written in poor english, Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
On 12/18/25 22:54, Hans Hagen via ntg-context wrote:
> Just send whole files, not .diff as I want to use winmerge to visually
> compare.
Here you have my `lpdf-fld.lmt`.
Pablo
if not modules then modules = { } end modules ['lpdf-fld'] = {
version = 1.001,
comment = "companion to lpdf-ini.mkiv",
author= "Hans Hagen, PRAGMA-ADE, Hasselt NL",
copyright = "PRAGMA ADE / ConTeXt Development Team",
license = "see context related readme files"
}
-- TURN OFF: preferences -> forms -> highlight -> etc
-- The problem with widgets is that so far each version of acrobat has some
-- rendering problem. I tried to keep up with this but it makes no sense to do
so as
-- one cannot rely on the viewer not changing. Especially Btn fields are tricky
as
-- their appearences need to be synchronized in the case of children but e.g.
-- acrobat 10 does not retain the state and forces a check symbol. If you make a
-- file in acrobat then it has MK entries that seem to overload the already
present
-- appearance streams (they're probably only meant for printing) as it looks
like
-- the viewer has some fallback on (auto generated) MK behaviour built in. So
...
-- hard to test. Unfortunately not even the default appearance is generated.
This
-- will probably be solved at some point.
--
-- Also, for some reason the viewer does not always show custom appearances when
-- fields are being rolled over or clicked upon, and circles or checks pop up
when
-- you don't expect them. I fear that this kind of instability eventually will
kill
-- pdf forms. After all, the manual says: "individual annotation handlers may
ignore
-- this entry and provide their own appearances" and one might wonder what
-- 'individual' means here, but effectively this renders the whole concept of
-- appearances useless.
--
-- Okay, here is one observation. A pdf file contains objects and one might
consider
-- each one to be a static entity when read in. However, acrobat starts
rendering
-- and seems to manipulate (appearance streams) of objects in place (this is
visible
-- when the file is saved again). And, combined with some other caching and
hashing,
-- this might give side effects for shared objects. So, it seems that for some
cases
-- one can best be not too clever and not share but duplicate information. Of
course
-- this defeats the whole purpose of these objects. Of course I can be wrong.
--
-- A rarther weird side effect of the viewer is that the highlighting of fields
-- obscures values, unless you uses one of the BS variants, and this makes
custum
-- appearances rather useless as there is no way to control this apart from
changing
-- the viewer preferences. It could of course be a bug but it would be nice if
the
-- highlighting was at least transparent. I have no clue why the built in shapes
-- work ok (some xform based appearances are generated) while equally valid
other
-- xforms fail. It looks like acrobat appearances come on top (being refered to
in
-- the MK) while custom ones are behind the highlight rectangle. One can
disable the
-- "Show border hover color for fields" option in the preferences. If you load
-- java-imp-rhh this side effect gets disabled and you get what you expect (it
took
-- me a while to figure out this hack).
--
-- When highlighting is enabled, those default symbols flash up, so it looks
like we
-- have some inteference between this setting and custom appearances.
--
-- Anyhow, the NeedAppearances is really needed in order to get a rendering for
-- printing especially when highlighting (those colorfull foregrounds) is on.
local tostring, tonumber, next = tostring, tonumber, next
local gmatch, lower, format, formatters = string.gmatch, string.lower,
string.format, string.formatters
local lpegmatch = lpeg.match
local todimen = string.todimen
local sortedhash = table.sortedhash
local trace_fields = false trackers.register("backend.fields", function(v)
trace_fields = v end)
local report_fields = logs.reporter("backend","fields")
local context = context
local bpfactor = number.dimenfactors.bp
local references = structures.references
local settings_to_array = utilities.parsers.settings_to_array
local pdfbackend = backends.registered.pdf
local nodeinjections = pdfbackend.nodeinjections
local codeinjections = pdfbackend.codeinjections
local registrations = pdfbackend.registrations
local registeredsymbol= codeinjections.registeredsymbol
local lpdf= lpdf
local pdfstream = lpdf.stream
local pdfdictionary = lpdf.dictionary
local pdfarray= lpdf.array
local pdfreference= lpdf.reference
local pdfunicode = lpdf.unicode
local pdfstring = lpdf.string
local pdfconstant = lpdf.constant
local pdfaction = lpdf.action
local pdfflushobject = lpdf.flushobject
loc
[NTG-context] Re: form field issues
Maybe this is the time to put a *complete ban* of any AI generated text postings to this forum now that we still can. Before you realize it you'll be wasting your time in replying to a machine who's sole purpose is to keep you distracted form your work. Anyone who gets caught ought to be banned, for ever. As this forum is for (real) people to share and exchange thoughts and information. .F ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
The problem we all face (well, not all of us...) is that “digital technologies,” as they are called here, are presented as weapons of mass power. They give power (opening careers without digging with a pickaxe), verified sorting and decision-making (medical diagnosis after processing massive amounts of data), driving a car while watching a movie, digital processing at the speed of light for banks and more generally for accounting, and, as you say Hans, it is mainly used to serve the unquenchable desire to “make money.” But in general, just as typography is no longer done by hand with type cases, contractual exchanges must not be falsified, whereas digital technology (and by extension security algorithms) grants this power of imitation to anyone interested in the joys of digital technology. Yesterday as today, people need this trust that allows them to talk to each other and live together. We must nevertheless avoid digging too many dark caves in the warm and comfortable cave we already live in (for those who spend a lot of time snacking in front of the television or “chatting” on TikTok...) and remain vigilant in the face of the beautiful promises that the digital revolution and the bureaucrats in Brussels want to place under the Christmas tree. Happy Xmas ! Le 18/12/2025 à 22:52, Hans Hagen via ntg-context a écrit : On 12/18/2025 6:06 PM, Jean-Pierre Delange via ntg-context wrote: Unfortunately, I forgot to mention that my research consisted of reading a few pages on the Internet, notably these: 1.) https://helpx.adobe.com/ legal/esignatures/regulations/european-union.html; this one: https:// eidas.ec.europa.eu/efda/trust-services/browse/eidas/tls; 2.) this one: https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/ pages/467109076/What+is+the+legislation+-+eSignature; and this one: https://gregbur.me/2022/04/28/deep-dive-digitally-signing-pdfs-with- okular/. With these things one can just relax for a while. After all, we first have to see if the EU manages to set up the infrastructure itself without big tech. After all it needs trust. The dutch digi-id system was outsourced to some commercial entity that then was bought by some investor (UK, those often have a bad reputation here) that wo sels to another investor (USA, even worse reputation, esp because that gov can ask demands to everything). For me that basically removes trust in that system that we're supposed to use so we have to see how that plays out as much communication (country, province, city, public ornagizations) depend on it. It's very easy nowadays to end up in conspiracy landscapes so a signature system needs to be done right from the start. Adobe should not even be involved in that. It's good that at least it is done as 'europe' for folk like me. So we'll see hwo it goes. The best we can do is just handle it technically but usage / validity is then not something we have to worry about. It's after all just adding objects to a pdf (plus some encryption). I get the impression that there is less hurry than these pointed to documents suggest so no need to update overnight (during the xmas days). Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___ ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
On 12/18/2025 7:01 PM, Pablo Rodriguez via ntg-context wrote: On 12/18/25 16:14, Hans Hagen via ntg-context wrote: On 12/16/2025 5:01 PM, Pablo Rodriguez via ntg-context wrote: On 12/16/25 15:39, Hans Hagen via ntg-context wrote: i can have a look at the patch but can't test it Testing the patch and complaints are on me. ok, so i'll see what is coming once you're ready I have the first patch with two different dictionaries: a parent signature (with only entries for that field) and a widget child (with only entries for that annotation). I also removed `/NeedAppearances true` with a signature field (not only when already signed), as we had to do with signed documents. After discussing it with `poppler` developers, I think there may be another way of setting the parent and child dictionaries (which “Acrobat” doesn’t recognize). First I have to confirm this with the people from the Arlington project and if (and when) “Acrobat Reader” might improve it, we may have also an improved fix (but this will take some time). Just send whole files, not .diff as I want to use winmerge to visually compare. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
On 12/18/2025 6:06 PM, Jean-Pierre Delange via ntg-context wrote: Unfortunately, I forgot to mention that my research consisted of reading a few pages on the Internet, notably these: 1.) https://helpx.adobe.com/ legal/esignatures/regulations/european-union.html; this one: https:// eidas.ec.europa.eu/efda/trust-services/browse/eidas/tls; 2.) this one: https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/ pages/467109076/What+is+the+legislation+-+eSignature; and this one: https://gregbur.me/2022/04/28/deep-dive-digitally-signing-pdfs-with- okular/. With these things one can just relax for a while. After all, we first have to see if the EU manages to set up the infrastructure itself without big tech. After all it needs trust. The dutch digi-id system was outsourced to some commercial entity that then was bought by some investor (UK, those often have a bad reputation here) that wo sels to another investor (USA, even worse reputation, esp because that gov can ask demands to everything). For me that basically removes trust in that system that we're supposed to use so we have to see how that plays out as much communication (country, province, city, public ornagizations) depend on it. It's very easy nowadays to end up in conspiracy landscapes so a signature system needs to be done right from the start. Adobe should not even be involved in that. It's good that at least it is done as 'europe' for folk like me. So we'll see hwo it goes. The best we can do is just handle it technically but usage / validity is then not something we have to worry about. It's after all just adding objects to a pdf (plus some encryption). I get the impression that there is less hurry than these pointed to documents suggest so no need to update overnight (during the xmas days). Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
On 12/18/2025 7:45 PM, Pablo Rodriguez via ntg-context wrote: That being said, I’m afraid I think it shouldn’t be a problem finding disgusting AI-generated summaries (or texts, for that matter). I have never asked for AI-generated summaries, but as Hans mentioned, the only thing left for “Acrobat Reader” to display is “this text is long and you look incredibly stupid today, let me summarize it for you”. The problem with AI is that often the I seems more important than the A when discussing git (apart from a-morality of companies involved in it desired to dominate). It probably impresses / worries those who have never programmed a complex solution differently than someone who has (and has been around for a while). If one sees it as machine learning in some domain with some specific purpose, and if one combines looking at it with some understanding of how computers work it could be useful in places (helping recognizing things). If aggregated content helps some users e.g. with tex, fine, as long as oen doesn't shut off ones own brain. One can treat it as some clever search machine (although my impression is that searching the net got worse of it). Personally i never felt the need for using it, at least not as long as I have a functioning brain myself. A couple chat* tests were ion the one hand impressive, soon became boring esp when one starts recongizing errors and patterns. Actually I'd probably get bored fast if I had to rely on it (or worse: to be forces to use it in some job). But just don't underestimate what you already know, or an 'ask a human' or can find by simply searching, and then wrap up (helping understanding better) but when instead it comes from ai then be prepared to defend it as if it came from yourself as there is no one to refer to. (We had 'ask a human' as meeting theme for a reason.) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
Dear Pablo, I agree with your response to the misuse of AI as an arsenal of conformist answers when faced with the need to quickly produce discourse that appears to be similar to academic assertions. But I just wanted to raise the issue of electronic signatures “in general.” And I didn't know how personally involved you were in debugging “poppler” so that people who use PDF with Linux systems could have a reliable signature system. And I didn't know (I don't know a lot of things...) how Okular seems to be almost the only reliable way (for now) to do this kind of thing safely. Best//JP Le 18/12/2025 à 19:45, Pablo Rodriguez via ntg-context a écrit : On 12/18/25 18:06, Jean-Pierre Delange via ntg-context wrote: [...] My apologies if I have broken the unspoken rule of not citing my sources and, as a result, if I have offended anyone. Dear Jean-Pierre, I think as a general rule it is an excellent idea to cite all relevant sources (to give other people the opportunity to check if I’m missing something [or the whole point] there). My apologies for having reacted in such a poorly manner. If it helps to understand, I felt something like being fed a mechanical summary in something I had to learn by experience and some extra effort (dedicating much free time during months) to understand what was wrong and how it could be fixed. That being said, I’m afraid I think it shouldn’t be a problem finding disgusting AI-generated summaries (or texts, for that matter). I have never asked for AI-generated summaries, but as Hans mentioned, the only thing left for “Acrobat Reader” to display is “this text is long and you look incredibly stupid today, let me summarize it for you”. Since I have been exposed to that kind of “help” (AI-generated summaries sent to me), there are two main issues I have with all AI-generated text. Their accuracy is similar to be able to recognize a romanesque cauliflower (https://en.wikipedia.org/wiki/Romanesco_broccoli) only as as cauliflower (https://en.wikipedia.org/wiki/Cauliflower). I’m afraid I cannot avoid thinking they are way different vegetables. The verbosity and pompousness in these texts only matches their shallowness. In short, too much words for almost nothing at all. I also think that this kind of textual input decreases reading comprehension and text composition in humans. This is why I think AI-generated text should be avoided in written communication, or at least it should be warned about and marked as such. We are getting there in having `poppler` as reasonable PDF signing software, but the process is painfully slow (too much to do, very few people to do it). I hope it won’t take years to have relevant feature parity with signatures in “Acrobat Reader” (which I’m not a fan of, but it is a useful program in that regard). Best wishes, Pablo ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___ ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
On 12/18/25 18:06, Jean-Pierre Delange via ntg-context wrote: > [...] My apologies if I have broken the unspoken rule of not citing > my sources and, as a result, if I have offended anyone. Dear Jean-Pierre, I think as a general rule it is an excellent idea to cite all relevant sources (to give other people the opportunity to check if I’m missing something [or the whole point] there). My apologies for having reacted in such a poorly manner. If it helps to understand, I felt something like being fed a mechanical summary in something I had to learn by experience and some extra effort (dedicating much free time during months) to understand what was wrong and how it could be fixed. That being said, I’m afraid I think it shouldn’t be a problem finding disgusting AI-generated summaries (or texts, for that matter). I have never asked for AI-generated summaries, but as Hans mentioned, the only thing left for “Acrobat Reader” to display is “this text is long and you look incredibly stupid today, let me summarize it for you”. Since I have been exposed to that kind of “help” (AI-generated summaries sent to me), there are two main issues I have with all AI-generated text. Their accuracy is similar to be able to recognize a romanesque cauliflower (https://en.wikipedia.org/wiki/Romanesco_broccoli) only as as cauliflower (https://en.wikipedia.org/wiki/Cauliflower). I’m afraid I cannot avoid thinking they are way different vegetables. The verbosity and pompousness in these texts only matches their shallowness. In short, too much words for almost nothing at all. I also think that this kind of textual input decreases reading comprehension and text composition in humans. This is why I think AI-generated text should be avoided in written communication, or at least it should be warned about and marked as such. We are getting there in having `poppler` as reasonable PDF signing software, but the process is painfully slow (too much to do, very few people to do it). I hope it won’t take years to have relevant feature parity with signatures in “Acrobat Reader” (which I’m not a fan of, but it is a useful program in that regard). Best wishes, Pablo ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
On 12/18/25 16:14, Hans Hagen via ntg-context wrote:
> On 12/16/2025 5:01 PM, Pablo Rodriguez via ntg-context wrote:
>> On 12/16/25 15:39, Hans Hagen via ntg-context wrote:
>>> i can have a look at the patch but can't test it
>>
>> Testing the patch and complaints are on me.
>
> ok, so i'll see what is coming once you're ready
I have the first patch with two different dictionaries: a parent
signature (with only entries for that field) and a widget child (with
only entries for that annotation).
I also removed `/NeedAppearances true` with a signature field (not only
when already signed), as we had to do with signed documents.
After discussing it with `poppler` developers, I think there may be
another way of setting the parent and child dictionaries (which
“Acrobat” doesn’t recognize).
First I have to confirm this with the people from the Arlington project
and if (and when) “Acrobat Reader” might improve it, we may have also an
improved fix (but this will take some time).
Many thanks for your help,
Pablo
--- ofld.lmt 2025-12-18 17:47:51.922865345 +0100
+++ mkxl/lpdf-fld.lmt 2025-12-18 18:52:46.357419673 +0100
@@ -112,6 +112,7 @@
local pdf_no_rect = pdfarray { 0, 0, 0, 0 }
local signature = nil
+local signature_field = nil
local splitter = lpeg.splitat("=>")
@@ -936,6 +937,8 @@
end
if type == "signed" then
signature = true
+elseif type == "signature" then
+signature_field = true
end
end
for name, field in sortedhash(radios) do
@@ -955,10 +958,10 @@
}
if signature then
acroform.SigFlags = 3
-elseif pdfmajorversion() == 1 then
+elseif pdfmajorversion() == 1 and not signature_field then
acroform.NeedAppearances = true
else
--- depricated
+-- deprecated
end
if sometext or somefont then
checkpdfdocencoding()
@@ -1120,22 +1123,23 @@
-- copy of line ... probably also needs a /Lock
local function makesignatureparent(field,specification)
-local text = pdfunicode(field.default)
-local length = tonumber(specification.length or 0) or 0
-local value = lpdf.registersignature(field.values)
+ -- local text = pdfunicode(field.default) -- not really needed here
+ -- local length = tonumber(specification.length or 0) or 0 -- not really needed here
+ -- local value = lpdf.registersignature(field.values) -- not really needed here
local d = pdfdictionary {
-Subtype = pdf_widget,
+ -- Subtype = pdf_widget,-- belongs to widget, not to field
T= pdfunicode(specification.title),
-F= fieldplus(specification),
-Ff = fieldflag(specification),
+ -- F= fieldplus(specification), -- belongs to widget, not to field
+Ff = fieldflag(specification), -- not required for default value
OC = fieldlayer(specification),
DA = fieldsurrounding(specification),
AA = fieldactions(specification),
FT = pdf_sig,
Q= fieldalignment(specification),
-MaxLen = length == 0 and 1000 or length,
-DV = not value and text or nil,
-V= value or text,
+ -- MaxLen = length == 0 and 1000 or length, -- only for text fields
+MK = fieldrendering(specification),
+ -- DV = not value and text or nil, -- no default signature value
+ -- V= value or text, -- signature value, when actually signed
}
save_parent(field,specification,d)
end
@@ -1171,10 +1175,10 @@
Parent = pdfreference(parent.pobj),
F = fieldplus(specification),
OC = fieldlayer(specification),
-DA = fieldsurrounding(specification),
+ -- DA = fieldsurrounding(specification), --belongs to field, not widget
AA = fieldactions(specification),
MK = fieldrendering(specification),
-Q = fieldalignment(specification),
+ -- Q = fieldalignment(specification), --belongs to field, not widget
-- AP = pdfdictionary {
-- N = pdfreference(lpdf.flushstreamobject("q 0 0 100 100 re f Q"))
-- }
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : [email protected] /
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___
[NTG-context] Re: form field issues
My dear Pablo, Unfortunately, I forgot to mention that my research consisted of reading a few pages on the Internet, notably these: 1.) https://helpx.adobe.com/legal/esignatures/regulations/european-union.html; this one: https://eidas.ec.europa.eu/efda/trust-services/browse/eidas/tls; 2.) this one: https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467109076/What+is+the+legislation+-+eSignature; and this one: https://gregbur.me/2022/04/28/deep-dive-digitally-signing-pdfs-with-okular/. But I very much fear that my limited knowledge on the subject (particularly in legal matters and on the specific topic of secure electronic signatures) has unfortunately led me to ask for a summary of these thorny issues from a calculator that I know nothing about and that consumes a lot of energy. I have no doubt, of course, that in the real world things are much more complicated than a robot—which, after all, does nothing more than calculate the probabilities of one word following another—can certify. That is why we continue to tear our hair out, regardless of the fictitious or actual help that robots can provide us. My apologies if I have broken the unspoken rule of not citing my sources and, as a result, if I have offended anyone. Best//JP Le 18/12/2025 à 15:15, Pablo Rodriguez via ntg-context a écrit : On 12/17/25 22:45, Jean-Pierre Delange via ntg-context wrote: Hi Folks ! As an European citizen seeking official and reliable information about secure document signing, I conducted an investigation which indicates the following. Dear Jean-Pierre, the text resulting from your investigation looks too much like AI- computed text (aka AI slop). Sorry, but I reported in `poppler` (the PDF library that ”Okular” uses to handle PDF documents) the issue about signing some signature fields wrong (https://gitlab.freedesktop.org/poppler/poppler/-/issues/1640). I also commented to the MR to fix that issue (https://gitlab.freedesktop.org/poppler/poppler/-/merge_requests/1923). You might even trust me with the following: “the output from the investigation” may sound as a fairy tale (things in real life are way more complex [and complicated]). Just as a detail, PAdES from `poppler` (and then for “Okular” and “Papers”) is technically wrong, since time is included in the signature (not as a timestamp token). This is not allowed in PAdES. I wish things could be as the AI-computed tale presents them, but in real life (from what I have seen in these projects) is that there is plenty of work and very few people to manage it. If you allow me a suggestion, please, when sending AI-generated text to the list, mark it clearly, so that anyone could skip it (if they are inclined to do so). That way, we would still have an option. Just in case you would like to know. Cheers, Pablo ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___ ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
On 12/16/2025 5:01 PM, Pablo Rodriguez via ntg-context wrote: On 12/16/25 15:39, Hans Hagen via ntg-context wrote: I don’t know that these root keys are. If they are root certificates, leaf/user certificates are signed in chain, so root certificates need to be there to verify the certificate chain (from a trusted CA). yes but having them compiled into a viewer ... well ... Most web browsers contain root certificates (at least, Firefox/LibreWolf contain a bunch of them). In fact, `poppler` should benefit from that (although Firefox doesn’t include all [or probably most] EUTL certificates). Once I have checked all, I only ask you to include the patch for signature fields I will eventually send (if it’s ok, of course). i can have a look at the patch but can't test it Testing the patch and complaints are on me. ok, so i'll see what is coming once you're ready Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
Hi, Understandable. For me, PDF/X is a quite reliable basis for print data. Some preflight check makes sense, and probably I should look into what’s possible with CLI tools. Preflight can be dangerous. Some of these programs mess with the file and write a new one, and then there can be errors. (We had a case long ago where a 'famous preflighter' decided to mess with linewidths whicxh resulted in a 20K misprint run by a publisher. Easy to backtrack to the changes and no pity from our end (underpaid anyway). Apple’s Preview allows to include a manual signature. I would be surprised if that counted as a valid digital signature. Apparently Wondershare, PDFgear, and Sejda do the same. with all these tech companies pleasing dictators soon there is little untainted hard- and software for me to choose from ... so i can't check apple I wouldn’t buy Apple any more, also MacOS is getting enshittificated more and more, but my 2013 Mac mini is still my work computer, and I’m more productive on MacOS than on any Linux – it’s in the details, e.g. there’s no mark/annotation feature for files that works cross desktop environment. There are no tools to convert these informations from Apple’s resource forks to anything useful. There is still no good encrypted file system for external disks that works with MacOS and Linux (I’m using VeraCrypt, but it’s dead slow on my old computers). i had to ditch a windows surface (now a linux tablet) because for some reason a not bitlocked system had become one (no key of course) ... i never encrypt pc's (only the fairphone is encrypted) which makes one wonder: i think that for pdf some kind of check is fine but encryption is more tricky as what about 50 years from now (even for legal documents) ... govermements never look more than 3-4 years ahead (btw, in todays paper: germany moved (past tense) away from big tech and then only mentioning one 'bundeslander' having done that and nothing about the other having reverted .. flip-flopping; no mentioning of tex btw) I like GNOME, but KDE’s Dolphin is a better file manager, but some of its features/extensions don’t work with GNOME… I keep an eye on linux as fallback but it gets more bloated (even updating server is now gigabyte downloads with seeing stuff (libs) installed that i can't imagine making sense in a headless setup. Anyway, I just ordered a rpi 500+ in order to see how cheap / small we can go. Probably also a bit of making luametatex/context run faster challenge (as it will likely run 1/3 my current laptop). (the fastest amd tuxedo laptop i looked at is a bit out of my budget right now anyway and the current oen still runs fine, otherwise it would be a 6 times test setback) (no rant) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
On 12/17/25 22:45, Jean-Pierre Delange via ntg-context wrote: > Hi Folks ! > > As an European citizen seeking official and reliable information > about secure document signing, I conducted an investigation which > indicates the following. Dear Jean-Pierre, the text resulting from your investigation looks too much like AI- computed text (aka AI slop). Sorry, but I reported in `poppler` (the PDF library that ”Okular” uses to handle PDF documents) the issue about signing some signature fields wrong (https://gitlab.freedesktop.org/poppler/poppler/-/issues/1640). I also commented to the MR to fix that issue (https://gitlab.freedesktop.org/poppler/poppler/-/merge_requests/1923). You might even trust me with the following: “the output from the investigation” may sound as a fairy tale (things in real life are way more complex [and complicated]). Just as a detail, PAdES from `poppler` (and then for “Okular” and “Papers”) is technically wrong, since time is included in the signature (not as a timestamp token). This is not allowed in PAdES. I wish things could be as the AI-computed tale presents them, but in real life (from what I have seen in these projects) is that there is plenty of work and very few people to manage it. If you allow me a suggestion, please, when sending AI-generated text to the list, mark it clearly, so that anyone could skip it (if they are inclined to do so). That way, we would still have an option. Just in case you would like to know. Cheers, Pablo ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
Hi Folks ! As an European citizen seeking official and reliable information about secure document signing, I conducted an investigation which indicates the following Best//JP : Secure and Certified PDF Signing in the European Union /(Legal and Technical Background)/ 1. Scope and Purpose This appendix outlines the *legal, technical, and infrastructural requirements* for secure PDF signing within the European Union, with specific attention to standards compliance, trust-chain integrity, and platform-level constraints. It clarifies the respective roles of *document production systems* and *signature tools*, and situates Okular as a technically coherent signing solution in this context. 2. Regulatory Framework 2.1 eIDAS Regulation *eIDAS* (/Electronic IDentification, Authentication and trust Services/) is defined by Regulation /(EU) No 910/2014/. It establishes a unified legal framework for electronic signatures, seals, timestamps, and trust services across all EU Member States. eIDAS distinguishes three legal levels of electronic signatures: * *SES* (/Simple Electronic Signature/), * *AdES* (/Advanced Electronic Signature/), * *QES* (/Qualified Electronic Signature/), the latter being legally equivalent to a handwritten signature. Legal validity under eIDAS depends on *identity assurance*, *document integrity*, and *non-repudiation*, all of which rely on cryptographic mechanisms and trusted certification authorities rather than on document layout or visual appearance. 3. PDF Signature Standard 3.1 PAdES *PAdES* (/PDF Advanced Electronic Signatures/) is specified in *ETSI EN 319 142*. It defines how cryptographic signatures are embedded into PDF documents in a manner compatible with long-term validation and legal verification. Common profiles include: * *PAdES-B* (/Basic/), * *PAdES-T* (/Timestamped/), * *PAdES-LT* (/Long-Term Validation/), * *PAdES-LTA* (/Long-Term Archival/). For professional and institutional use, *PAdES-T* or *PAdES-LT* are generally required. 4. Chain of Trust Requirements A legally valid electronic signature presupposes an *unbroken chain of trust*: 1. The document is signed using a private cryptographic key. 2. The associated *X.509* certificate is valid and not revoked. 3. The certificate is issued by a recognized *CA* (/Certification Authority/). 4. The trust chain terminates at a root authority listed by the EU. 5. For *QES*, the private key must reside in a *QSCD* (/Qualified Signature Creation Device/). Failure at any level invalidates the legal standing of the signature. 5. Platform Considerations 5.1 Linux and Windows Both platforms provide: * mature *PKI* (/Public Key Infrastructure/) stacks, * robust *PKCS #11* (/Public-Key Cryptography Standards/) support for smart cards and hardware tokens, * wide compatibility with national eID systems and *QTSPs* (/Qualified Trust Service Providers/). As a result, they are consistently recommended by European trust service providers for advanced and qualified signatures. 5.2 macOS macOS relies on proprietary key management mechanisms with limited and inconsistent *PKCS #11* integration. Vendor support for qualified devices is weaker, and interoperability with EU eID ecosystems is often incomplete. This constrains its suitability for high-assurance signing workflows. 6. Okular as a Signing Tool Okular implements *PAdES* in strict compliance with ETSI specifications and leverages system-level cryptographic libraries. It provides transparent access to: * certificate identity, * validation status, * revocation information, * signature integrity. Its native integration with Linux and solid support on Windows make it well suited for eIDAS-compliant signing, particularly in environments using hardware-backed certificates. 7. ConTeXt and the Limits of Document Production ConTeXt is a document composition system that produces *technically robust and standards-compliant PDF files*, including structured metadata where required. It may define signature fields within a PDF but does not perform cryptographic signing. This limitation is deliberate and appropriate: secure electronic signing requires controlled access to private keys, trusted hardware, and system-level certificate stores—functions that properly belong to specialized signing tools rather than to a typesetting engine. 8. Recommended Workflow 1. *ConTeXt*: generate the final PDF (optionally PDF/A, with metadata). 2. *Okular*: apply a *PAdES* signature using an advanced or qualified certificate. 3. *Verification*: validate the signature and trust chain using a standards-compliant reader. This separation of responsibilities ensures legal conformity, technical robustness, and auditability.
[NTG-context] Re: form field issues
Am 16.12.25 um 23:30 schrieb Hans Hagen via ntg-context: On 12/16/2025 6:56 PM, Henning Hraban Ramm wrote: Am 16.12.25 um 16:56 schrieb Pablo Rodriguez via ntg-context: BTW, do you know other (freely-available [and preferably offline]) programs that sign PDF documents? * Qoppa PDF Studio Pro (commercial, Lin/Mac/Win) https://www.qoppa.com/pdfstudio/ * Code Industry Master PDF Editor (commercial, Lin/Mac/Win) https://code-industry.net/masterpdfeditor/ * Okular (OSS, Lin/Mac/Win) https://okular.kde.org I actually wasn’t aware that there’s a Mac version of Okular. there's also a windows version, quite ok Yes, but I was already aware of it. ;) (But annotations are still a PITA.) maybe they don't care to much about that, most pushed-in-git changes are other things (pdf is not the only format they do) but the plenty dependencies make that i am not too motivated to look into fixing the pdf bits (basics are there) They have a GUI with a few common elements that are usable for different things but not ideally/creatively adapted for special needs. I can understand that, but I still would prefer an interface for threaded annotations like the one in Foxit Reader or Acrobat. Master PDF editor’s annotation interface is similar to Okular’s. It’s usable for a few comments, but not for a book full of corrections. The 2 editors have demo versions, I don’t know what you can do with them. I’ve a license of PDF Studio Pro (since it’s the only tool besides Acrobat Pro that can check & convert PDF/X). i have no application so i rather spend my money on cd's, books and concerts Understandable. For me, PDF/X is a quite reliable basis for print data. Some preflight check makes sense, and probably I should look into what’s possible with CLI tools. Apple’s Preview allows to include a manual signature. I would be surprised if that counted as a valid digital signature. Apparently Wondershare, PDFgear, and Sejda do the same. with all these tech companies pleasing dictators soon there is little untainted hard- and software for me to choose from ... so i can't check apple I wouldn’t buy Apple any more, also MacOS is getting enshittificated more and more, but my 2013 Mac mini is still my work computer, and I’m more productive on MacOS than on any Linux – it’s in the details, e.g. there’s no mark/annotation feature for files that works cross desktop environment. There are no tools to convert these informations from Apple’s resource forks to anything useful. There is still no good encrypted file system for external disks that works with MacOS and Linux (I’m using VeraCrypt, but it’s dead slow on my old computers). I like GNOME, but KDE’s Dolphin is a better file manager, but some of its features/extensions don’t work with GNOME… Well, I’ll stop off-topic ranting… Hraban ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
On 12/16/2025 6:56 PM, Henning Hraban Ramm wrote: Am 16.12.25 um 16:56 schrieb Pablo Rodriguez via ntg-context: BTW, do you know other (freely-available [and preferably offline]) programs that sign PDF documents? * Qoppa PDF Studio Pro (commercial, Lin/Mac/Win) https://www.qoppa.com/pdfstudio/ * Code Industry Master PDF Editor (commercial, Lin/Mac/Win) https://code-industry.net/masterpdfeditor/ * Okular (OSS, Lin/Mac/Win) https://okular.kde.org I actually wasn’t aware that there’s a Mac version of Okular. there's also a windows version, quite ok (But annotations are still a PITA.) maybe they don't care to much about that, most pushed-in-git changes are other things (pdf is not the only format they do) but the plenty dependencies make that i am not too motivated to look into fixing the pdf bits (basics are there) The 2 editors have demo versions, I don’t know what you can do with them. I’ve a license of PDF Studio Pro (since it’s the only tool besides Acrobat Pro that can check & convert PDF/X). i have no application so i rather spend my money on cd's, books and concerts Apple’s Preview allows to include a manual signature. I would be surprised if that counted as a valid digital signature. Apparently Wondershare, PDFgear, and Sejda do the same. with all these tech companies pleasing dictators soon there is little untainted hard- and software for me to choose from ... so i can't check apple I found https://www.bytesigner.in that is apparently aimed at big companies, they don’t even name a price. that's the point: the tex/pdf world is basically not interesting and/or considered as there is money to be made elsewhere (has always been the case with pdf) which then involves marketing and who likes that which is why in the end we need to keep tex a bit invisible .. away for the competing markets .. not distraction .. so we just support/adapt-to what is needed, e.g. wrt signing and move on Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
Am 16.12.25 um 16:56 schrieb Pablo Rodriguez via ntg-context: BTW, do you know other (freely-available [and preferably offline]) programs that sign PDF documents? * Qoppa PDF Studio Pro (commercial, Lin/Mac/Win) https://www.qoppa.com/pdfstudio/ * Code Industry Master PDF Editor (commercial, Lin/Mac/Win) https://code-industry.net/masterpdfeditor/ * Okular (OSS, Lin/Mac/Win) https://okular.kde.org I actually wasn’t aware that there’s a Mac version of Okular. (But annotations are still a PITA.) The 2 editors have demo versions, I don’t know what you can do with them. I’ve a license of PDF Studio Pro (since it’s the only tool besides Acrobat Pro that can check & convert PDF/X). Apple’s Preview allows to include a manual signature. I would be surprised if that counted as a valid digital signature. Apparently Wondershare, PDFgear, and Sejda do the same. I found https://www.bytesigner.in that is apparently aimed at big companies, they don’t even name a price. HTH Hraban ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
On 12/16/25 07:30, Pablo Rodriguez via ntg-context wrote: > [...] > > to be fair, I haven’t tested the improved ConTeXt-generated signature > fields against MuPDF-GL and poppler, but not against Foxit Reader (I > cannot recall any other PDF signing software). Hi Hraban, I have tested Foxit Reader 2025.2.1 and it fails too (signature value is added to a pure widget instead of the signature field). BTW, do you know other (freely-available [and preferably offline]) programs that sign PDF documents? Just in case it might help, Pablo ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
On 12/16/25 15:39, Hans Hagen via ntg-context wrote: >> >> I don’t know that these root keys are. If they are root certificates, >> leaf/user certificates are signed in chain, so root certificates need to >> be there to verify the certificate chain (from a trusted CA). > > yes but having them compiled into a viewer ... well ... Most web browsers contain root certificates (at least, Firefox/LibreWolf contain a bunch of them). In fact, `poppler` should benefit from that (although Firefox doesn’t include all [or probably most] EUTL certificates). >> Once I have checked all, I only ask you to include the patch for >> signature fields I will eventually send (if it’s ok, of course). > > i can have a look at the patch but can't test it Testing the patch and complaints are on me. Many thanks for your help, Pablo ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
On 12/16/2025 8:12 AM, Pablo Rodriguez via ntg-context wrote: On 12/15/25 21:01, Hans Hagen via ntg-context wrote: On 12/15/2025 8:11 PM, Pablo Rodriguez via ntg-context wrote: [...] I have a patch for `lpdf-fld.lmt` which fixes this, but it requires fixing `poppler` (and probably any other software) first. This parent / child stuff has always been a mess: fix this, break that. Many thanks for your reply, Hans. Our field parent and widget child is wrong (especially with signatures) because we have mixed dictionaries: a signature parent that also contains widget entries in the same object and a widget child that also has signature entries. Sorry, but I’m afraid this cannot work and this is why “Acrobat Reader” merges both dictionaries into a single one. With signatures (especially), there are two options, a single dictionary, or the parent has to be a pure field dictionary (no widget entries) and the child has to be a pure widget dictionary (no field entries). Also our signature fields add both a default value (I think it makes no sense in a signature) and a value (which I think it should be added when signing only). A waste of time. Anyway, I have no 'full acrobat' to test and actually try to avoid the reader with its aggressive 'ai wants to help making a summary' kind of crap as well as the ever changing interfaces. I only have access to “Acrobat Reader”, no interest in any full version. I only use “Acrobat” to check signatures and `/GoToE` actions (link to embedded PDF documents) and nothing more. The forced “AI-help” is also really annoying for me. BTW, I’m doing all this testing to ensure “Acrobat” compatibility. Let me do all the work here and I will provide a patch. I’m going to waste my time here. “Acrobat” will be working fine and at least `poppler` (“Okular“ and “Evince”) will be able to use our signature fields. Signing is dubious anyway with the necessity to use expensive tools (because one can't use the free-ish web certificates) At least in Spain, our official IDs contain a pair of certificates (one for authentication and another for signatures, https://en.wikipedia.org/wiki/National_Identity_Card_(Spain)) and FNMT (the Spanish Royal Mint) provides free certificates for natural persons. As a general rule, I think that Article 5a.5.g of Regulation EU/910/2014 (http://data.europa.eu/eli/reg/2014/910/2024-10-18#art_5a) may require that: offer all natural persons the ability to sign by means of qualified electronic signatures by default and free of charge. In any case, signing with testing / self-made certificates is a good way to check whether a PDF document has been modified at all (by regular programs [such as SharePoint] or “helping AI”). and (last time i checked) hard coded root keys in viewers. I don’t know that these root keys are. If they are root certificates, leaf/user certificates are signed in chain, so root certificates need to be there to verify the certificate chain (from a trusted CA). yes but having them compiled into a viewer ... well ... In the European Union, we have the EU Trust List (as defined by Regulation EU/910/2014. “Acrobat Reader” includes all root and intermediate certificates and this is really helpful. The EUTL helps to know whether an electronic signature is legally binding or not (since the signer’s identity has been verified by a trusted CA). Once I have checked all, I only ask you to include the patch for signature fields I will eventually send (if it’s ok, of course). i can have a look at the patch but can't test it - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
On 12/15/25 21:01, Hans Hagen via ntg-context wrote: > On 12/15/2025 8:11 PM, Pablo Rodriguez via ntg-context wrote: >> [...] >> I have a patch for `lpdf-fld.lmt` which fixes this, but it requires >> fixing `poppler` (and probably any other software) first. > > This parent / child stuff has always been a mess: fix this, break that. Many thanks for your reply, Hans. Our field parent and widget child is wrong (especially with signatures) because we have mixed dictionaries: a signature parent that also contains widget entries in the same object and a widget child that also has signature entries. Sorry, but I’m afraid this cannot work and this is why “Acrobat Reader” merges both dictionaries into a single one. With signatures (especially), there are two options, a single dictionary, or the parent has to be a pure field dictionary (no widget entries) and the child has to be a pure widget dictionary (no field entries). Also our signature fields add both a default value (I think it makes no sense in a signature) and a value (which I think it should be added when signing only). > A waste of time. Anyway, I have no 'full acrobat' to test and actually > try to avoid the reader with its aggressive 'ai wants to help making a > summary' kind of crap as well as the ever changing interfaces. I only have access to “Acrobat Reader”, no interest in any full version. I only use “Acrobat” to check signatures and `/GoToE` actions (link to embedded PDF documents) and nothing more. The forced “AI-help” is also really annoying for me. BTW, I’m doing all this testing to ensure “Acrobat” compatibility. Let me do all the work here and I will provide a patch. I’m going to waste my time here. “Acrobat” will be working fine and at least `poppler` (“Okular“ and “Evince”) will be able to use our signature fields. > Signing is dubious anyway with the necessity to use expensive tools > (because one can't use the free-ish web certificates) At least in Spain, our official IDs contain a pair of certificates (one for authentication and another for signatures, https://en.wikipedia.org/wiki/National_Identity_Card_(Spain)) and FNMT (the Spanish Royal Mint) provides free certificates for natural persons. As a general rule, I think that Article 5a.5.g of Regulation EU/910/2014 (http://data.europa.eu/eli/reg/2014/910/2024-10-18#art_5a) may require that: offer all natural persons the ability to sign by means of qualified electronic signatures by default and free of charge. In any case, signing with testing / self-made certificates is a good way to check whether a PDF document has been modified at all (by regular programs [such as SharePoint] or “helping AI”). > and (last time i checked) hard coded root keys in viewers. I don’t know that these root keys are. If they are root certificates, leaf/user certificates are signed in chain, so root certificates need to be there to verify the certificate chain (from a trusted CA). In the European Union, we have the EU Trust List (as defined by Regulation EU/910/2014. “Acrobat Reader” includes all root and intermediate certificates and this is really helpful. The EUTL helps to know whether an electronic signature is legally binding or not (since the signer’s identity has been verified by a trusted CA). Once I have checked all, I only ask you to include the patch for signature fields I will eventually send (if it’s ok, of course). Many thanks for your help, Pablo ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
On 12/15/25 20:29, Henning Hraban Ramm wrote: > Am 15.12.25 um 20:11 schrieb Pablo Rodriguez via ntg-context: >> [...] >> I have checked the signature fields and we have problems with digitally >> sign that with any other than “Acrobat”. > > Hi Pablo, > > thank you! I will include your statement in my book. IMO it makes no > sense to try to use this feature in the current sorry state. Hi Hraban, to be fair, I haven’t tested the improved ConTeXt-generated signature fields against MuPDF-GL and poppler, but not against Foxit Reader (I cannot recall any other PDF signing software). I have to investigate this further, since if “Acrobat Reader” recognizes (what I think it may be) another valid signature field structure, fixing the way we generate these fields will allow signatures from other programs to be recognized by “Acrobat”. Just in case it helps, Pablo ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
On 12/15/2025 8:29 PM, Henning Hraban Ramm wrote: Am 15.12.25 um 20:11 schrieb Pablo Rodriguez via ntg-context: On 12/15/25 18:56, Henning Hraban Ramm wrote: Hi again, I checked some old form issues (e.g. in my Chaos Post complaints form, [...] * I didn’t yet check label/choice/popup/combo/signature fields. Hi Hraban, many thanks for checking fields. I have checked the signature fields and we have problems with digitally sign that with any other than “Acrobat”. Hi Pablo, thank you! I will include your statement in my book. IMO it makes no sense to try to use this feature in the current sorry state. I’ll also advise against everything else than line, text and check fields that can work in a printable form and are still helpful interactively. (radio would be fixable, as outlined in my OP.) I tried choice/popup/combo fields now, and viewer support is just too bad IMO. It doesn’t help that ConTeXt’s height setting doesn’t seem to work on popup & combo. well, it all has worked ok (over a decade ago it did) so maybe somethign changed ... one should anyway play safe with these features; same with annotations as some stuff was also dropped from the standard there i paobbaly would look into it (current state of viewers etc) when i had a project that needs it but that's not the case so other things take priority Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
On 12/15/2025 8:11 PM, Pablo Rodriguez via ntg-context wrote: On 12/15/25 18:56, Henning Hraban Ramm wrote: Hi again, I checked some old form issues (e.g. in my Chaos Post complaints form, [...] * I didn’t yet check label/choice/popup/combo/signature fields. Hi Hraban, many thanks for checking fields. I have checked the signature fields and we have problems with digitally sign that with any other than “Acrobat”. I have tested it (rather extensively) against the Arlington PDF model (https://software.verapdf.org/develop/arlington/). [Just in case anyone might wonder, it is a different validator than the PDF/A-PDF/UA validator. This is just PDF-1.x or PDF-2.0 validator.] The real issue here is that ConTeXt isn’t using the field parent/widget child relationship totally right (I’m afraid). “Acrobat” has no issue with that (since it merges both parent field and child widget objects into a single one), but `pdfsig` from `poppler` and “MuPDF-GL” end up adding digital signatures that are invisible to “Acrobat” (but these are technically wrong). I also have the impression (which I have to check with the people from the Arlington project) that “Acrobat” may be failling to recognize valid signatures (with field-widget single objects not expected by “Acrobat”). I have a patch for `lpdf-fld.lmt` which fixes this, but it requires fixing `poppler` (and probably any other software) first. Just in case it might avoid you some work, This parent / child stuff has always been a mess: fix this, break that. It was in the standard before even acrobat did it all and then there was a bugged inheritance of (e.g. check) field default values that partally became a feature. Submitting bugs made little sense because after a release the test / beta teams are disolved. By the time other pdf processers catched op the mess was (imo) persistent. A waste of time. Anyway, I have no 'full acrobat' to test and actually try to avoid the reader with its aggressive 'ai wants to help making a summary' kind of crap as well as the ever changing interfaces. Signing is dubious anyway with the neccessity to use expensive tools (because one can't use the free-ish web certificates) and (last time i checked) hard coded root keys in viewers. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
Am 15.12.25 um 20:11 schrieb Pablo Rodriguez via ntg-context: On 12/15/25 18:56, Henning Hraban Ramm wrote: Hi again, I checked some old form issues (e.g. in my Chaos Post complaints form, [...] * I didn’t yet check label/choice/popup/combo/signature fields. Hi Hraban, many thanks for checking fields. I have checked the signature fields and we have problems with digitally sign that with any other than “Acrobat”. Hi Pablo, thank you! I will include your statement in my book. IMO it makes no sense to try to use this feature in the current sorry state. I’ll also advise against everything else than line, text and check fields that can work in a printable form and are still helpful interactively. (radio would be fixable, as outlined in my OP.) I tried choice/popup/combo fields now, and viewer support is just too bad IMO. It doesn’t help that ConTeXt’s height setting doesn’t seem to work on popup & combo. Hraban ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: form field issues
On 12/15/25 18:56, Henning Hraban Ramm wrote: > Hi again, I checked some old form issues (e.g. in my Chaos Post > complaints form, > [...] > * I didn’t yet check label/choice/popup/combo/signature fields. Hi Hraban, many thanks for checking fields. I have checked the signature fields and we have problems with digitally sign that with any other than “Acrobat”. I have tested it (rather extensively) against the Arlington PDF model (https://software.verapdf.org/develop/arlington/). [Just in case anyone might wonder, it is a different validator than the PDF/A-PDF/UA validator. This is just PDF-1.x or PDF-2.0 validator.] The real issue here is that ConTeXt isn’t using the field parent/widget child relationship totally right (I’m afraid). “Acrobat” has no issue with that (since it merges both parent field and child widget objects into a single one), but `pdfsig` from `poppler` and “MuPDF-GL” end up adding digital signatures that are invisible to “Acrobat” (but these are technically wrong). I also have the impression (which I have to check with the people from the Arlington project) that “Acrobat” may be failling to recognize valid signatures (with field-widget single objects not expected by “Acrobat”). I have a patch for `lpdf-fld.lmt` which fixes this, but it requires fixing `poppler` (and probably any other software) first. Just in case it might avoid you some work, Pablo ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
