taskGNU a2ps - Tasks: task #16517, Version 5: "a2pdf", from...


You are not allowed to post comments on this tracker with your current authentication level.

task #16517: Version 5: "a2pdf", from scratch

Submitter:  Reuben Thomas <rrt>
Submitted:  Wed 13 Mar 2024 06:39:07 PM UTC
Should Start On:  Wed 13 Mar 2024 12:00:00 AM UTC Should be Finished on:  Wed 13 Mar 2024 12:00:00 AM UTC
Category:  None Priority:  5 - Normal
Status:  None Privacy:  Public
Assigned to:  None Percent Complete:  0%
Open/Closed:  Open Effort:  0.00

Wed 13 Mar 2024 06:39:07 PM UTC, original submission:  

Having looked in detail at what should change in a major update to a2ps, I have concluded it will be easier to write a new program from scratch.

What needs to change functionality-wise:

  • Default output format should be PDF, not PostScript.
  • Input should default to UTF-8, not 8-bit encodings.
  • Fonts these days support most languages.
  • There are better 3rd-party alternatives to the built-in stylesheets system, such as GNU Source-highlight.

The implications for the code:

  • The PostScript renderer can be removed. paps ( https://github.com/dov/paps ) produces PDF and PostScript from UTF-8 text, using Pango.
  • The stylesheets system can be removed, and replaced with GNU Source-highlight; other back-ends can be used just as easily. Rather than using file(1)'s human-readable output, we should be detecting and using MIME type.
  • sheets.map and most uses of delegations can be replaced with Hulot ( https://github.com/rrthomas/Hulot ), with a suitable set of page-focussed converters configured.
  • Recode (formerly GNU Recode) can handle encoding to UTF-8 where necessary; the encodings code can be removed.
  • There's no need to include Ogonkify. Fonts have moved on.

What stays the same:

  • PSUtils version 3 now produces PDF (so can be used for PDF output), and can still be used to provide all the page manipulations.

There's little point retaining the existing code base for this, as most of the specialised code can be removed, and the above functionality exists almost entirely in 3rd-party packages. What remains is quicker to reimplement in a more suitable language than C. I suggest doing it in Python.

What's required:

  • Replicate the command-line interface. In particular, we want to be able to specify document manipulations and printing options as before.
  • Replicate the functionality for annotating and rearranging pages. In particular, PSUtils does not (yet) support page headers and footers; paps does (see above), but cannot annotate existing files. I think adding a command to the PSUtils suite to perform this functionality (and adding e.g. watermarking support) would be a good idea.
  • Replicate the table of contents functionality, with groff.

Overall, I feel this plan retains the spirit of a2ps while adapting to the landscape of the mid-2020s, other than in one important regard: it remains focussed on pages and printing, while many users read electronic, non-paginated content. That is fine, as a2ps's main purpose is to provide paginated material, and users who don't want that won't need it; typically, they can just directly open the files that a2ps would process.

Reuben Thomas <rrt>
Group administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by rrt (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.


    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-c54d.
    Corresponding source code