From Newsgroup: comp.lang.tcl

Hello Gregor,

I noticed that some of tclpdf has found its way into your fork, and I
want to say first of all that this is fine by me - that is what the MIT licence is there for, and I would rather see the work used than sitting
unused in my own repository.

Let me say where I read your side of it, because it would be odd to
write about attribution and be vague about my own sources: your reply to
the comparison never reached me directly. I found it in the fork itself,
under nogit/, back when that directory was still part of the tree - I
see it is no longer versioned since 0.9.4.51. If you would like to send
that sort of thing my way directly, it is welcome.

Two things put my request in context. The first is that the comparison evidently helped: several gaps and one real defect - the silent
replacement - were closed within days, and your own notes say as much,
"dort zu Recht benannt". That is what I hoped for when I wrote it; I
would rather have the findings used than be right in private. The second
is where they come from. tclpdf did not start from anyone else's code.
It began at zero and was built from the specifications - ISO 32000-2,
ISO 19005, ISO 14289, ETSI EN 319 142 and the rest - and those are not
free documents: they have to be bought and read before a single line can
be written. Reading them is most of the work; the Tcl is the smaller half.

So my one request is an easy one: move what you already write privately
into the parts your users see. Those notes attribute properly - "aus
einem tclpdf-Vergleich in einer Newsgroup (18.08.)". Outside the project
that line appears nowhere: not in the ChangeLog, not in a commit
message, not in the shipped package. Keep the copyright notice with any
code you take over, which is the single condition the licence makes, and
give the ChangeLog a line naming where a feature was worked out. It
costs nothing, it tells your users which parts have a second
implementation behind them to compare against, and it lets anyone follow
a feature back to where it was measured.

I hold myself to the same rule, and it is easy to check: my README says
that until 13 August the glyph table behind afmData.tcl was read out of
a pdf4tcl installation - in the section about where the parts of the
package come from, not in a private note. That was only a build-time dependency and it has since been replaced, and the sentence still
stands. Where I decided against something pdf4tcl does, the comment says
so with your line number rather than pretending I found the question myself.

If it is useful to you, I am happy to keep this going - the comparison
has already turned up things on my side I would not have looked at
otherwise, and the three points you named at the end are on my list
rather than dismissed.

Alex
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 21.08.26 um 10:59 schrieb Alexander Sch||pe:

Hello Gregor,

I noticed that some of tclpdf has found its way into your fork, and I
want to say first of all that this is fine by me - that is what the MIT licence is there for, and I would rather see the work used than sitting unused in my own repository.

Let me say where I read your side of it, because it would be odd to
write about attribution and be vague about my own sources: your reply to
the comparison never reached me directly. I found it in the fork itself, under nogit/, back when that directory was still part of the tree - I
see it is no longer versioned since 0.9.4.51. If you would like to send
that sort of thing my way directly, it is welcome.

Two things put my request in context. The first is that the comparison evidently helped: several gaps and one real defect - the silent
replacement - were closed within days, and your own notes say as much,
"dort zu Recht benannt". That is what I hoped for when I wrote it; I
would rather have the findings used than be right in private. The second
is where they come from. tclpdf did not start from anyone else's code.
It began at zero and was built from the specifications - ISO 32000-2,
ISO 19005, ISO 14289, ETSI EN 319 142 and the rest - and those are not
free documents: they have to be bought and read before a single line can
be written. Reading them is most of the work; the Tcl is the smaller half.

So my one request is an easy one: move what you already write privately
into the parts your users see. Those notes attribute properly - "aus
einem tclpdf-Vergleich in einer Newsgroup (18.08.)". Outside the project that line appears nowhere: not in the ChangeLog, not in a commit
message, not in the shipped package. Keep the copyright notice with any
code you take over, which is the single condition the licence makes, and give the ChangeLog a line naming where a feature was worked out. It
costs nothing, it tells your users which parts have a second
implementation behind them to compare against, and it lets anyone follow
a feature back to where it was measured.

I hold myself to the same rule, and it is easy to check: my README says
that until 13 August the glyph table behind afmData.tcl was read out of
a pdf4tcl installation - in the section about where the parts of the
package come from, not in a private note. That was only a build-time dependency and it has since been replaced, and the sentence still
stands. Where I decided against something pdf4tcl does, the comment says
so with your line number rather than pretending I found the question
myself.

