• ANNOUNCE: tclpdf 1.0 released

    From =?UTF-8?Q?Alexander_Sch=C3=B6pe?=@ete-sep@mxbo.de to comp.lang.tcl on Mon Aug 10 16:24:24 2026
    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 Ralf Fassel@ralfixx@gmx.de to comp.lang.tcl on Tue Aug 11 14:25:45 2026
    From Newsgroup: comp.lang.tcl

    * Alexander Sch||pe <ete-sep@mxbo.de>
    | 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 =?UTF-8?Q?Alexander_Sch=C3=B6pe?=@ete-sep@mxbo.de to comp.lang.tcl on Tue Aug 11 21:48:51 2026
    From Newsgroup: comp.lang.tcl

    Am 11.08.26 um 14:25 schrieb Ralf Fassel:
    * Alexander Sch||pe <ete-sep@mxbo.de>
    | 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! EfOe

    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 rCo 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 rCLusualrCY 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 -o8.8.1 that rCLPostScript XObjects should not be usedrCY. -o8.8.2 explains why: such fragments rCLshall have no effect either when viewing the document on-screen or when printing it to
    a non-PostScript devicerCY. 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 donrCOt 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 rCo it would essentially mean adding a PostScript interpreter. EfOe
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From =?UTF-8?Q?Alexander_Sch=C3=B6pe?=@ete-sep@mxbo.de to comp.lang.tcl on Tue Aug 11 23:12:45 2026
    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.

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

    Alex
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Ashok@apnmbx-public@yahoo.com to comp.lang.tcl on Wed Aug 12 11:16:12 2026
    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 <ete-sep@mxbo.de>
    | ANNOUNCE: tclpdf 1.0 released
    | =============================


    Simply awesome!
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Ralf Fassel@ralfixx@gmx.de to comp.lang.tcl on Thu Aug 13 10:55:34 2026
    From Newsgroup: comp.lang.tcl

    * Alexander Sch||pe <ete-sep@mxbo.de>
    | Am 11.08.26 um 14:25 schrieb Ralf Fassel:
    | > * Alexander Sch||pe <ete-sep@mxbo.de>
    | > | 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 rCo 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 -o8.8.1 that rCLPostScript
    | XObjects should not be usedrCY. -o8.8.2 explains why: such fragments
    | rCLshall have no effect either when viewing the document on-screen or
    | when printing it to a non-PostScript devicerCY. 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 donrCOt 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 =?UTF-8?Q?Alexander_Sch=C3=B6pe?=@ete-sep@mxbo.de to comp.lang.tcl on Thu Aug 13 16:40:55 2026
    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! EfOe

    Alex


    Am 13.08.26 um 10:55 schrieb Ralf Fassel:
    * Alexander Sch||pe <ete-sep@mxbo.de>
    | Am 11.08.26 um 14:25 schrieb Ralf Fassel:
    | > * Alexander Sch||pe <ete-sep@mxbo.de>
    | > | 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 rCo 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 -o8.8.1 that rCLPostScript
    | XObjects should not be usedrCY. -o8.8.2 explains why: such fragments
    | rCLshall have no effect either when viewing the document on-screen or
    | when printing it to a non-PostScript devicerCY. 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 donrCOt 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 saito@saitology9@gmail.com to comp.lang.tcl on Thu Aug 13 12:15:32 2026
    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 =?UTF-8?Q?Alexander_Sch=C3=B6pe?=@ete-sep@mxbo.de to comp.lang.tcl on Fri Aug 14 10:36:34 2026
    From Newsgroup: comp.lang.tcl

    Not yet for existing PDF documents. PDF page import is something I want
    to add, but I donrCOt 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
    roe
    ru+
    tclpdf
    roe
    ru+
    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. EfOe

    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 Ralf Fassel@ralfixx@gmx.de to comp.lang.tcl on Fri Aug 14 15:37:34 2026
    From Newsgroup: comp.lang.tcl

    * Alexander Sch||pe <ete-sep@mxbo.de>
    | 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 =?UTF-8?Q?Alexander_Sch=C3=B6pe?=@ete-sep@mxbo.de to comp.lang.tcl on Sat Aug 15 21:54:31 2026
    From Newsgroup: comp.lang.tcl

    Hi Ralf,

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

    IrCOll fix that for the next release. IrCOll 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<ete-sep@mxbo.de>
    | 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 Mark Summerfield@m.n.summerfield@gmail.com to comp.lang.tcl on Mon Aug 17 06:55:50 2026
    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 rLo symbol:

    $pdf font -family freesans -size 22 -color black
    $pdf text rLo -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 rLo -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 rLy rLo Efu| rCo rCa 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