From Newsgroup: comp.lang.tcl

ANNOUNCE: tclpdf 1.0 released
=============================

tclpdf is a pure Tcl extension for creating PDF documents: pages and
graphics, embedded TrueType fonts subset to the glyphs actually used,
JPEG and PNG images, tables, and electronic invoices as ZUGFeRD /
Factur-X in PDF/A-3B. Developed by Alexander Schoepe, it requires only
Tcl 8.6.11+ and runs under Tcl 9 as well; zlib is a built-in command
rather than a package, and Tk is not used.

1.0 is the first release.

Download / Repository: https://fossil.sowaswie.de/tclpdf


English
-------

Highlights:

* Documents are TclOO objects with Tcl-style options throughout - "$doc
text ... -at {20 30} -size 12" - and the topical modules load on first
use, so a caller who only writes text never loads the image, table or
SVG code.
* Graphics: paths, rectangles with rounded corners, circles, ellipses, polygons and Beziers, clipping to a rectangle or to an arbitrary path, transformations about a fixed point, constant alpha, tiling patterns,
axial and radial shadings, RGB / CMYK / grey / separation colours and
147 colour names resolved without Tk.
* Fonts: the fourteen standard faces, and TrueType embedded as Type0/CIDFontType2 with Identity-H and a ToUnicode CMap so the text
stays copyable and searchable - subset to the glyphs actually used,
measured at 8664 bytes from a 757076-byte face in 0.9 ms. A character
the font has no glyph for raises an error instead of disappearing silently.
* Images: JPEG and PNG go in unchanged wherever possible - a JPEG as /DCTDecode, a PNG without alpha as /FlateDecode with /Predictor 15,
neither ever decoded. Only an alpha channel is separated out, at 338 ms
for 640 by 480; extracted and compared pixel by pixel against the
originals, colour, alpha and palette match exactly.
* Tables: column widths, cell wrapping, page breaks with repeated header
and footer rows, rowSpan and colSpan, alignment on the decimal separator measured across head, body and foot together, four hooks per cell, and a
group spanning several rows moves to the next page as a whole.
* SVG: shapes, paths, transforms, groups, reuse, viewBox and gradients
become PDF path operators rather than a rasterised picture, so a logo
stays sharp at any zoom and the file stays small.
* Electronic invoices: ZUGFeRD / Factur-X as PDF/A-3B with ICC profile, OutputIntent, XMP carrying the Factur-X extension schema, embedded XML,
file specification, /AF entry and name tree. The conformance level is
read from BT-24 of the invoice rather than taken on trust, and both
example invoices pass veraPDF for PDF/A-3B.
* File attachments are a core feature rather than an invoice special
case, so a document can carry several, each with its own relationship, description and modification date.
* Form XObjects store a drawing once and place it as often as wanted, at
any scale, rotation or opacity - a logo on five pages is embedded once.
* Output goes to a file with "$doc write" or straight into an open
channel with "$doc writeChannel", which is what a CGI response or a
socket needs.
* The document language ("$doc language de-DE") reaches the catalog as
/Lang, checked against RFC 3066.

Notes:

* Tested against Tcl 8.6.18 and Tcl 9.0.4 on macOS: 328 tests green
under both, 18 examples writing 20 documents, every one of them accepted
by "qpdf --check".
* tdom is optional and used by the SVG module when present: it parses 27
to 48 times faster than the parser tclpdf brings along and refuses an
entity expansion bomb. Without it SVG still works, through the built-in element tree parser. Nothing else is optional, because nothing else is used.
* Build in the source directory. A separate build directory configures
cleanly but cannot run the tests, because the generated pkgIndex.tcl
locates the modules through $dir while the sources stay where they are. Nothing is lost by building in-tree - "make install" puts index and
modules together again either way.
* Write a document once. A second "$doc write" builds a second set of
objects on top of the first, so the file stays valid and renders
correctly but carries the earlier objects along unreferenced.
* No font is part of the package. The faces under examples/assets/fonts
exist so that the tests and examples have something to embed and travel
in the source archive alone; "make install" installs none. Whether you
may embed a font into a PDF that tclpdf writes is a question for that
font's licence, not for this one.
* Progressive JPEG and interlaced (Adam7) PNG are refused with a message naming the reason and the way out. A progressive JPEG cannot be passed
through as /DCTDecode at all - ISO 32000-1 7.4.8 does not cover it - and
an interlaced PNG would have to be decoded and re-encoded, which is a different feature. Save the file baseline or non-interlaced.
* What tclpdf covers is roughly a third of ISO 32000-1, weighted by the
page count of its chapters. The remainder is almost entirely what a
reader of foreign PDFs needs rather than a writer; encryption, form
fields (AcroForm), tagged PDF and multimedia are not implemented.

Planned:

* Reading foreign PDFs, so that an existing letterhead can be taken over
as a background instead of being rebuilt. That needs the parser side of
the format - cross-reference and object streams above all, plus the
filters a writer never emits (LZW, CCITT, RunLength) - and it is the
largest single piece still ahead.
* Encryption. The standard security handler needs MD5 and either RC4 or
AES, and none of them is available here without either a rebuilt TclTLS
or a pure-Tcl implementation shipped along; which of the two it becomes
is still open. Note that PDF/A-3 and therefore ZUGFeRD forbid encryption anyway.
* Barcodes, QR codes and EPC-QR in particular, so that an invoice can
carry a payment code a bank app scans off the page.
* OpenType with CFF outlines (CIDFontType0). TrueType outlines are
embedded today; a face that carries its glyphs as CFF has no glyf table,
and the whole subsetting path builds on that one - so it is a route of
its own rather than a small addition.
* Kerning from the kern table or GPOS. The setting is metrically correct
today but not optically balanced, which shows in headings on pairs like
AV, To and Ta.
* Tagged PDF, and with it PDF/A-3a and PDF/UA. PDF/A-3b is what ZUGFeRD
asks for and what is delivered; the accessible levels need a structure
tree that does not exist yet. The document language is already written.

* Drawing a Tk canvas into a PDF - every item type, as vectors rather
than as a screenshot. This is the one planned feature that involves Tk
at all, and it stays outside the core: a caller who has a canvas has
loaded Tk already, while the package itself neither requires nor loads
it. Its postscript method is the alternative today, and it produces PostScript, not PDF.

None of this is promised for a particular release, and nothing on the
list is needed for what 1.0 does.


Deutsch
-------

Neuerungen:

* Dokumente sind TclOO-Objekte mit durchgaengig Tcl-eigenen Optionen -
"$doc text ... -at {20 30} -size 12" -, und die Themenmodule laden beim
ersten Gebrauch, sodass ein Aufrufer, der nur Text schreibt, den Bild-, Tabellen- und SVG-Code nie laedt.
* Grafik: Pfade, Rechtecke mit runden Ecken, Kreise, Ellipsen, Polygone
und Bezierkurven, Beschneiden auf ein Rechteck oder einen beliebigen
Pfad, Transformationen um einen festen Punkt, konstante Deckung,
Kachelmuster, axiale und radiale Verlaeufe, RGB / CMYK / Grau /
Schmuckfarben und 147 Farbnamen ohne Tk.
* Schriften: die vierzehn Standardschnitte, dazu TrueType eingebettet
als Type0/CIDFontType2 mit Identity-H und ToUnicode-CMap, damit der Text kopierbar und durchsuchbar bleibt - reduziert auf die tatsaechlich
benutzten Glyphen, gemessen 8664 Byte aus einer 757076 Byte grossen
Schrift in 0,9 ms. Ein Zeichen, fuer das die Schrift keine Glyphe hat,
ist ein Fehler und verschwindet nicht stillschweigend.
* Bilder: JPEG und PNG gehen unveraendert hinein, wo immer es geht - ein
JPEG als /DCTDecode, ein PNG ohne Alpha als /FlateDecode mit /Predictor
15, keines von beiden wird je dekodiert. Nur ein Alphakanal wird herausgeloest, in 338 ms fuer 640 mal 480; extrahiert und pixelweise
gegen die Originale gehalten stimmen Farbe, Alpha und Palette exakt
ueberein.
* Tabellen: Spaltenbreiten, Zellenumbruch, Seitenumbruch mit
wiederholtem Kopf und Fuss, rowSpan und colSpan, Ausrichtung am Dezimaltrennzeichen ueber Kopf, Rumpf und Fuss gemeinsam gemessen, vier
Haken je Zelle, und eine ueber mehrere Zeilen laufende Gruppe wandert geschlossen auf die naechste Seite.
* SVG: Formen, Pfade, Transformationen, Gruppen, Wiederverwendung,
viewBox und Verlaeufe werden zu PDF-Pfadoperatoren statt zu einem
gerasterten Bild, sodass ein Logo bei jeder Vergroesserung scharf bleibt
und die Datei klein.
* Elektronische Rechnungen: ZUGFeRD / Factur-X als PDF/A-3B mit
ICC-Profil, OutputIntent, XMP samt Factur-X-Erweiterungsschema,
eingebetteter XML, Dateispezifikation, /AF-Eintrag und Namensbaum. Die Konformitaetsstufe wird aus BT-24 der Rechnung gelesen statt geglaubt,
und beide Beispielrechnungen bestehen veraPDF fuer PDF/A-3B.
* Dateianhaenge sind eine Kernfunktion und kein Rechnungs-Sonderfall,
deshalb kann ein Dokument mehrere tragen, jeden mit eigener Beziehung, Beschreibung und Aenderungszeit.
* Form-XObjects speichern eine Zeichnung einmal und platzieren sie
beliebig oft, in jeder Groesse, Drehung und Deckung - ein Logo auf fuenf Seiten wird einmal eingebettet.
* Die Ausgabe geht mit "$doc write" in eine Datei oder mit "$doc
writeChannel" direkt in einen offenen Kanal, was eine CGI-Antwort oder
ein Socket braucht.
* Die Dokumentsprache ("$doc language de-DE") landet als /Lang im
Katalog, geprueft gegen RFC 3066.