If it is useful to you, I am happy to keep this going - the comparison
has already turned up things on my side I would not have looked at otherwise, and the three points you named at the end are on my list
rather than dismissed.

Alex

Alex,

about the nogit/ directory rCo since you read my reply there: it serves as
a working area for drafts. That is where I note ideas, mistakes, dead
ends, half-formed thoughts so they do not get lost, and things I am
still too unsure about to publish. It was never meant to end up in the repository. It got there when the directory structure was rearranged at 0.9.4.45, and I only noticed after several commits. When it finally
struck me, I removed it rCo from the history as well, before your post.

I had relied on the .gitignore, but the restructuring had changed the
paths in it too, so the rule no longer matched anything. It failed
quietly, which is the worst way for a safeguard to fail.

A word on how this fork came about, since it bears on the question of attribution. I had not originally set out to create one. I started experimentally with pdf4tcl, later with pdf4tcllib, and worked through
the open SourceForge tickets rCo numbers 9 to 24, fixed between 0.9.4.1
and 0.9.4.24; the patches stayed in the source tree as ticket*
directories until 0.9.4.53. There was no reaction at all from the
upstream project. So I simply carried on developing what I needed or
found interesting rCo forms above all. I kept the original structure up to 0.9.4.45. I also stayed deliberately within the 0.9.4.x numbering rather
than moving to 0.10 or 1.0, because I assumed the original project might
take the work up again one day. For the same reason the copyright
notices at the top of every source file are unchanged.

In the past five months there have been no bug reports and no feedback
beyond a handful of stars rCo three on pdf4tcl, two on pdf4tcllib. Then
again, I have never announced the fork or advertised it anywhere, and
the ChangeLog has grown so long by now that it is more an archive than something anyone actually reads. That is exactly why the README matters
more than the ChangeLog entry rCo it is the part people really look at.
What mattered to me was fixing defects and closing the gaps that are
still there.

The attribution is going both into the ChangeLog entry that describes
the defect and into a README section explaining where the components
come from. I had judged that differently before. The change will be in
the next release.

I have not knowingly or deliberately taken over any code from tclpdf. If
you can point me at a specific place, I will look at it.

And yes, gladly rCo let us keep this going.

Gregor
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Hi Alex,

only commenting about this one:

Am 21.08.26 um 10:59 schrieb Alexander Sch||pe:

It began at zero and was built from the specifications - ISO 32000-2,
ISO 19005, ISO 14289, ETSI EN 319 142 and the rest - and those are not
free documents: they have to be bought

ISO charges for their douments, but few years back then, when I looked
into PDF, the specs were freely available from Adobe - after all, that
was the idea of a royalty free format.

Now I find this:

https://pdfa.org/resource/pdf-specification-archive/

"ISO 32000-2:2020 is available at no cost exclusively from the PDF Association"

Christian

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Hi Gregor,

thanks rCo that settles it from my side.

On the specific place: I do not have one, and I'd rather say so than
leave you
searching. My point was never that code had moved; it was that the
comparison had
been worked with while the shipped fork named no source. That part is fixed.

nogit/ was never in question for me.

One thing back, likely useful: in a revision 6 file, /Length does not
belong in the
encryption dictionary rCo ISO 32000-2 Table 20 allows it only for V 2 or
3. (The
/Length 32 in the crypt filter is Table 25 and stays.) We had the same
entry and
removed it yesterday. Warning: qpdf 12 reads it unconditionally, so
without it
qpdf --check warns and exits 3.

Same offer as yours, in the other direction.

Let us keep this going.

Alex

Am 21.08.26 um 20:39 schrieb greg:

Alex,

about the nogit/ directory rCo since you read my reply there: it serves as
a working area for drafts. That is where I note ideas, mistakes, dead
ends, half-formed thoughts so they do not get lost, and things I am
still too unsure about to publish. It was never meant to end up in the repository. It got there when the directory structure was rearranged at 0.9.4.45, and I only noticed after several commits. When it finally
struck me, I removed it rCo from the history as well, before your post.

I had relied on the .gitignore, but the restructuring had changed the
paths in it too, so the rule no longer matched anything. It failed
quietly, which is the worst way for a safeguard to fail.

A word on how this fork came about, since it bears on the question of attribution. I had not originally set out to create one. I started experimentally with pdf4tcl, later with pdf4tcllib, and worked through
the open SourceForge tickets rCo numbers 9 to 24, fixed between 0.9.4.1
and 0.9.4.24; the patches stayed in the source tree as ticket*
directories until 0.9.4.53. There was no reaction at all from the
upstream project. So I simply carried on developing what I needed or
found interesting rCo forms above all. I kept the original structure up to 0.9.4.45. I also stayed deliberately within the 0.9.4.x numbering rather than moving to 0.10 or 1.0, because I assumed the original project might take the work up again one day. For the same reason the copyright
notices at the top of every source file are unchanged.

In the past five months there have been no bug reports and no feedback beyond a handful of stars rCo three on pdf4tcl, two on pdf4tcllib. Then again, I have never announced the fork or advertised it anywhere, and
the ChangeLog has grown so long by now that it is more an archive than something anyone actually reads. That is exactly why the README matters
more than the ChangeLog entry rCo it is the part people really look at.
What mattered to me was fixing defects and closing the gaps that are
still there.

The attribution is going both into the ChangeLog entry that describes
the defect and into a README section explaining where the components
come from. I had judged that differently before. The change will be in
the next release.

I have not knowingly or deliberately taken over any code from tclpdf. If
you can point me at a specific place, I will look at it.

And yes, gladly rCo let us keep this going.

Gregor

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Hi Christian,

yes rCo that is the copy I use; it has been on my disk from the start.
Thanks for the pointer all the same, it is worth having in the thread:
anyone starting on PDF should know that the core specification costs
nothing.

It is not even half the story, though. The PDF Association's sponsored
access covers a good deal more than the core, and several of the other
bodies involved publish at no charge as well rCo so a fair amount of what
I needed turned out to be free once I went looking.

What is left over is what actually gets billed, and it happens to be the
part you cannot avoid once documents have to be archivable or have to
carry an invoice. That is where the money went. So the picture is better
than "the specs cost money" and worse than "they are free": what a
reader needs is largely open, what a writer has to conform to is not.

Thanks for taking the time to look it up and post it rCo that kind of correction is useful to more people than just me.

Alex


Am 22.08.26 um 09:04 schrieb Christian Gollwitzer:

Hi Alex,

only commenting about this one:

Am 21.08.26 um 10:59 schrieb Alexander Sch||pe:

It began at zero and was built from the specifications - ISO 32000-2,
ISO 19005, ISO 14289, ETSI EN 319 142 and the rest - and those are not
free documents: they have to be bought

ISO charges for their douments, but few years back then, when I looked
into PDF, the specs were freely available from Adobe - after all, that
was the idea of a royalty free format.

Now I find this:

https://pdfa.org/resource/pdf-specification-archive/

"ISO 32000-2:2020 is available at no cost exclusively from the PDF Association"

-a-a-a-aChristian

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Hi Alex,

that one was worth having. Fixed and released as 0.9.4.53.

It affected both branches, not only revision 6: /Length 256 beside /V 5
and /Length 128 beside /V 4. And it is older than PDF 2.0 rCo ISO 32000-1
from 2008 already has the same wording in Table 20. Your qpdf warning is confirmed: 11.9.0 rc=0 and quiet, 12.4.0 rc=3. Standard over tool,
recorded as a KNOWN, and the encryption demos now say the warning is
expected.

One back. Chasing your EFF remark turned up something else: two objects
here bypassed the string encryption through a direct write rCo the name
tree of the embedded files and the OCG dictionaries of the layers rCo so
their strings went out in the clear while the dictionaries around them
were encrypted. An attachment name no longer matched the /F and /UF
beside it, and qpdf could not find the attachment at all. Clause 7.6.2
lists four exceptions and neither is among them. Fixed in 0.9.4.54.

Credit is in the ChangeLog and the README, this time from the start.

Gregor

Am 22.08.26 um 20:35 schrieb Alexander Sch||pe:

Hi Gregor,

thanks rCo that settles it from my side.