Hinweise:

* Geprueft gegen Tcl 8.6.18 und Tcl 9.0.4 unter macOS: 328 Tests gruen
unter beiden, 18 Beispiele mit 20 Dokumenten, jedes davon von "qpdf
--check" angenommen.
* tdom ist optional und wird vom SVG-Modul benutzt, wenn es vorhanden
ist: es parst 27- bis 48-mal schneller als der mitgelieferte Parser und
wehrt eine Entity-Bombe ab. Ohne tdom laeuft SVG weiter, ueber den
eingebauten Elementbaum-Parser. Sonst ist nichts optional, weil sonst
nichts benutzt wird.
* Im Quellverzeichnis bauen. Ein eigenes Bauverzeichnis konfiguriert
sauber, kann die Tests aber nicht ausfuehren, weil die erzeugte
pkgIndex.tcl die Module ueber $dir sucht, waehrend die Quellen liegen
bleiben. In-tree geht nichts verloren - "make install" legt Index und
Module ohnehin wieder zusammen.
* Ein Dokument einmal schreiben. Ein zweites "$doc write" baut einen
zweiten Satz Objekte auf den ersten, sodass die Datei gueltig bleibt und richtig dargestellt wird, die frueheren Objekte aber unreferenziert
mitreist.
* Keine Schrift gehoert zum Paket. Die Schnitte unter
examples/assets/fonts sind da, damit Tests und Beispiele etwas zum
Einbetten haben, und reisen allein im Quellarchiv mit; "make install" installiert keine. Ob eine Schrift in ein von tclpdf geschriebenes PDF eingebettet werden darf, entscheidet die Lizenz jener Schrift, nicht
diese hier.
* Progressive JPEG und verschraenktes (Adam7) PNG werden mit einer
Meldung abgelehnt, die Grund und Ausweg nennt. Ein progressives JPEG
laesst sich ueberhaupt nicht als /DCTDecode durchreichen - ISO 32000-1
7.4.8 deckt es nicht ab -, und ein verschraenktes PNG muesste dekodiert
und neu kodiert werden, was eine andere Funktion waere. Die Datei
baseline beziehungsweise nicht verschraenkt speichern.
* Was tclpdf abdeckt, ist rund ein Drittel von ISO 32000-1, gewichtet
nach dem Seitenumfang der Kapitel. Der Rest ist fast durchweg das, was
ein Leser fremder PDFs braucht und kein Schreiber; Verschluesselung, Formularfelder (AcroForm), Tagged PDF und Multimedia sind nicht umgesetzt.

Geplant:

* Fremde PDFs lesen, damit ein vorhandener Briefbogen als Hintergrund uebernommen statt nachgebaut wird. Dafuer fehlt die Leseseite des
Formats - vor allem Querverweis- und Objektstroeme, dazu die Filter, die
ein Schreiber nie erzeugt (LZW, CCITT, RunLength) - und es ist der
groesste noch offene Einzelposten.
* Verschluesselung. Der Standard-Sicherheitshandler braucht MD5 und dazu
RC4 oder AES, und keines davon ist hier zu haben ohne ein neu gebautes
TclTLS oder eine mitgelieferte Umsetzung in reinem Tcl; welcher der
beiden Wege es wird, ist offen. Zu beachten: PDF/A-3 und damit ZUGFeRD verbieten Verschluesselung ohnehin.
* Barcodes, insbesondere QR und EPC-QR, damit eine Rechnung einen
Zahlungscode tragen kann, den eine Bank-App vom Beleg scannt.
* OpenType mit CFF-Umrissen (CIDFontType0). Eingebettet werden heute TrueType-Umrisse; eine Schrift, die ihre Glyphen als CFF fuehrt, hat
keine glyf-Tabelle, und der ganze Subset-Weg baut auf genau dieser auf -
das ist also ein eigener Weg und keine kleine Ergaenzung.
* Kerning aus der kern-Tabelle oder GPOS. Der Satz ist heute metrisch
richtig, aber nicht optisch ausgeglichen, was in Ueberschriften bei
Paaren wie AV, To und Ta auffaellt.
* Tagged PDF und damit PDF/A-3a und PDF/UA. Geliefert wird PDF/A-3b, das ZUGFeRD verlangt; die barrierefreien Stufen brauchen einen Strukturbaum,
den es noch nicht gibt. Die Dokumentsprache wird bereits geschrieben.