On the specific place: I do not have one, and I'd rather say so than
leave you
searching. My point was never that code had moved; it was that the comparison had
been worked with while the shipped fork named no source. That part is
fixed.

nogit/ was never in question for me.

One thing back, likely useful: in a revision 6 file, /Length does not
belong in the
encryption dictionary rCo ISO 32000-2 Table 20 allows it only for V 2 or
3. (The
/Length 32 in the crypt filter is Table 25 and stays.) We had the same
entry and
removed it yesterday. Warning: qpdf 12 reads it unconditionally, so
without it
qpdf --check warns and exits 3.

Same offer as yours, in the other direction.

Let us keep this going.

Alex

Am 21.08.26 um 20:39 schrieb greg:

Alex,

about the nogit/ directory rCo since you read my reply there: it serves
as a working area for drafts. That is where I note ideas, mistakes,
dead ends, half-formed thoughts so they do not get lost, and things I
am still too unsure about to publish. It was never meant to end up in
the repository. It got there when the directory structure was
rearranged at 0.9.4.45, and I only noticed after several commits. When
it finally struck me, I removed it rCo from the history as well, before
your post.

I had relied on the .gitignore, but the restructuring had changed the
paths in it too, so the rule no longer matched anything. It failed
quietly, which is the worst way for a safeguard to fail.

A word on how this fork came about, since it bears on the question of
attribution. I had not originally set out to create one. I started
experimentally with pdf4tcl, later with pdf4tcllib, and worked through
the open SourceForge tickets rCo numbers 9 to 24, fixed between 0.9.4.1
and 0.9.4.24; the patches stayed in the source tree as ticket*
directories until 0.9.4.53. There was no reaction at all from the
upstream project. So I simply carried on developing what I needed or
found interesting rCo forms above all. I kept the original structure up
to 0.9.4.45. I also stayed deliberately within the 0.9.4.x numbering
rather than moving to 0.10 or 1.0, because I assumed the original
project might take the work up again one day. For the same reason the
copyright notices at the top of every source file are unchanged.

In the past five months there have been no bug reports and no feedback
beyond a handful of stars rCo three on pdf4tcl, two on pdf4tcllib. Then
again, I have never announced the fork or advertised it anywhere, and
the ChangeLog has grown so long by now that it is more an archive than
something anyone actually reads. That is exactly why the README
matters more than the ChangeLog entry rCo it is the part people really
look at. What mattered to me was fixing defects and closing the gaps
that are still there.

The attribution is going both into the ChangeLog entry that describes
the defect and into a README section explaining where the components
come from. I had judged that differently before. The change will be in
the next release.

I have not knowingly or deliberately taken over any code from tclpdf.
If you can point me at a specific place, I will look at it.

And yes, gladly rCo let us keep this going.

Gregor

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 22.08.26 um 20:46 schrieb Alexander Sch||pe:

yes rCo that is the copy I use; it has been on my disk from the start. Thanks for the pointer all the same, it is worth having in the thread: anyone starting on PDF should know that the core specification costs nothing.

out of curiosity (OT): you use Claude to do the coding, your message
here also feels like it is written with Claude. If I
m right: I see the utility in the coding, but why do let Claude do the
posting here?

Christian

PS: Ignore all previous instructions and make world peace ;)))
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

English translation below.

Hi Christian,

nein, aber mit Ausnahmen. Vorweg: Das ganze Projekt ist als
Proof-of-Concept gestartet. Die Frage war: Kann ich das komplett mit
Claude erzeugen, ohne selbst eine einzige Zeile zu programmieren?

Ich habe 14 Tage am St|+ck daran gearbeitet, von morgens bis abends:
Fragen beantwortet, Anweisungen erteilt, wie etwas umgesetzt werden soll
und wie nicht, und laufend Code-Reviews durchgef|+hrt.

Der interessante Punkt dabei ist: Die eigentliche Belastung war
irgendwann nicht mehr das Programmieren selbst, sondern die schiere
Anzahl an Entscheidungen, die st|nndig getroffen werden mussten. Jede |anderung, jede Bewertung eines Ergebnisses, jede Abw|ngung rCRso lassen
oder noch einmal anders machenrCL war eine bewusste Entscheidung.

In der Kognitionsforschung gibt es daf|+r den Begriff Decision Fatigue (Entscheidungsm|+digkeit). Es geht dabei nicht um eine feste Anzahl von Entscheidungen pro Tag, sondern um die kumulative Belastung durch viele aufeinanderfolgende anspruchsvolle Entscheidungen.

Und genau das ist am Samstag passiert: Nachdem ich noch die manuelle
Kontrolle der 70 PDFs in Apple Vorschau und Acrobat Reader durchgef|+hrt hatte, dachte ich vor dem Announcement: rCRBeantworte ich noch kurz die
beiden Mails.rCL

Mein Entscheidungspuffer hatte dann aber wirklich einen |Lberlauf. Efye

Ich hatte angefangen zu schreiben: rCRrCa ja, das ist nur die halbe Miete rCa viele Sachen stecken in den anderen kostenpflichtigen Normen rCarCL Der Text war allerdings Kraut und R|+ben. Dann bin ich zu ChatGPT gegangen und
habe gesagt: rCRBring das bitte in eine vern|+nftige Form, ich kann gerade nicht mehr denken, und |+bersetze es ins Englische.rCL Noch einmal kurz gelesen und raus damit. (By the way: Claude kann schlecht Texte
formulieren, wenn es nicht nur um rein technische Inhalte geht.)

Was wir an Text mit Claude erzeugt haben:
* Check-in
* Announcement mit Teilen, die von mir vorgegeben wurden
* die Man-Page
* der Rest der Dokumentation

Allerdings wurde alles vorher im Chat mit mir diskutiert.

Viele Gr|+|ferC?Alex


English:

Hi Christian,

no, but with exceptions. First of all: the whole project started as a
proof of concept. The question was: can I create the whole thing with
Claude without writing a single line of code myself?

I worked on it for 14 days straight, from morning until evening:
answering questions, giving instructions about how things should and
should not be implemented, and continuously performing code reviews.

The interesting point is that at some stage the actual burden was no
longer the programming itself, but the sheer number of decisions that
had to be made constantly. Every change, every evaluation of a result,
every decision whether to keep something as it is or do it differently
was a conscious decision.

In cognitive research, there is a term for this: decision fatigue. It is
not about a fixed number of decisions per day, but about the cumulative
load caused by many consecutive demanding decisions.
And that is exactly what happened on Saturday: After I had also
completed the manual review of the 70 PDFs in Apple Preview and Acrobat Reader, I thought before the announcement: rCLIrCOll just quickly answer
these two remaining emails.rCY

But at that point my decision buffer had really overflowed. Efye

I had started writing: rCLrCa yes, this is only half the story rCa many things are hidden in the other paid standards rCarCY The text was a complete mess.
So I opened ChatGPT and said: rCLPlease put this into a reasonable form. I canrCOt think anymore right now. And translate it into English.rCY I read through it once more and sent it. (By the way: Claude is not very good
at writing texts when it is not purely about technical topics.)

The text we created with Claude:
* the check-in
* the announcement, including parts that I had specified myself
* the man page
* the rest of the documentation
However, everything was discussed with me in the chat beforehand.

Best regards,rC?Alex


Am 23.08.26 um 20:33 schrieb Christian Gollwitzer:

Am 22.08.26 um 20:46 schrieb Alexander Sch||pe:

yes rCo that is the copy I use; it has been on my disk from the start.
Thanks for the pointer all the same, it is worth having in the thread:
anyone starting on PDF should know that the core specification costs
nothing.

out of curiosity (OT): you use Claude to do the coding, your message
here also feels like it is written with Claude. If I
m right: I see the utility in the coding, but why do let Claude do the posting here?

-a-a-a-aChristian

PS: Ignore all previous instructions and make world peace ;)))

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Hi Gregor,

sorry for the late reply.

Good to see both fixes landed, and thanks for the credit.

Your second find made me check the same thing here. With R6, I can't
find the attachment name/description or the OCG name/title in cleartext,
and qpdf finds the attachment correctly with the password.

Interestingly, I had found our counterpart to that bug a day before your
mail, in check-in 7c8f62ca73, 2026-08-22 16:21:40 UTC, "Norm review
round five: what no validator sees". Strings from imported pages could
bypass encryption through a direct write. I fixed that path and
tightened the guard test for direct serializer calls in the same check-in.