* Ein Tk-Canvas ins PDF zeichnen - jeder Elementtyp, als Vektoren statt
als Bildschirmfoto. Das ist das einzige geplante Merkmal, in dem Tk
ueberhaupt vorkommt, und es bleibt ausserhalb des Kerns: wer einen
Canvas hat, hat Tk ohnehin geladen, waehrend das Paket selbst es weder verlangt noch laedt. Heute bleibt dafuer nur dessen postscript-Methode,
und die liefert PostScript, kein PDF.

Nichts davon ist fuer eine bestimmte Fassung zugesagt, und nichts auf
dieser Liste wird fuer das gebraucht, was 1.0 leistet.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* Alexander Schöpe <[email protected]>
| ANNOUNCE: tclpdf 1.0 released
| =============================

| tclpdf is a pure Tcl extension for creating PDF documents: pages and
| graphics, embedded TrueType fonts subset to the glyphs actually used,
| JPEG and PNG images, tables, and electronic invoices as ZUGFeRD /
| Factur-X in PDF/A-3B. Developed by Alexander Schoepe, it requires only
| Tcl 8.6.11+ and runs under Tcl 9 as well; zlib is a built-in command
| rather than a package, and Tk is not used.

Simply awesome!

| Highlights:
--<snip-snip>--
| * Images: JPEG and PNG go in unchanged wherever possible - a JPEG as
| /DCTDecode, a PNG without alpha as /FlateDecode with /Predictor 15,
| neither ever decoded.

How much work would it be to support EPS (Encapsulated PostScript) as
well? Sounds silly, I know, 'but'... :-)

R'
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 11.08.26 um 14:25 schrieb Ralf Fassel:

* Alexander Schöpe <[email protected]>
| ANNOUNCE: tclpdf 1.0 released
| =============================

| tclpdf is a pure Tcl extension for creating PDF documents: pages and
| graphics, embedded TrueType fonts subset to the glyphs actually used,
| JPEG and PNG images, tables, and electronic invoices as ZUGFeRD /
| Factur-X in PDF/A-3B. Developed by Alexander Schoepe, it requires only
| Tcl 8.6.11+ and runs under Tcl 9 as well; zlib is a built-in command
| rather than a package, and Tk is not used.

Simply awesome!

| Highlights:
--<snip-snip>--
| * Images: JPEG and PNG go in unchanged wherever possible - a JPEG as
| /DCTDecode, a PNG without alpha as /FlateDecode with /Predictor 15,
| neither ever decoded.

How much work would it be to support EPS (Encapsulated PostScript) as
well? Sounds silly, I know, 'but'... :-)

R'

Hi Ralf,

Thanks! 🙂

EPS is indeed an interesting special case. I have looked into it in more detail now. The short answer is: embedding EPS is not really the
difficult part — understanding its contents is.

EPS contains PostScript, which is a program rather than a description of
the image in the way PDF or SVG is. In one particular Illustrator file I looked at, the 658 KB of PostScript consist to a large extent of a
private prologue with hundreds of definitions and various control-flow constructs. To get the actual graphics out of it, tclpdf would
essentially have to execute the PostScript.

I also compared two EPS files from different producers. Both define
their own shorthand procedures; of the 25 and 7 procedures respectively,
there is not a single one in common. So a small parser supporting a
handful of the “usual” EPS commands would not really be a viable solution.

A natural idea would be to simply embed the PostScript in the PDF. PDF
1.7 did in fact allow this through an XObject with /Subtype /PS.
However, ISO 32000-1 already says in §8.8.1 that “PostScript XObjects should not be used”. §8.8.2 explains why: such fragments “shall have no effect either when viewing the document on-screen or when printing it to
a non-PostScript device”. And in ISO 32000-2 (PDF 2.0), PostScript
XObjects do not occur at all; they are no longer part of the specification.

The EPS preview does not really solve the problem either. It is just a
raster image and therefore cannot provide the quality of the original
vector graphics.

Converting EPS to PDF or SVG, on the other hand, works perfectly well.
That is probably the approach I would recommend: convert the EPS
beforehand with a suitable tool and give tclpdf the result. I don’t want
to make a PostScript interpreter a dependency of tclpdf.

So: technically possible, but for tclpdf EPS support would not really be another image importer — it would essentially mean adding a PostScript interpreter. 🙂
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Hi Ralf,

tclpdf can be extended without touching its core. You can add custom functionality such as letterheads, stamps, document data or other PDF
features using the event system and extension API.

I’ve added a short guide with examples here: https://fossil.sowaswie.de/tclpdf/wiki?name=plugins

Alex
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

+1 !

In general, happy to see the barrage of new package releases on c.l.t in
the past month or so :-)

On 8/11/2026 5:55 PM, Ralf Fassel wrote:

* Alexander Schöpe <[email protected]>
| ANNOUNCE: tclpdf 1.0 released
| =============================