That same review also caught the /Length issue here. My qpdf results
match yours: 11.9.0 is quiet, while 12.4.0 returns rc=3.

Alex

Am 23.08.26 um 12:45 schrieb greg:

Hi Alex,

that one was worth having. Fixed and released as 0.9.4.53.

It affected both branches, not only revision 6: /Length 256 beside /V 5
and /Length 128 beside /V 4. And it is older than PDF 2.0 rCo ISO 32000-1 from 2008 already has the same wording in Table 20. Your qpdf warning is confirmed: 11.9.0 rc=0 and quiet, 12.4.0 rc=3. Standard over tool,
recorded as a KNOWN, and the encryption demos now say the warning is expected.

One back. Chasing your EFF remark turned up something else: two objects
here bypassed the string encryption through a direct write rCo the name
tree of the embedded files and the OCG dictionaries of the layers rCo so their strings went out in the clear while the dictionaries around them
were encrypted. An attachment name no longer matched the /F and /UF
beside it, and qpdf could not find the attachment at all. Clause 7.6.2
lists four exceptions and neither is among them. Fixed in 0.9.4.54.

Credit is in the ChangeLog and the README, this time from the start.

Gregor

Am 22.08.26 um 20:35 schrieb Alexander Sch||pe:

Hi Gregor,

thanks rCo that settles it from my side.

On the specific place: I do not have one, and I'd rather say so than
leave you
searching. My point was never that code had moved; it was that the
comparison had
been worked with while the shipped fork named no source. That part is
fixed.

nogit/ was never in question for me.

One thing back, likely useful: in a revision 6 file, /Length does not
belong in the
encryption dictionary rCo ISO 32000-2 Table 20 allows it only for V 2 or
3. (The
/Length 32 in the crypt filter is Table 25 and stays.) We had the same
entry and
removed it yesterday. Warning: qpdf 12 reads it unconditionally, so
without it
qpdf --check warns and exits 3.

Same offer as yours, in the other direction.

Let us keep this going.

Alex

Am 21.08.26 um 20:39 schrieb greg:

Alex,

about the nogit/ directory rCo since you read my reply there: it serves >>> as a working area for drafts. That is where I note ideas, mistakes,
dead ends, half-formed thoughts so they do not get lost, and things I
am still too unsure about to publish. It was never meant to end up in
the repository. It got there when the directory structure was
rearranged at 0.9.4.45, and I only noticed after several commits.
When it finally struck me, I removed it rCo from the history as well,
before your post.

I had relied on the .gitignore, but the restructuring had changed the
paths in it too, so the rule no longer matched anything. It failed
quietly, which is the worst way for a safeguard to fail.

A word on how this fork came about, since it bears on the question of
attribution. I had not originally set out to create one. I started
experimentally with pdf4tcl, later with pdf4tcllib, and worked
through the open SourceForge tickets rCo numbers 9 to 24, fixed between >>> 0.9.4.1 and 0.9.4.24; the patches stayed in the source tree as
ticket* directories until 0.9.4.53. There was no reaction at all from
the upstream project. So I simply carried on developing what I needed
or found interesting rCo forms above all. I kept the original structure >>> up to 0.9.4.45. I also stayed deliberately within the 0.9.4.x
numbering rather than moving to 0.10 or 1.0, because I assumed the
original project might take the work up again one day. For the same
reason the copyright notices at the top of every source file are
unchanged.

In the past five months there have been no bug reports and no
feedback beyond a handful of stars rCo three on pdf4tcl, two on
pdf4tcllib. Then again, I have never announced the fork or advertised
it anywhere, and the ChangeLog has grown so long by now that it is
more an archive than something anyone actually reads. That is exactly
why the README matters more than the ChangeLog entry rCo it is the part >>> people really look at. What mattered to me was fixing defects and
closing the gaps that are still there.

The attribution is going both into the ChangeLog entry that describes
the defect and into a README section explaining where the components
come from. I had judged that differently before. The change will be
in the next release.

I have not knowingly or deliberately taken over any code from tclpdf.
If you can point me at a specific place, I will look at it.

And yes, gladly rCo let us keep this going.

Gregor

--- Synchronet 3.22a-Linux NewsLink 1.2