Simply awesome!

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* Alexander Schöpe <[email protected]>
| Am 11.08.26 um 14:25 schrieb Ralf Fassel:
| > * Alexander Schöpe <[email protected]>
| > | ANNOUNCE: tclpdf 1.0 released
| > | =============================
| > --<snip-snip>--
| > | * Images: JPEG and PNG go in unchanged wherever possible - a JPEG as
| > | /DCTDecode, a PNG without alpha as /FlateDecode with /Predictor 15,
| > | neither ever decoded.
| > How much work would it be to support EPS (Encapsulated PostScript)
| > as well?
--<snip-snip>--
| EPS is indeed an interesting special case. I have looked into it in
| more detail now. The short answer is: embedding EPS is not really the
| difficult part — understanding its contents is.

...in my special case it would add a bitmapped picture inside the EPS
encoded as a giant hex string :-)

| A natural idea would be to simply embed the PostScript in the PDF.
| PDF 1.7 did in fact allow this through an XObject with /Subtype /PS.

That's what I had hoped for...

| However, ISO 32000-1 already says in §8.8.1 that “PostScript
| XObjects should not be used”. §8.8.2 explains why: such fragments
| “shall have no effect either when viewing the document on-screen or
| when printing it to a non-PostScript device”. And in ISO 32000-2 (PDF
| 2.0), PostScript XObjects do not occur at all; they are no longer part
| of the specification.

:-/

| Converting EPS to PDF or SVG, on the other hand, works perfectly
| well. That is probably the approach I would recommend: convert the EPS
| beforehand with a suitable tool and give tclpdf the result.

d'accord.

| I don’t want to make a PostScript interpreter a dependency of tclpdf.

I agree, that's too complicated.

Thanks for all your contributions to TCL!
R'
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Ah, I see. In your particular case, the EPS may indeed contain a bitmap
image as a large hexadecimal string.

To extract that image reliably from an arbitrary EPS, however, a
PostScript interpreter is still necessary. EPS is PostScript code, so
even if the actual image data is just a bitmap, the surrounding
PostScript may determine how the data is decoded and rendered.

The easiest approach is therefore to convert the EPS beforehand, for
example with Ghostscript, and then give the resulting file to tclpdf. If
the EPS contains bitmap data, it could for example be converted to PNG:

gs -dSAFER -dBATCH -dNOPAUSE \
-sDEVICE=pngalpha \
-r300 \
-sOutputFile=output.png \
input.eps

If it contains vector graphics and those should be preserved, converting
it to PDF would be preferable:

gs -dSAFER -dBATCH -dNOPAUSE \
-sDEVICE=pdfwrite \
-sOutputFile=output.pdf \
input.eps

ImageMagick can also process EPS, but it uses Ghostscript for the actual PostScript interpretation.

I also think EPS support would be better suited to an optional tclpdf
plugin rather than the tclpdf core. tclpdf is designed to be extended
this way, for example for letterheads, stamps, document data or other
PDF features. I have added a short guide with examples here:

https://fossil.sowaswie.de/tclpdf/wiki?name=plugins

EPS is also increasingly a legacy format for this purpose. Adobe still supports EPS as an input format for conversion, but recommends
converting EPS to PDF for sharing and viewing, since EPS requires
special software to interpret the PostScript content.

There is also a technical reason why I would not try to embed the
PostScript directly in a PDF. PDF 1.7 had PostScript XObjects, but the specification already discouraged their use. PDF 2.0 removed PostScript XObjects from the specification completely.

In addition, I am currently still working on implementing the PDF specification up to PDF 2.0 in tclpdf, including things like proper font handling and kerning. I would therefore rather keep the tclpdf core
focused on the PDF standard itself and put specialized legacy formats
such as EPS into optional plugins.

So my preference would be either to convert EPS to PDF/PNG/SVG
beforehand, or to provide EPS handling as an optional plugin. In either
case, the tclpdf core would remain independent of a PostScript interpreter.

Thanks again for the suggestion! 🙂

Alex


Am 13.08.26 um 10:55 schrieb Ralf Fassel:

* Alexander Schöpe <[email protected]>
| Am 11.08.26 um 14:25 schrieb Ralf Fassel:
| > * Alexander Schöpe <[email protected]>
| > | ANNOUNCE: tclpdf 1.0 released
| > | =============================
| > --<snip-snip>--
| > | * Images: JPEG and PNG go in unchanged wherever possible - a JPEG as
| > | /DCTDecode, a PNG without alpha as /FlateDecode with /Predictor 15,
| > | neither ever decoded.
| > How much work would it be to support EPS (Encapsulated PostScript)
| > as well?
--<snip-snip>--
| EPS is indeed an interesting special case. I have looked into it in
| more detail now. The short answer is: embedding EPS is not really the
| difficult part — understanding its contents is.

...in my special case it would add a bitmapped picture inside the EPS
encoded as a giant hex string :-)

| A natural idea would be to simply embed the PostScript in the PDF.
| PDF 1.7 did in fact allow this through an XObject with /Subtype /PS.

That's what I had hoped for...

| However, ISO 32000-1 already says in §8.8.1 that “PostScript
| XObjects should not be used”. §8.8.2 explains why: such fragments
| “shall have no effect either when viewing the document on-screen or
| when printing it to a non-PostScript device”. And in ISO 32000-2 (PDF
| 2.0), PostScript XObjects do not occur at all; they are no longer part
| of the specification.

:-/

| Converting EPS to PDF or SVG, on the other hand, works perfectly
| well. That is probably the approach I would recommend: convert the EPS
| beforehand with a suitable tool and give tclpdf the result.

d'accord.

| I don’t want to make a PostScript interpreter a dependency of tclpdf.

I agree, that's too complicated.

Thanks for all your contributions to TCL!
R'

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 8/10/2026 10:24 AM, Alexander Schöpe wrote:

ANNOUNCE: tclpdf 1.0 released
=============================

tclpdf is a pure Tcl extension for creating PDF documents: pages and graphics, embedded TrueType fonts subset to the glyphs actually used,
JPEG and PNG images, tables, and electronic invoices as ZUGFeRD /
Factur-X in PDF/A-3B. Developed by Alexander Schoepe, it requires only
Tcl 8.6.11+ and runs under Tcl 9 as well; zlib is a built-in command
rather than a package, and Tk is not used.

1.0 is the first release.

Awesome!

A frequent need is to sometimes create a new PDF out of many different documents. So you add take a screenshot, one or two text documents, some images, etc. and put them all in one single pdf (not as attachments) so
your boss can read all without boethring with unzipping, opening and
closing multiple documents, and getting lost in the order they need to
look at it.

Does it currently have a command to do this?


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Not yet for existing PDF documents. PDF page import is something I want
to add, but I don’t have a timeline for it yet.

The rest of your use case already works. You can create a new PDF and
add text, screenshots, JPEG/PNG images, SVG graphics, tables, etc. as
separate pages or as content on the same page.

For example:

screenshot.png
text
image.jpg
table
SVG
│
▼
tclpdf
│
▼
combined.pdf

The missing part is importing an already existing PDF and copying its
pages into the new document. That requires considerably more PDF parsing functionality than tclpdf currently has.

PDF import is therefore planned as a future feature, but I cannot say
yet when it will be available.

So for now, if you have the source material available as images, text,
SVG, etc., tclpdf can already build the combined PDF. For existing PDFs,
you would currently need an external PDF tool such as qpdf to merge them.

And yes, this is a good use case for tclpdf. 🙂

Am 13.08.26 um 18:15 schrieb saito:

On 8/10/2026 10:24 AM, Alexander Schöpe wrote:

ANNOUNCE: tclpdf 1.0 released
=============================

tclpdf is a pure Tcl extension for creating PDF documents: pages and
graphics, embedded TrueType fonts subset to the glyphs actually used,
JPEG and PNG images, tables, and electronic invoices as ZUGFeRD /
Factur-X in PDF/A-3B. Developed by Alexander Schoepe, it requires only
Tcl 8.6.11+ and runs under Tcl 9 as well; zlib is a built-in command
rather than a package, and Tk is not used.

1.0 is the first release.

Awesome!

A frequent need is to sometimes create a new PDF out of many different documents. So you add take a screenshot, one or two text documents, some images, etc. and put them all in one single pdf (not as attachments) so
your boss can read all without boethring with unzipping, opening and
closing multiple documents, and getting lost in the order they need to
look at it.

Does it currently have a command to do this?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* Alexander Schöpe <[email protected]>
| ANNOUNCE: tclpdf 1.0 released
| =============================

| tclpdf is a pure Tcl extension for creating PDF documents: pages and
| graphics, embedded TrueType fonts subset to the glyphs actually used,
| JPEG and PNG images, tables, and electronic invoices as ZUGFeRD /
| Factur-X in PDF/A-3B. Developed by Alexander Schoepe, it requires only
| Tcl 8.6.11+ and runs under Tcl 9 as well; zlib is a built-in command
| rather than a package, and Tk is not used.

| 1.0 is the first release.

| Download / Repository: https://fossil.sowaswie.de/tclpdf

Though it seems obvious for the experienced user, a (short) section in
the documentation about how to install the downloaded tclpdf1.0.tar.gz
would be nice.

Also is there a specific reason why many of the tarfile contents are
mode 600 (should be 644 IMHO)? This leads to all kind of trouble when unpacking the distribution at the final destination.

drwxrwxr-x alex/staff 0 tclpdf1.0/
-rw------- alex/staff 18437 tclpdf1.0/table.tcl
-rw-r--r-- alex/staff 12844 tclpdf1.0/otLayout.tcl
-rw------- alex/staff 16722 tclpdf1.0/svg.tcl
-rw------- alex/staff 12190 tclpdf1.0/shading.tcl
-rw------- alex/staff 26237 tclpdf1.0/text.tcl
-rw------- alex/staff 9883 tclpdf1.0/subset.tcl
-rw------- alex/staff 11846 tclpdf1.0/image.tcl
-rw------- alex/staff 6120 tclpdf1.0/imageJpeg.tcl
-rw-r--r-- alex/staff 8069 tclpdf1.0/kernGpos.tcl
-rw------- alex/staff 7566 tclpdf1.0/tableDraw.tcl
-rw-r--r-- alex/staff 12079 tclpdf1.0/page.tcl
[...]

R'
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Hi Ralf,

No, I hadn’t noticed that yet. It is most likely caused by my umask,
which apparently results in the files being created with mode 600.

I’ll fix that for the next release. I’ll also add a short section to the documentation explaining how to install the downloaded tarball.

Thanks for pointing this out!

Best,
Alex

Am 14.08.26 um 15:37 schrieb Ralf Fassel:

* Alexander Schöpe<[email protected]>
| ANNOUNCE: tclpdf 1.0 released
| =============================
| tclpdf is a pure Tcl extension for creating PDF documents: pages and
| graphics, embedded TrueType fonts subset to the glyphs actually used,
| JPEG and PNG images, tables, and electronic invoices as ZUGFeRD /
| Factur-X in PDF/A-3B. Developed by Alexander Schoepe, it requires only
| Tcl 8.6.11+ and runs under Tcl 9 as well; zlib is a built-in command
| rather than a package, and Tk is not used.
| 1.0 is the first release.
| Download / Repository:https://fossil.sowaswie.de/tclpdf

Though it seems obvious for the experienced user, a (short) section in
the documentation about how to install the downloaded tclpdf1.0.tar.gz
would be nice.

Also is there a specific reason why many of the tarfile contents are
mode 600 (should be 644 IMHO)? This leads to all kind of trouble when unpacking the distribution at the final destination.

drwxrwxr-x alex/staff 0 tclpdf1.0/
-rw------- alex/staff 18437 tclpdf1.0/table.tcl
-rw-r--r-- alex/staff 12844 tclpdf1.0/otLayout.tcl
-rw------- alex/staff 16722 tclpdf1.0/svg.tcl
-rw------- alex/staff 12190 tclpdf1.0/shading.tcl
-rw------- alex/staff 26237 tclpdf1.0/text.tcl
-rw------- alex/staff 9883 tclpdf1.0/subset.tcl
-rw------- alex/staff 11846 tclpdf1.0/image.tcl
-rw------- alex/staff 6120 tclpdf1.0/imageJpeg.tcl
-rw-r--r-- alex/staff 8069 tclpdf1.0/kernGpos.tcl
-rw------- alex/staff 7566 tclpdf1.0/tableDraw.tcl
-rw-r--r-- alex/staff 12079 tclpdf1.0/page.tcl
[...]

R'

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On Mon, 10 Aug 2026 16:24:24 +0200, Alexander Schöpe wrote:

ANNOUNCE: tclpdf 1.0 released

[snip]

I tried this out and found it easy to install and easy to use.

However, I've had a problem printing a Unicode character.

Early in my code I have:

set pdf [tclpdf new -format a4 -unit mm -orientation portrait]
try {
$pdf page add
$pdf font embed freesans [file home]/.fonts/FreeSans.ttf

then later on I try to output a ✔ symbol:

$pdf font -family freesans -size 22 -color black
$pdf text ✔ -at [list [expr {2.5 + $x}] [expr {8.5 + $y}]]

But it gives me an error:

tclpdf: the font "freesans" has no glyph for U+2714 (position 0) - it cannot be written with this face
while executing
"my FontEncode $font $string"
(class "::tclpdf::document::document" method "TextEncode" line 3)
invoked from within
"my TextEncode $font $string"
(class "::tclpdf::document::document" method "TextRun" line 33)
invoked from within
"my TextRun $string $state $x $y [dict get $options rotate]"
(class "::tclpdf::document::document" method "text" line 53)
invoked from within
"$pdf text ✔ -at [list [expr {2.5 + $x}] [expr {8.5 + $y}]]"

However, I know that this glyph is in FreeSans.ttf because I have a little program, fontviewer.tk, which shows it to me; here's a line of its output
that uses the FreeSans font:
FreeSans: QO01liI ✘ ✔ 🗹 • … The quick brown fox jumped over the lazy dogs

I don't know if it is relevant but all the other text in the PDF is written using the built-in Helvetica font.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Thank you for trying tclpdf, and for the clear report.

The cause is the font file itself: FreeSans.ttf does not contain U+2714
(heavy check mark). I checked the last GNU FreeFont release, 2012-05-03,
and it is not in FreeSans - nor are U+2718 (heavy ballot X) or the
ballot boxes U+2610 and U+2611. FreeSerif from the same package has all
of them, and so do DejaVu Sans and Noto Sans Symbols 2, for example.

Your viewer probably shows the character anyway because Tk, as most
screen rendering does, substitutes a glyph from another installed font
when the requested one lacks it. tclpdf cannot do that: the PDF names
the embedded font program the glyph comes from, so a character the font
does not have would appear as an empty box in the reader. That is why it
stops at the call and names the character instead.

Have you tried DejaVu Sans (or Noto Sans Symbols 2) for the symbol? A
second embed and a switch of face just for that call is all it takes, e.g.

$pdf font embed symbols /path/to/DejaVuSans.ttf
...
$pdf font -family symbols -size 22 -color black
$pdf text ✔ -at [list [expr {2.5 + $x}] [expr {8.5 + $y}]]

The face is chosen per call, so the rest of your text stays in FreeSans
(or Helvetica) as it is; FreeSerif from your FreeFont package works the
same way. If it helps, [$pdf textWidth "✔" -family freesans] gives the
same error without drawing anything, so you can check a face at start-up.

I will add a note about this to the manual - the "but my viewer shows
it" case will come up again. Thanks again for the feedback.


Am 17.08.26 um 08:55 schrieb Mark Summerfield:

On Mon, 10 Aug 2026 16:24:24 +0200, Alexander Schöpe wrote:

ANNOUNCE: tclpdf 1.0 released

[snip]

I tried this out and found it easy to install and easy to use.

However, I've had a problem printing a Unicode character.

Early in my code I have:

set pdf [tclpdf new -format a4 -unit mm -orientation portrait]
try {
$pdf page add
$pdf font embed freesans [file home]/.fonts/FreeSans.ttf

then later on I try to output a ✔ symbol:

$pdf font -family freesans -size 22 -color black
$pdf text ✔ -at [list [expr {2.5 + $x}] [expr {8.5 + $y}]]

But it gives me an error:

tclpdf: the font "freesans" has no glyph for U+2714 (position 0) - it cannot be written with this face
while executing
"my FontEncode $font $string"
(class "::tclpdf::document::document" method "TextEncode" line 3)
invoked from within
"my TextEncode $font $string"
(class "::tclpdf::document::document" method "TextRun" line 33)
invoked from within
"my TextRun $string $state $x $y [dict get $options rotate]"
(class "::tclpdf::document::document" method "text" line 53)
invoked from within
"$pdf text ✔ -at [list [expr {2.5 + $x}] [expr {8.5 + $y}]]"

However, I know that this glyph is in FreeSans.ttf because I have a little program, fontviewer.tk, which shows it to me; here's a line of its output that uses the FreeSans font:
FreeSans: QO01liI ✘ ✔ 🗹 • … The quick brown fox jumped over the lazy dogs

I don't know if it is relevant but all the other text in the PDF is written using the built-in Helvetica font.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Hi Alexander,

I embedded DejaVuSans & retried as you suggested and it worked
perfectly. (I'd forgotten that that tk "filled in" as best it
could when it needed to.)

Thank you.

On Mon, 17 Aug 2026 20:02:49 +0200, Alexander Schöpe wrote:

Thank you for trying tclpdf, and for the clear report.

The cause is the font file itself: FreeSans.ttf does not contain U+2714 (heavy check mark). I checked the last GNU FreeFont release, 2012-05-03,
and it is not in FreeSans - nor are U+2718 (heavy ballot X) or the
ballot boxes U+2610 and U+2611. FreeSerif from the same package has all
of them, and so do DejaVu Sans and Noto Sans Symbols 2, for example.

Your viewer probably shows the character anyway because Tk, as most
screen rendering does, substitutes a glyph from another installed font
when the requested one lacks it. tclpdf cannot do that: the PDF names
the embedded font program the glyph comes from, so a character the font
does not have would appear as an empty box in the reader. That is why it stops at the call and names the character instead.

Have you tried DejaVu Sans (or Noto Sans Symbols 2) for the symbol? A
second embed and a switch of face just for that call is all it takes, e.g.

$pdf font embed symbols /path/to/DejaVuSans.ttf
...
$pdf font -family symbols -size 22 -color black
$pdf text ✔ -at [list [expr {2.5 + $x}] [expr {8.5 + $y}]]

The face is chosen per call, so the rest of your text stays in FreeSans
(or Helvetica) as it is; FreeSerif from your FreeFont package works the
same way. If it helps, [$pdf textWidth "✔" -family freesans] gives the same error without drawing anything, so you can check a face at start-up.

I will add a note about this to the manual - the "but my viewer shows
it" case will come up again. Thanks again for the feedback.

[snip]
--- Synchronet 3.22a-Linux NewsLink 1.2