HTMLDOC 1.9.18 is a bug fix release. Changes include:
</tr> (Issue #494)--header1 support for web page output (Issue #515)Binaries are available from Github for Windows and macOS, and through the Snapcraft store for Linux.
Enjoy!
Download HTMLDOC 1.9.18 Install HTMLDOC 1.9.18 Snap Home Page
PAPPL v1.4.6 is now available for download and is a bug fix release. Changes include:
Enjoy!
LPrint v1.3.1 is a bug fix release. Changes include:
Enjoy!
HP Printer Application v1.3.0 is now available for download as an “officially supported” printer application for older PCL laser and inkjet printers. Changes in 1.3.0 include:
Enjoy!
LPrint v1.3.0 adds a new dithering algorithm, support for new printers, support for configuration files, and fixes a number of bugs. Changes include:
Enjoy!
PAPPL v1.4.5 is now available for download and is a bug fix release. Changes include:
--disable-libpam configure option.Enjoy!
PDFio 1.2.0 is a feature release. Changes include:
pdfioFileCreateNumberObj and pdfioFileCreateStringObj functions
(Issue #14)pdfioContentTextMeasure function (Issue #17)pdfioContentTextNewLineShow and pdfioContentTextNewLineShowf
functions (Issue #24)pdfioContentTextNextLine to pdfioContentTextNewLine.Enjoy!
I had the privilege of being a guest with Till Kamppeter on this month’s Destination Linux podcast to talk about printing on Linux and the history of OpenPrinting, driverless printing, Apple, and AirPrint.
PAPPL v1.4.4 is now available for download and is a bug fix release. Changes include:
-n support for setting number of copies (Issue #312)papplPrinterSetDriverDefaults didn’t set the
“orientation-requested-default” value (Issue #313)Enjoy!
PDFio 1.1.4 is a bug fix release. Changes include:
Enjoy!
PDFio 1.1.3 is a bug fix release. Changes include:
Enjoy!
PAPPL v1.4.3 is now available for download and is a bug fix release. Changes include:
papplJobCreateWithFile.Enjoy!
PAPPL v1.4.2 is now available for download and is a bug fix release. Changes include:
Enjoy!
PDFio 1.1.2 fixes a number of PDF reading issues as well as a build issue. Changes include:
pdfioContentSetDashPattern to support setting a solid (0 length)
dash pattern (Issue #41)Enjoy!
PAPPL v1.4.1 is now available for download and is a bug fix release. Changes include:
papplJobResume and papplJobSuspend
functions (Issue #295)Enjoy!
PAPPL v1.4.0 is now available for download and is a feature release. Changes in 1.4.0 include:
papplDeviceRemoveScheme and papplDeviceRemoveTypes APIs to
disable unwanted device types (Issue #259)options sub-command to list vendor options and values
(Issue #255)Enjoy!
HTMLDOC 1.9.17 is a bug fix release. Changes include:
--pre-indent option to control indentation of pre-formatted text (Issue #505)Binaries are available from Github for Windows and macOS, and through the Snapcraft store for Linux.
Enjoy!
Download HTMLDOC 1.9.17 Install HTMLDOC 1.9.17 Snap Home Page
mantohtml v2.0.1 is a general bug fix release. Changes include:
NAME(SECTION).Enjoy!
PAPPL v1.3.4 is now available for download and is a general bug fix release. Changes in 1.3.4 include:
Changes in 1.3.3 include:
Enjoy!
PAPPL v1.3.2 is now available for download and is a general bug fix release. Changes in 1.3.2 include:
Enjoy!
PDFio 1.1.1 fixes a potential denial of service issue and fixes some build issues. Changes include:
Enjoy!
PDFio 1.1.0 fixes a potential denial of service issue, fixes a few general bugs, and adds a few new APIs. Changes include:
pdfioFileCreateTemporary function (Issue #29)pdfioDictIterateKeys function (Issue #31)pdfioContentPathEnd function.pdfioFileGet... metadata APIs (Issue #33)pdfioContentMatrixRotate function.Enjoy!
RasterView 1.9.0 includes some minor improvements and bug fixes and adds support for Windows. Changes include:
Enjoy!
Download RasterView 1.9.0 Install RasterView 1.9.0 Snap Home Page
This is a follow-up to my first post on code quality with updates to various tools and some thoughts on POSIX threading.
In addition to Address Sanitizer, GCC and Clang also both support
Memory Sanitizer and Thread Sanitizer to detect uninitialized
memory accesses and threading issues. Compile with the -fsanitize=memory or
-fsanitize=thread options to enable them, respectively.
The Thread Sanitizer is still very much a beta tool, and while it has helped with some of my recent threaded code it needs better support for locks - see below.
The LGTM service is shutting down, with everything moving over to the CodeQL tools. Github offers built-in support for running CodeQL as an “action” (continuous integration), and if you were using LGTM they will create a pull request for any of your repositories to migrate to the new tools. Github also offers integration with Codacy but I haven’t been as happy with their tools.
Travis CI decided to go non-free, so I’ve moved all of my CI to Github Actions.
Over the last year I have needed to debug PAPPL threading issues,
mainly around its use of reader/writer locks (pthread_rwlock_t) to control
access to the various objects. Thread Sanitizer was of limited use, so
I ended up developing simple logging macros along with an analysis program to
find deadlock, recursive locking, and locked-at-free issues. For example:
pthread_rwlock_rdlock(&obj->rwlock);
... access object values
pthread_rwlock_unlock(&obj->rwlock);
becomes:
_papplRWLockRead(obj);
... access object values
_papplRWUnlock(obj);
The macros log the thread, function, object address, and action (rdlock, wrlock,
or unlock) to stderr and then call the corresponding pthread_rwlock_xxx
function. When the test program is done running, the parse-lock-log program
then analyses the log and reports on any issues that are found.
I have been looking at re-implementing this as a shared library that can be loaded at runtime without re-compilation so it can be used more generally and also provide live reporting in addition to post execution analysis. I’ll post more if I make any headway on this…
LPrint v1.2.0 adds support for snap configuration and EPL/ZPL auto-typing support, and fixes a number of bugs. Changes include:
--with-systemd configure option and install to
$prefix/lib/systemd/system by default (Issue #50)Enjoy!
PAPPL v1.3.1 is now available for download and is a general bug fix release. Changes in 1.3.1 include:
Enjoy!
PAPPL v1.3.0 is now available for download and adds new job management, image printing, localization, and configuration features. Changes in 1.3.0 include:
papplLocGetDefaultMediaSizeName function to get the default media size
for the current country (Issue #167)--enable-tsanitizer
configure option.--with-papplstatedir and --with-papplsockdir
to use the localstatedir value (Issue #219)papplDevicePrintf to allow the “%c” character to be 0.Enjoy!
mantohtml is a man page to HTML conversion program. It supports all of the common man/roff macros and can combine multiple man pages in a single HTML output file.
mantohtml v2.0 is an all-new implementation of my original utility, now available as a separate project.
Enjoy!
PAPPL v1.2.3 is now available for download and is a general bug fix release. Changes in 1.2.3 include:
Enjoy!
PAPPL v1.2.2 is now available for download and is a general bug fix release. Changes in 1.2.2 include:
--with-papplstatedir and --with-papplsockdir
to use the localstatedir value (Issue #219)Enjoy!
Mini-XML 3.3.1 fixes a POSIX thread cleanup bug.
Enjoy!
PAPPL v1.2.1 is now available for download and fixes some key issues with localization, client limits, and compiling against older versions of CUPS. Changes in 1.2.1 include:
Enjoy!
HTMLDOC 1.9.16 adds new time and date support and fixes bugs. Changes include:
$DATE(format) and $TIME(format) header/footer strings
(Issue #472)Binaries are available from Github for Windows and macOS, and through the Snapcraft store for Linux.
Enjoy!
Download HTMLDOC 1.9.16 Install HTMLDOC 1.9.16 Snap Home Page
PAPPL v1.2.0 is now available for download. PAPPL v1.2 adds full localization, support for additional IPP features, and some other improvements. Changes in 1.2.0 include:
papplMainloopShutdown API to trigger a shutdown of the system that
was started by papplMainloop.Enjoy!
HP Printer Application v1.2.0 is now available for download as an “officially supported” printer application for older PCL laser and inkjet printers. Changes in 1.2.0 include:
Enjoy!
PAPPL v1.2rc1 is now available for download. PAPPL v1.2 adds full localization, support for additional IPP features, and some other improvements. Changes in 1.2rc1 include:
papplMainloop.papplDeviceList and DNS-SD discovery when there was no active system.papplDeviceGetSupplies API.Enjoy!
PAPPL v1.2b1 is now available for download. PAPPL v1.2 adds full localization, support for additional IPP features, and some other improvements. Changes include:
papplJobFilterImage function with smoothing enabled (Issue #64)papplDeviceGetSupplies API to query supply levels via SNMP (Issue #83)papplPrinterGet/SetMaxPreservedJobs API and reprint web interface (Issue #189)papplSystemAddEvent and papplSubscriptionXxx functions (Issue #191)papplPrinterDisable and papplPrinterEnable functions and proper support for the IPP “printer-is-accepting-jobs” attribute.papplSystemGet/SetMaxClients API (Issue #198)papplPrinterSetReadyMedia to support up to PAPPL_MAX_SOURCE media entries, regardless of the number of sources.Enjoy!
StringsUtil v1.0 is now available for download. StringsUtil provides a library for using Apple “.strings” localization files and a utility for managing those files.
StringsUtil provides a library for using Apple “.strings” localization files and a utility for managing those files. It is intended as a free, smaller, embeddable, and more flexible alternative to GNU gettext. Key features include:
I’m providing StringsUtil under the Apache License Version 2.0 with an (optional) exception to allow linking against GPL2/LGPL2 software.
PDFio 1.0.1 is a bug fix release. Changes include:
pdfioPageGetNumStreams and pdfioPageOpenStream functions.pdfioStreamGetToken.Enjoy!
This release of mmd adds support for task lists as well as resolving a few
minor issues reported by the Clang static code analysis tool. Changes include:
Enjoy!
HTMLDOC is now available on Flathub, another Linux app store.
Enjoy!
HTMLDOC 1.9.15 is a bug fix release. Changes include:
Binaries are available from Github for Windows and macOS, and through the Snapcraft store for Linux.
Enjoy!
Download HTMLDOC 1.9.15 Install HTMLDOC 1.9.15 Snap Home Page
LPrint v1.1.0 adds support for EPL and 600dpi ZPL label printers, adds status reporting and automatic label configuration for ZPL label printers, adds auto-setup and test labels for printers, adds system service files for macOS and Linux, and fixes all known bugs in the previous release. Changes include:
lprint default and lprint delete not working (Issue #17, Issue #40)SIGINT (Issue #18)Enjoy!
HTMLDOC 1.9.14 is a bug fix release. Changes include:
Binaries are available from Github for Windows and macOS, and through the Snapcraft store for Linux.
Enjoy!
Download HTMLDOC 1.9.14 Install HTMLDOC 1.9.14 Snap Home Page
PAPPL v1.1.0 is now available for download. PAPPL v1.1 adds support for Wi-Fi configuration, IPP-USB, printer driver lookup and auto-add functionality, improves management of multiple printers, and adds support for Microsoft® Windows® 10 and higher.
Enjoy!
The first stable release of PDFio is now available! PDFio is a simple C library for reading and writing PDF files. The primary goals of PDFio are:
PDFio is not concerned with rendering or viewing a PDF file, although a PDF RIP or viewer could be written using it.
Enjoy!
PDFio 1.0rc1 is the first candidate release of PDFio. Changes include:
Enjoy!
The release candidate for PAPPL v1.1 is now available for download. PAPPL v1.1 adds support for Wi-Fi configuration, IPP-USB, printer driver lookup and auto- add functionality, improves management of multiple printers, and adds support for Microsoft® Windows® 10 and higher.
Changes in 1.1rc1 include:
Enjoy!
PDFio 1.0b2 is the second beta release of PDFio. Changes include:
pdfioFileCreateOutput API to support streaming output of PDF (Issue #21)all-shared target (Issue #22)pdfioContentSetDashPattern to accept double values (Issue #25)Enjoy!
Mini-XML 3.3 is a bug fix release. Changes include:
free throughout the library (Issue #276)mxmlLoad* functions (Issue #278, Issue #279)mxmlSaveString with a buffer size of 0 (Issue #284)MXML_MINOR_VERSION value in “mxml.h” (Issue #285)Enjoy!
HTMLDOC 1.9.13 is a bug fix release. Changes include:
Binaries are available from Github for Windows and macOS, and through the Snapcraft store for Linux.
Enjoy!
Download HTMLDOC 1.9.13 Install HTMLDOC 1.9.13 Snap Home Page
The third beta release of PAPPL v1.1 is now available for download. PAPPL v1.1 adds support for Wi-Fi configuration, IPP-USB, printer driver lookup and auto- add functionality, improves management of multiple printers, and adds support for Microsoft® Windows® 10 and higher.
Changes in 1.1b3 include:
papplSystemSetAuthCallback API to support alternate authentication
mechanisms (Issue #185)papplCreateTempFile and papplPrinterOpenFile file creation functions
(Issue #186)server-options option for the server sub-command (Issue #187)papplCopyString, papplGetRand, and papplGetTempDir utility
functions.papplSystemSetHostName did not also update the default TLS common
name.file:///dev/null to NUL: on Windows.Enjoy!
The second beta release of PAPPL v1.1 is now available for download. PAPPL v1.1 adds support for Wi-Fi configuration, IPP-USB, printer driver lookup and auto- add functionality, improves management of multiple printers, and adds support for Microsoft® Windows® 10 and higher.
Changes in 1.1b2 include:
papplDeviceGetID with network devices (Issue #95)Enjoy!
The OpenPrinting group of the Linux Foundation had a session at the 2021 (virtual) Linux Plumber’s Conference yesterday. I led a discussion about the upcoming CUPS 2.4 release, next year’s planned CUPS 2.5 release, and 2023’s planned CUPS 3.0 release which will (finally) eliminate printer drivers on Linux. Till presented developments in printer management and packaging on Linux, print dialogs, and printer applications. And Bhavna talked about her Google Summer of Code work to extend PAPPL with scanning support.
I recently got some push-back on my latest beta releases, specifically on the format of my version numbers (1.0b1 for PDFio, and 1.1b1 for PAPPL). I’ve been using this scheme for many years now, and it is hardly unique. What follows is a short summary of the history, standards, and best practices for version numbers…
Version numbering has long been a source of pain in software. Early programs either lacked version numbers or used integers (“version 1”, “version 2”, etc.) to identify some release. Bug fixes often turned these integers into real numbers (1.01, 1.02, etc.) where a newer version was numerically greater than the older version (1.01 is older than 1.1, etc.)
A modified version of this scheme gradually replaced real number versioning where two or more integers separated by periods represented a version number, for example 1.0 was the first release of (major) version 1, 1.1 was the second release, and so forth. Bug fixes (patches) yielded a third number - 1.0.1, 1.0.2, etc. The notion of alpha-, beta-, and pre-release software became a thing with all sorts of formats - 1.0b1, 1.0-pre1, etc. Then developers got serious and declared release candidates and golden masters!
Large companies started tracking build numbers in addition to public version numbers. For example, Apple uses a numbering scheme that can be roughly translated as “majorMINORbuildPATCH”, where “major” is an integer representing the internal major release number, “MINOR” is an uppercase letter (A=0, B=1, C=2, …) representing a minor update to that major release, “build” is an integer representing the number of times that “build train” (branch) has been built, and “PATCH” is a lowercase letter (omitted for the first build) representing the number of times a build had to be patched (components rolled back and the combined build re-tested) to yield a functional build. Thus, the current macOS® 12.0 Beta 6 has a version number of “21A5294g” - major version 21, minor version 0, build number 5294, patch 7.
This last wrinkle demonstrates an important distinction - there are version numbers that are used for human consumption (“macOS 12”) and version numbers that are used for computers (“21A5294g”). Some packaging schemes define rules for comparing version number strings, while others provide explicit ways to assign sequences or values for comparison.
Of course, eventually people got together to define standards. In the open source community, the Semantic Versioning standard is quite popular, although most Linux packaging systems don’t exactly conform (more below).
The Trusted Network Connect
standard defines version numbers as a set of four 16-bit unsigned integers that
can effectively be compared as a single 64-bit value or treated as four
separated integers, e.g. MAJOR.MINOR.PATCH+BUILD for display/interoperability
purposes. This has trickled down to IPP and other standards.
Snapcraft packages can have any version number string they like. Snaps are tracked by their build numbers which are (manually) assigned to stable, candidate, beta, and edge (as in “bleeding edge”) releases that users can install.
Most of the version numbering standards focus on identifying production
code. As I mentioned at the top of this article, I’ve been using more-or-less
standard suffixes to identify beta (MAJOR.MINORbNUMBER) and release candidate
(MAJOR.MINORrcNUMBER) source archives that allow developers to try my new
software out and report any issues they encounter, but I don’t expect this
software to be released to the general public as it is not yet production
code. But if a developer does choose to package it up, most of the traditional
Linux packaging formats (RPM, Debian, Slackware, etc.) will treat 1.0b1 as
older than 1.0.0 so the right thing will happen when I release 1.0.0 and the
developer packages that code.
The Semantic Versioning specification gives lip-service to supporting
so-called “pre-release” suffixes (1.0.0-alpha1, 1.0.0-beta.2, etc.) but it
is up to you (i.e., not standardized) to define the meaning of the names.
Common suffixes are “alpha”, “beta”, “pre”, and “rc” - it is just important to
keep the names you use in lexical sort order so that the version number
comparisons work as expected. Alas, none of the Linux package formats actually
support Semantic Versioning suffixes, so that 1.0.0-beta.1 to 1.0.0 upgrade
won’t actually happen…
The TNC-style four number version tuple is even less flexible - there is literally no way to express a beta release. More than likely you’ll end up using the last number as a build number and (internally) decide when you have a final build for a particular MAJOR.MINOR.PATCH version.
With 30+ years of software development experience I can make the following recommendations:
Define a version numbering scheme that works for your project, and use it consistently. This scheme naturally may depend on where you plan to release your software.
If you distribute binaries, build numbers are an important part of your
software version number. Automate the build number whenever possible, for
example git rev-list --all --count will give you the number of commits
pushed to the Git repository used by your build system.
If you distribute APIs, don’t remove APIs in minor or patch releases. If you have to remove an API, it is time for a major version number change.
Version numbering is an important part of your software development plan. You should have a software development plan whether you are developing software by yourself or as part of a large team. It can even be written down on the back of a napkin during lunch…
The first beta release of PAPPL v1.1 is now available for download. PAPPL v1.1 adds support for Wi-Fi configuration, IPP-USB, printer driver lookup and auto- add functionality, improves management of multiple printers, and adds support for Microsoft® Windows® 10 and higher.
Changes in 1.1b1 include:
PAPPL_SOPTIONS_NO_TLS option to disable TLS support.papplMainLoop now uses a persistent location for state and spool files by
default (Issue #128)papplMainLoop now supports clients talking to a system-wide server running
as root (Issue #148)drivers sub-command now reports the IEEE-1284 device ID for a given
driver (Issue #157)papplJobCreateWithFile API to allow printer applications to
submit print jobs internally.papplSystem hostname/port APIs to be consistent with the
naming used for the papplClient APIs.Enjoy!
PDFio 1.0b1 is the first beta release of PDFio.
I had the privilege of being a guest with Till Kamppeter on this month’s Ubuntu Desktop Team Indaba to talk about open source printing - the early history, where we are today, and where we are headed. Be sure to check out the video and the OpenPrinting web sites for more information and links to all of the projects that are being worked on.
RasterView 1.8 includes some minor improvements and bug fixes. Changes include:
Enjoy!
Download RasterView 1.8 Install RasterView 1.8 Snap Home Page
PDFio is a simple C library for reading and writing PDF files. I’ve been working on it sporadically for the last few weeks to prototype some new printing features and support a future version of HTMLDOC. The primary goals of PDFio are:
PDFio is not concerned with rendering or viewing a PDF file, although a PDF RIP or viewer could be written using it. And while it is far from complete, the current code is sufficient to manipulate PDF files and create page content.
I’m providing PDFio under the Apache License Version 2.0 with an (optional) exception to allow linking against GPL2/LGPL2 software.
HTMLDOC 1.9.12 is a bug fix release. Changes include:
Enjoy!
Download HTMLDOC 1.9.12 Install HTMLDOC 1.9.12 Snap Home Page
PAPPL v1.0.3 is a general bug fix release and is now available for download.
Download PAPPL v1.0.3 Home Page
Changes in 1.0.3 include:
Enjoy!
PAPPL v1.0.2 is a general bug fix release and is now available for download.
Download PAPPL v1.0.2 Home Page
Changes in 1.0.2 include:
papplSystemSetVersions function now allows changes while the system is
running (Issue #123)papplClientGetForm function did not support files larger than 64k
(Issue #139)papplPrinterSet... functions from
an iterator callback (Issue #143)server sub-command now enables TCP/IP connections using the default
hostname; auto-started servers still disable TCP/IP connections by default
(Issue #147)papplPrinterSetDriverDefaults function did not validate the defaults
against the actual driver data.SIGTERM now behaves the same as sending
a Shutdown-System request.papplDeviceOpen did not copy the device ID callback.papplDeviceList and papplDeviceOpen did not send errors to stderr when a
NULL error callback was specified.Enjoy!
PAPPL v1.0.1 is a general bug fix release and is now available for download.
Download PAPPL v1.0.1 Home Page
Changes in 1.0.1 include:
papplSystemLoadState function did not load vendor attribute defaults
correctly (Issue #103)papplSystemLoadState function now calls the printer driver’s status
callback after loading the printer’s attributes (Issue #107)papplSystemSaveState.Enjoy!
zipc v1.3 is a bug fix release. Changes include:
localtime_r/s to avoid potential thread safety issues.Enjoy!
This release of mmd fixes a link parsing bug as well as resolving several
minor issues reported by various static code analysis tools.
Enjoy!
Download mmd 1.8 Install mmdutil 1.8 Snap Home Page
Changes include:
([title](link)) did not parse correctly.mmd sources.I periodically get bug reports and pull requests concerning the quality or patterns in my code. While some of my projects provide some documentation on the coding standards and tools I use, I’ve never bothered to write this up before. So here is a snapshot of my strategy for producing quality C code that I have honed over the last 35 years (!) of writing C.
I know plenty of programmers who think that documentation is not their job, that “comments are for wusses”, that hard-to-read code is job security, or that “I don’t have enough time to write documentation”. I personally think those attitudes are the number one problem with most coding today.
Consider the following two code examples - the first provides no clue about the
purpose of the function, arguments, or variables and would be difficult to
maintain while the second makes everything obvious from the naming. The names of
functions, structures, etc. should be obvious so that other code that calls them
is easier to follow as well. Imagine looking at another function in your program
that calls a(1,10); and wondering what the heck that does!
There are also differences in formatting between the two examples that help with the readability and maintenance of the code. I’m not going to advocate for a particular coding style, and the second example isn’t even the one I use. The important thing is to choose a style that works for you and be consistent! Remember, even if you are the only person that will be maintaining the code, you will still need to remember what the heck you were doing in one, two, or ten years!
“Bad” Code Example:
void a(int b, int c){
int q; char qq[100];
for (q=b;q<=c;q++){snprintf(qq,sizeof(qq),"%d",q);puts(qq);}
}
“Good” Code Example:
// Print a list of numbers from "first" to "last"
void
print_numbers(
int first, // First number
int last) // Last number
{
int number; // Current number
char text[100]; // Number as a string
// Loop through the number
for (number = first; number <= last; number ++)
{
// Format and print the number on a line
snprintf(text, sizeof(text), "%d", number);
puts(text);
}
}
There are a lot of tools available that help you write better code. The following is far from a definitive list but represents what I have incorporated into my own projects.
Most compilers provide helpful warnings about problems in your code.
Clang and GCC both support -Wall to enable a lot of common
warnings, -Wextra to enable less common warnings, -Wxxx to enable warning
“xxx”, and -Wno-xxx to disable a warning that isn’t useful in your code. I usually stick to -Wall -Wunused (all common plus unused function arguments)
and sometimes add -Wno-format-truncation (GCC only) which warns about the
snprintf output buffer not being large enough for a corresponding “%s” in the
format string. The -Werror option can be used to turn warnings into errors,
but I only add it in “maintainer” mode so that random new warnings or system
header variations don’t derail people using my code.
For normal development I use the -Os option to include optimizations that do
not affect debugging or size and -g to include debugging symbols. You can use
-O0 to disable optimizations, but in my experience that can hide issues that
only show up when the code optimizer is enabled or create issues that the
optimizer fixes for you.
For release builds, I find -Os is still usually the best. Some code benefits
from the additional optimizations provided by -O2 (mainly expansion of inline
functions) or -O3 which does more execution modeling, loop unrolling, and code
cloning to reduce branching delays.
If you are using MS Visual C, it uses
/Wallto enable all its warnings and/wd xxxto disable specific ones./WXturns warnings into errors./Osis the equivalent of GCC’s-Oswhile/Otroughly corresponds to-O2. Debugging is enabled with/Zi. Most often I’m just letting the Visual Studio defaults for the Debug and Release targets get used since these options have changed over the years…
Dynamic code analysis tools work on your running programs and typically involve a steep processing and/or memory penalty. I’ve been using dynamic code analysis tools for much of my career. First was a product called Rational Purify that helped you find memory access issues, but alas Rational was eventually bought up by IBM and Purify appears to have been discontinued.
Valgrind replaced Purify for me. Valgrind basically simulates the host processor to run your code, tracks all memory usage, and validates all arguments passed to system calls and library functions. Valgrind just runs your compiled program (nothing needs to change for your compiler or linker options), and uses debug symbols to provide backtraces when an error occurs.
I used Valgrind extensively when developing and testing CUPS and HTMLDOC, and still run it from time to time on my other software when a hard-to-time problem gets reported. That said, you can expect a 10x performance hit (or more) and increased memory usage, and I’ve brought my development machine to its knees more than once when doing a big test!
While I worked at Apple, I did some contributions to Valgrind to keep the macOS support up-to-date. Unfortunately, starting with macOS 10.13 Apple added system integrity features (mandatory code signing, library validation, and secure runtime checks) that make it impossible to run Valgrind on current macOS releases. Since most of my code is cross-platform, I still use it from time to time on Linux, but it is no longer part of my macOS test suites.
A more recent, lighter-weight tool called Address Sanitizer is supported
by recent versions of both GCC and Clang on macOS and Linux. The address
sanitizer checks for memory errors and leaks. Unlike Valgrind, you can’t use
Address Sanitizer with an existing executable. Instead, you add the
-fsanitize=address option to your compiler and linker options to build
Address Sanitizer into your program, and every run of the program is a run of
the Address Sanitizer.
The ASAN_OPTIONS environment variable can be used to specify testing options.
I always set it to leak_check_at_exit=false to suppress the inevitable “you
didn’t free everything before exiting” error, since unconditionally freeing
everything you’ve allocated doesn’t usually make sense.
Static code analysis tools work on your source code and have no impact on your
code’s execution speed or memory usage. Each tool has its strengths and
weaknesses, and a common complaint is that they are not always smart enough to
see logical connections. For example, the following (convoluted) example will
trip up most source code analyzers with an error about “copy” not being
initialized in the calls to puts and free:
// Print a string in a convoluted way
void
print_string(char *s) { // String
bool ok = false; // Did we have a string to copy?
char *copy; // Copy of string
if (s != NULL) {
// Have a string, make a copy
copy = strdup(s);
ok = copy != NULL;
}
if (ok) {
puts(copy);
free(copy);
}
}
That said, there are a few tools that I use extensively in my projects, and most of them are open source or free to use for open source projects:
The Clang Static Analyzer is probably the fastest of the
current static analysis tools and is part of the Clang compiler and Apple’s
Xcode IDE (CMD+SHIFT+B). I also enable the “shallow” analysis mode for
regular macOS builds to catch coding errors that the normal warnings miss.
Cppcheck is an open source analyzer that offers “add-ons” that scan for a variety of things including common CERT vulnerabilities and MISRA C conformance. I find the MISRA C code “standard” to be a joke (among other things it says you can’t do pointer arithmetic or have a loop with multiple variables) but the CERT checks are top-notch.
LGTM is an open source code scanning service that is integrated with many of the source code hosting companies. Some of its checks yield a lot of false positives, but all of my C projects are setup to use it and you can exclude certain checks as needed. One weakness is that LGTM does not support forks of projects, and while I generally agree with their rationale that most forks are mirrors of the parent repository, there should be a way to specify that your fork is different (e.g. OpenPrinting’s CUPS repository…)
CodeQL is another open source scanning service (from the same people that do LGTM) that brings in additional third-party scanning tools like Cppcheck. I’ve tried using it since it offers Github integration, however the documentation is poor and there does not seem to be a way to suppress things like Cppcheck’s MISRA conformance add-on, quickly yielding thousands of issues in the Github dashboard with no way to resolve them. I’m hoping this will change in 2021, but we’ll see…
Coverity is a closed-source scanning tool that offers free code scanning for open source projects. I’ve used it for CUPS in the past, and they provide a convenient web dashboard for reviewing reports and excluding false positives in each of your projects.
I’ve recently started looking at a more advanced tool called Frama-C. It looks like it will be able to do even more in depth scanning and logical analysis, once I figure out how to use it. :)
Many of the static analysis tools in the previous section are actually part of a continuous integration service integrated with Github. Continuous integration refers to automated builds of every commit and pull request to your code repository. The most basic solutions provide you with the answer to “will it build” for the platform(s) they support. Most also allow you to run unit tests and test suites after the build, providing a powerful way to sanity-check your software on a regular basis. I regularly use Travis CI for Linux and macOS testing and AppVeyor for Windows testing (it also now supports Linux and macOS, but I’m not using that functionality).
To go beyond “will it compile” you need to write unit tests and/or test suites to verify your code. There are a lot of unit test frameworks to choose from, but you can also roll your own (which is what I generally do) if those frameworks don’t align with your needs. Some frameworks can help you track your code coverage, while others just automate the reporting of test results. The key is to ensure that you are testing as many of the features or APIs in your software as you can, and to report failures as clearly as possible so you can more easily fix problems that crop up.
To integrate your unit tests into a continuous integration service, add a target to your project that builds and runs them. The “standard” for makefile-based projects is to support a “test” target, which Travis CI (at least) will use to run the tests in a Docker container after a successful build.
When developing open source software, I have met contributors with wildly different priorities than my own. Mostly these differences concern new features or changes in behavior, but sometimes I meet people concerned with coding practices, optimization, and/or standards conformance.
I’m a strong believer in focusing my optimization efforts on the 10% of code that yields 90% of the performance improvement. If one function is responsible for a significant amount of execution time or memory use, and if there is an obvious way to noticeably improve performance or memory use, then absolutely do that optimization. Eeking another 1% improvement is usually not necessary or useful, and often yields harder-to-maintain code.
Most open source software is not built using the latest compilers or libraries. In particular, Linux-based systems often provide a wide range of options, with server-focused distributions shipping with (in some cases) decades-old tools.
My CUPS software still follows the C89 standard in order to compile on old
commercial UNIX platforms, and I avoid C11 APIs like fopen_s and thrd_create
since they are not widely supported even today. But C99 seems to be well
supported and that is what my new software follows.
I’m not going to make any C++ recommendations. I stopped doing new C++ development years ago because STL and name mangling changes have made it incredibly difficult to ship binaries of C++ software.
Some tools and standards advocate freeing all memory you allocate before you exit your program. In the days before virtual memory, preemptive multitasking, and modern operating systems, this advice was sound - if you didn’t free everything then eventually your system would run out of free memory and you’d either crash or be forced to reboot. Even today, if you are using a barebones embedded OS then you absolutely need to tightly manage your memory.
But for any development for a modern OS, freeing/deleting objects for the sake of returning memory to the operating system is 100% totally unnecessary. As soon as your process is “reaped”, all the memory that was allocated to the process goes right back to the OS and is available for use again. All that freeing memory will do is consume processor time and delay the exit of your process.
Some tools and standards complain when you ignore the return values of
functions. In my experience, these warnings are appropriate less than half the
time. For example, the unlink system call returns the usual 0 on success
and -1 on failure, with the possible errno values indicating why the file
could not be removed. If I am writing a program whose sole purpose is to
delete files and it is important for me to know and/or report any failures, then
my code will absolutely check the return value. But if I am just removing a
temporary file my program created and that fails (perhaps because the file has
already been deleted), it is less important that I check the return value -
especially when there is nothing I can do to correct the problem.
When the return value is important and there is something I can do about it, I check the return value. If it is not important or I can’t do anything about it, I ignore it.
Some language purists insist that goto should be removed from the C language.
While I generally avoid using goto, there is one scenario where its use is
justified: function exit points. By consolidating the clean up code in
one place you make the code smaller, more readable, and more maintainable.
This release of codedoc adds syntax highlighting, literal link, image dimensions, and block quote in comments support as well as fixing a number of bugs. Changes include:
::WIDTHxHEIGHT in image (ALT) text.Enjoy!
HTMLDOC 1.9.11 fixes some bugs and adds high-resolution desktop icons for Linux. Changes include:
--numbered option did not work when the table-of-contents was disabled
(Issue #405)Enjoy!
Download HTMLDOC 1.9.11 Install HTMLDOC 1.9.11 Snap Home Page
The first stable release of PAPPL is now available for download. PAPPL is a simple C-based framework/library for developing CUPS Printer Applications, which are the recommended replacement for printer drivers.
Download PAPPL v1.0.0 Home Page
Changes in 1.0.0 include:
papplSystemLoadState would not load printers whose device IDs contained the
# character (Issue #92)papplPrinterGetPath API to get the path for a printer web page
(Issue #97)papplPrinterAddLink and papplSystemAddLink functions now accept an
“options” argument instead of the “secure” boolean in order to allow links to
be added to multiple places on the web interface in addition to requesting a
secure (HTTPS) link (Issue #98)Enjoy!
Over the past several years, Apple has been increasing the security requirements of macOS applications. Besides the macOS binaries I’ve been building of my software, I also have been helping other open source projects get their macOS binaries to be acceptable on users’ systems while still allowing the build process to be as automated as possible…
Code signing calculates a cryptographic hash (a complex checksum) of your software files and a certificate you get from Apple that both identifies who you are and that Apple trusts you. The hash can then be verified when the software is installed and run so that macOS knows that the software can be trusted and that it hasn’t been changed. If not, you’ll get the dreaded “this software can’t be trusted” dialog.
You install a code signing certificate by running the Xcode application, opening
the Preferences window (CMD+,), and going under the Accounts tab. Click on
“Manage Certificates…” to add a Developer ID Application certificate for
signing a command-line tool or application bundle and/or a Developer ID
Installer certificate for signing a macOS package.
Each developer account has an associated team ID that consists of 10 uppercase letters and/or numbers, e.g. “AB3456789Z”. This team ID is listed in the certificate common name, e.g. “Developer ID Application: Bob’s Software (AB3456789Z)”.
Note: The Developer ID certificates require a paid Apple developer program account. If you are a member of a development team, you might have to ask your team administrator to generate the certificates for you.
Two other kinds of certificates are also used on macOS:
Unless you re-sign with a Developer ID certificate, executables signed with the ad-hoc or Apple Development certificates will not run on your other systems.
Starting with macOS 10.15, software must also be notarized. Notarization is a kind of two-factor authentication for code signing - after you sign your software, you send a copy of it to Apple along with your Apple ID credentials (more on that in a moment) so that Apple can match everything up and produce a cryptographic seal-of-approval for your software. The results of notarization should be attached to the software that you provide to your users to avoid issues when the user isn’t online.
Another feature of code signing on macOS is that the signature can specify additional restrictions for the runtime environment for the program. Some of these restrictions are required for notarization to work, and one of them (the “runtime” restriction) prevents you from inserting dynamic libraries or debugging the executables.
Xcode includes three command-line tools, accessed by putting xcrun in front of
the names, that are used for code signing and notarization. The codesign
utility does the actual code signing and accepts several arguments:
-s IDENTITY: Specifies the code signing identity such as “-“ for ad-hoc,
“Developer ID Application” to use any Developer ID application certificate
you have, or “TEAMID” to use the Developer ID certificate associated with the
specified team.
-o OPTIONS: Specifies code signing options separated by commas. All
notarized applications (and those shipped through the Mac AppStore) must use
the “runtime” option.
--timestamp: Includes an authenticated date/time stamp in the signature,
which is required for notarization.
-i BUNDLE-ID or --prefix BUNDLE-PREFIX: Specifies a unique identifier for
a command-line program, e.g. “com.bobsoft.program” for the identifier or
“com.bobsoft” for the prefix. In the case of --prefix, the program name is
added to the prefix. The BUNDLE-ID must be unique across all software you
sign.
-f: Forces the code signature to be replaced, if one already exists.
The altool is used to notarize a package or ZIP file containing an application
bundle or one or more programs:
--notarize-app: Notarizes the given file.--notarization-info UUID: Queries the status of a notarization request.-f FILENAME: Specifies a ZIP file or package (.pkg) file.--primary-bundle-id BUNDLE-ID-OR-PREFIX: Specifies the application bundle ID
or the prefix that was used for command-line programs.--username APPLEID: Specifies the developer account’s Apple ID (email
address).--password @keychain:AC_TEAMID: Specifies the keychain entry to use for the
password (token) string.--asc-provider TEAMID: Specifies the developer team that is producing the
software.Finally, the stapler command is used to attach a copy of the notarization to
your software. This command currently only works for application bundles and
packages.
Any code signing workflow for open source projects should be flexible about the use of Apple identifiers. I typically use the “APPLEID” and “TEAMID” environment variables to provide the Apple ID and team ID values for a given project.
The notarization (altool) command needs an app-specific password string.
While the Apple examples store this in a keychain item named “AC_PASSWORD”, I
recommend using “AC_$TEAMID” to allow for working on multiple development
teams. For example, if your team ID is “AB3456789Z”, your Apple ID is
“bob@bobsoft.com”, and your app-specific password string is “abcdef123456789”,
run:
xcrun altool --store-password-in-keychain-item "AC_AB3456789Z" \
-u "bob@bobsoft.com" -p abcdef123456789
Once you have these basics setup, you can use the following script to sign and notarize an application, a package, or a list of commands:
#!/bin/sh
#
# macOS code signing and notarization script.
#
# Copyright © 2020 by Michael R Sweet
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
#
# 1. Redistributions of source code must retain the above copyright notice, this
# list of conditions and the following disclaimer.
#
# THIS SOFTWARE IS PROVIDED BY MICHAEL R SWEERT "AS IS" AND ANY EXPRESS OR
# IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
# EVENT SHALL MICHAEL R SWEET BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
# OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
# WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
# OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
# ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
# Usage:
#
# sign-and-notarize [--prefix BUNDLE-PREFIX] FILE [ ... FILE ]
#
if test "x$APPLEID" = x; then
echo Please set the APPLEID environment variable.
exit 1
fi
if test "x$TEAMID" = x; then
echo Please set the TEAMID environment variable.
exit 1
fi
primary=""
prefix=""
files=""
zipfile="$TMPDIR/notarize$$.zip"
alfile="$TMPDIR/notarize$$.txt"
# Collect files and do code signing...
while test $# -gt 0; do
arg="$1"
shift
case "$arg" in
--help)
echo "Usage: sign-and-notarize [--prefix BUNDLE-PREFIX] FILE [ ... FILE]"
exit 0
;;
--prefix)
prefix="$1"
shift
;;
-*)
echo "Unknown option '$arg'."
exit 1
;;
*.app | *.pkg)
files="$files $arg"
# Get the primary bundle ID...
if test -f $arg/Contents/Info.plist; then
primary=`plutil -p $arg/Contents/Info.plist | grep CFBundleIdentifier | awk -F\" '{print $4}'`
fi
echo "xcrun codesign -f -s $TEAMID -o runtime --timestamp $arg"
xcrun codesign -f -s $TEAMID -o runtime --timestamp $arg
;;
*)
if test "x$prefix" = x; then
echo "Missing --prefix option."
exit 1
fi
files="$files $arg"
echo "xcrun codesign -f -s $TEAMID --prefix $prefix -o runtime --timestamp $arg"
xcrun codesign -f -s $TEAMID --prefix $prefix -o runtime --timestamp $arg
;;
esac
done
if test "x$files" = x; then
echo "Usage: sign-and-notarize [--prefix BUNDLE-PREFIX] FILE [ ... FILE]"
exit 1
fi
# Notarize...
echo "zip -rv ... $files"
zip -rv $zipfile $files
if test "x$primary" = x; then
# When signing multiple command-line tools, use the prefix as the primary
if (echo $files | grep -q ' '); then
primary="$prefix"
else
primary="$prefix.`echo $files`"
fi
fi
echo "xcrun altool --notarize-app -f ... --primary-bundle-id $primary ..."
xcrun altool --notarize-app -f $zipfile --primary-bundle-id $primary --username $APPLEID --password @keychain:AC_$TEAMID --asc-provider $TEAMID > $alfile || exit 1
uuid=`grep RequestUUID $alfile | awk '{print $3}'`
status="in progress"
while test "$status" = "in progress"; do
echo " $uuid: $status"
sleep 10
echo "xcrun altool --notarization-info ..."
xcrun altool --notarization-info $uuid --username $APPLEID --password @keychain:AC_$TEAMID --asc-provider $TEAMID > $alfile || exit 1
status="`grep Status: $alfile | cut -b14-`"
done
echo " $uuid: $status"
rm -f $alfile $zipfile
# Staple the notarization...
for file in $files; do
case "$file" in
*.app | *.pkg)
echo "xcrun stapler staple $file"
xcrun stapler staple $file
;;
esac
done
By popular request, I’ve created a second way to financially support my open source development through Liberapay. Thank you for any assistance you choose to provide, whether it is financial or in the form of a bug report, pull request, or other feedback that helps make my software better!
The first release candidate of PAPPL 1.0 is now available for download. PAPPL is a simple C-based framework/library for developing CUPS Printer Applications, which are the recommended replacement for printer drivers.
Download PAPPL v1.0rc1 Home Page
Changes in 1.0rc1 include:
papplSystemLoadState no longer crashes when it cannot create a printer
(Issue #87)papplMainloop
(Issue #89)papplSystemSetPrinterDrivers that is
run after a printer is created (Issue #90)papplDeviceRead now has a 100ms timeout for USB and network connections.Enjoy!
In case you blinked, here is EPM v5.0.0 from Jim Jagielski. With my blessing, the license is now Apache 2.0 (like many of my other projects) and Jim has brought support for the platforms I dropped in v4.5 back as well!
Today brings two changes for EPM. First a quick (final) bug fix release (v4.5.1) from me with the following changes:
Second, I am pleased to announce that Jim Jagielski has volunteered to take over development of EPM. Among other things, Jim is an Apache OpenOffice developer who has been using EPM to create the community builds of AOO. He has also been maintaining a fork of EPM with his own changes and fixes that would benefit all developers and that I, quite frankly, haven’t had the time to look at or integrate. In short, I think Jim will do a great job moving EPM forward and giving the project the “love” it deserves!
The first beta release of PAPPL 1.0 is now available for download. PAPPL is a simple C-based framework/library for developing CUPS Printer Applications, which are the recommended replacement for printer drivers.
Enjoy!
Mini-XML 3.2 adds support for the Haiku operating system and fixes bugs. Changes include:
Enjoy!
This release of codedoc adds C++ block comment support and fixes a number of bugs. Changes include:
Enjoy!
HTMLDOC 1.9.10 fixes packaging and crash bugs. Changes include:
pre text (Issue #394)Enjoy!
Download HTMLDOC 1.9.10 Install HTMLDOC 1.9.10 Snap Home Page
Over the past few weeks I have been working with Yocto, specifically to put together a layer containing PAPPL and other necessary bits to build headless Raspberry Pi-based print servers. And since I’m a standards guy I want this setup to more-or-less pass all of the network certification tests, including Apple’s Bonjour Conformance Tests. Unfortunately, this has taken a bit longer than I’d hoped…
I’ve been using a Raspberry Pi Zero W and a Rasberry Pi 3 Model B for my testing. These use the same wireless chip (a Broadcom BCM43438) but the ‘Pi 3 also offers 100baseT Ethernet for the wired network tests.
My iMac Pro serves as the build machine (running Parallels with an Ubuntu 18.04 VM), and my 16” MacBook Pro serves as the BCT test machine. Both the MacBook Pro and the Raspberry Pi under test are connected to a 4th generation Apple TimeCapsule (802.11a/b/g/n) base station for the tests.
I’m using Yocto to create custom Linux images for the Raspberry Pi’s. For those not familiar with it, Yocto is an embedded Linux development environment that can be configured to support a wide variety of embedded processing boards and/or virtual machine environments like QEMU.
Yocto is organized into “images” which are the final OS images you put on your board, “layers” which are logical pieces of the OS such as core, networking, multimedia, Board Support Packages (“BSPs”), etc., and “recipes” which represent individual packages or components for the OS. You can customize all of these things, and everything gets compiled from source code or (if you are very lucky) can be found in an official pre-compiled repository hosted by the Yocto project. Building a Yocto image for the first time takes several hours, even on my iMac Pro…
I’ve been working with the “Zeus” branch (which until recently was the newest) and the official meta-raspberrypi BSP layer. To that I’ve updated the Avahi, CUPS, and dhcpcd “recipes” to pull in the current versions of each.
The two public certification tests I’ve been focusing on have been the PWG’s IPP Everywhere™ Printer Self-Certification Tools and Apple’s Bonjour Conformance Test (“BCT”). PAPPL easily passes the IPP Everywhere tests, but getting the BCT to pass has been a major challenge thanks to some interesting bugs/features in the wireless drivers and firmware used for the Raspberry Pi.
The Wi-Fi chipset used in Raspberry Pi boards is a “FullMAC” implementation - the chipset handles all of the low-level Wi-Fi communications, power management, reading/writing of packets, etc. and just passes on the (processed) information to the kernel driver. So this means the Wi-Fi chip firmware needs to know how to handle low-level networking details and whether a given network packet that is received over Wi-Fi needs to be passed on to the kernel. This is where the problems begin.
The first part of the BCT is a test of IPv4 link-local address handling. With IPv4, link-local addresses (169.254.0.0/16) are typically only used when you don’t have any working Internet infrastructure (more specifically, when there isn’t a working DHCP server). Each network device will try a series of semi-random addresses when it first comes on the network to find an available address. The underlying protocol is defined in RFC 3927 and uses Address Resolution Protocol (“ARP”) packets - a device asks whether any other device on the network is using a particular IP address, and if nothing answers after three attempts it then claims the address by announcing it a few times.
This query process is where things break with the default wireless settings and the Raspberry Pi wireless firmware. ARP packets are not addressed to a particular network device and they really need to be passed on to the kernel for processing. The current firmware for the Raspberry Pi Wi-Fi chipset does not do this, however, preventing the link-local queries from working. In addition, the power saving mode puts the Wi-Fi chipset to sleep in the middle of the BCT tests which run for several hours!
After much research and experimentation, I ended up writing a small script to disable power management and put the Wi-Fi interface in “promiscuous” mode so that the Wi-Fi firmware sends all packets to the kernel and not just the ones with its local addresses:
"set-wireless-options.sh"
#!/bin/sh
iw dev wlan0 set power_save off
ifconfig wlan0 promisc
I call this script from the /etc/network/interfaces configuration file:
"/etc/network/interfaces" (snippet)
# Wireless interface
auto wlan0
iface wlan0 inet dhcp
wireless_mode managed
wireless_essid any
wpa-driver nl80211
wpa-conf /etc/wpa_supplicant.conf
# Replace "/PATH/TO" with the actual path to the script...
pre-up /PATH/TO/set-wireless-options.sh
With those changes I can get the Raspberry Pi Zero W to pass BCT.
At some point I will be making my Yocto layer public on Github, complete with the necessary recipes for PAPPL and other key components needed for a headless print server. I’m also hoping that I’ll be able to get some firmware and/or kernel driver bug fixes to make it unnecessary to use promiscuous mode or turn the power-saver features off - we’ll see…
HTMLDOC 1.9.9 fixes some URL and formatting bugs, as well as fixing the macOS and Windows packages. Changes include:
<FONT FACE="monospace"> (Issue #385)Enjoy!
(June 17, 2020 Update: I re-posted the Windows binaries with a fix for the problems some people reported on Windows…)
PAPPL is a C-based Printer Application framework/library. I am developing it to support future features in LPrint as well as making a Printer Application for Gutenprint. My hope is that it will accelerate the adoption of IPP Everywhere™ and make it easier for people to support other IPP-based licensing programs like AirPrint™ and Mopria®.
PAPPL is licensed under the Apache License Version 2.0 with an exception to allow linking against GPL2/LGPL2 software (like older versions of CUPS), so it can be used freely in any project you’d like. If you want to support the development of this framework financially, please consider sponsoring me through Github. I am also available to do consulting and/or development through my company Lakeside Robotics.
PAPPL supports JPEG, PNG, PWG Raster, Apple Raster, and “raw” printing to printers connected via USB and network (AppSocket/JetDirect) connections. PAPPL provides access to the printer via its embedded IPP Everywhere™ service, either local to the computer or on your whole network, which can then be discovered and used by any application.
PAPPL will include a tutorial showing how to migrate the rastertopcl driver
from CUPS to a Printer Application, which can be used as a recipe for migrating
any CUPS driver.
PAPPL embeds a multi-threaded IPP server and provides callbacks for a variety of events that allows a GUI or command-line application to interact with both the local user that is running the Printer Application and any network clients that are submitting print jobs, querying printer status and capabilities, and so forth.
PAPPL requires a POSIX-compliant host operating system such as Linux®, macOS®, QNX®, or VxWorks®. It also requires the following support libraries:
Most development happens on a Mac, with testing on various Linux distributions and a Raspberry Pi Zero W to ensure that memory and CPU requirements remain low.
PAPPL fully implements the IPP Everywhere™ specification and passes the IPP Everywhere™ Printer Self-Certification Manual tests. PAPPL also implements several IPP extensions used for IPP-based licensing programs to simplify certification, including the CUPS “marker-xxx” attributes, the Get-Printer-Attributes operation using the resource path “/”, and the CUPS-Get-Printers operation.
When configured to support multiple printers, PAPPL implements a subset of the IPP System Service v1.0 specification to allow creation, deletion, and enumeration of printers.
PAPPL takes care of registration of DNS-SD (Bonjour) services for each printer, including the required sub-types, “flagship” LPD registrations, and recommended naming and renaming behavior.
PAPPL supports JPEG, PNG, PWG Raster, and Apple Raster documents in all of the standard color spaces and bit depths. JPEG images are scaled to the destination media size and print resolution using bilinear interpolation, while PNG images are scaled using a nearest-neighbor algorithm to preserve edge detail in bar codes and other non-photographic content. PWG Raster and Apple Raster documents are not scaled as they are normally sent at the proper resolution and size by the print client.
PAPPL also allows drivers to advertise support for other “raw” formats that are directly supported by the printer.
I am investigating options for PDF printing support in a future version of PAPPL. This work is being tracked the Github project.
PAPPL provides a simple driver interface for raster printing, and developers of CUPS Raster drivers will readily adapt to it. Drivers provide configuration and capability information to PAPPL, and PAPPL then calls the driver to start a job, start a page, output lines of graphics, end a page, and finally end a job during the processing of a print job.
The driver interface supports 1-bit grayscale (clustered- or dispersed-dot) and 1-bit bi-level (threshold) dithering using a 16x16 matrix, which is sufficient to support most B&W printing needs. Continuous tone printing is supported using 8-bit and 16-bit per component sGray, sRGB, AdobeRGB, or DeviceN (K, RGB, CMYK, etc.) raster data.
Drivers can also specify “raw” formats that the printer accepts directly - this is most useful for printers that support industry standard formats such as FGL, PCL, or ZPL which are produced directly by common shipping and billing automation applications. “Raw” files are submitted to the driver using a separate “print file” interface, allowing the driver to add any printer-specific commands that are needed to successfully print them.
Aside from printing functionality, drivers can also provide up-to-date status and configuration information by querying the printer when requested by the embedded server. This is an improvement over the CUPS command file interface and allows a PAPPL-based driver to provide details such as updated media information.
Drivers can also support printer identification, usually a sound or a light on the printer, which is a requirement for IPP Everywhere™ and is used to visually or audibly isolate a particular printer for the user.
The embedded server can also provide a web interface to the Printer Application, and PAPPL includes a standard web interface that can be customized and/or overridden. Aside from the usual status monitoring functionality, the web interface can be configured to allow remote users (with proper authentication) to:
You can also add custom pages and content using callbacks, static data, or external files or directories.
Note: An embedded web interface is required for IPP Everywhere™ conformance. The optional features allow a Printer Application to easily support the functionality required for other IPP-based licensing programs.
PAPPL is Copyright © 2019-2020 by Michael R Sweet.
This software is licensed under the Apache License Version 2.0 with an exception to allow linking against GPL2/LGPL2 software (like older versions of CUPS). See the files “LICENSE” and “NOTICE” for more information.
This software is based loosely on the “ippeveprinter.c” code from CUPS.
I’m planning on starting a series of beta releases soon, along with corresponding changes in the LPrint and Gutenprint repositories to use PAPPL. Once I have all three projects working as desired I’ll do a 1.0 release of PAPPL.
EPM v4.5 is a bug fix release and also removes support for some old platforms that I can no longer support. Changes include:
mkepmlist utility did not correctly handle filenames containing the
$ character (Issue #62)Enjoy!
I’m no graphic designer, but I’ve spent enough time fiddling with icons and other graphical elements to at least know how to use the software to produce passable images. I’ve recently made a few parody logos for use in some PWG documentation, which I thought I’d share for your amusement…
All of these images are provided under the CC BY-NC 4.0 license, in case you’d like to use them.
Vendor Logo:
Operating System Logos:
Technology Logos:
Licensing Logo:
Over the years, many people have asked whether they can financially support the development of LPrint, HTMLDOC, and other projects I make available freely on Github. Until recently there hasn’t been a simple way for me to do this, but Github now has a “sponsors” program that allows you to provide monthly donations to developers and projects, and will even match your donations for the first year!
I’ve created a Github sponsor profile to allow you to contribute financially to any of my open source projects and help set the direction and priority of future bug fixes, features, and supported hardware. Thank you for any assistance you choose to provide, whether it is financial or in the form of a bug report, pull request, or other feedback that helps make my software better!
LPrint version 1.0 is now available. LPrint is a Label Printer Application for macOS® and Linux®.
Enjoy!
HTMLDOC 1.9.8 adds a CGI file naming feature, adds support for letterhead images, and fixes some formatting bugs. Changes include:
HTMLDOC.filename META keyword that controls the filename
reported in CGI mode; the default remains “htmldoc.pdf” (Issue #367)L header/footer format ($LETTERHEAD), which
inserts a letterhead image at its full size (Issue #372, Issue #373,
Issue #375)Enjoy!
This is the first candidate release of LPrint 1.0, a Label Printer Application for macOS® and Linux®. Changes include:
lprint options command now reports both English and metric dimensions
for all supported sizes (Issue #14)Enjoy!
This is the second beta release of LPrint, a Label Printer Application for macOS® and Linux®. Changes include:
add, default, delete, and modify sub-commands now support the “-u”
option (Issue #1)lprint devices) or the server
log (for lprint server) so that it is possible to see permission and other
access errors (Issue #8)server sub-command.Enjoy!
This is the first beta release of LPrint, a Label Printer Application for macOS® and Linux®.
LPrint is a label printer application for macOS® and Linux®. I wrote it in response to criticism that coming changes in CUPS will leave users of label printers in the cold…
Basically, LPrint is a print spooler optimized for label printing. It accepts “raw” print data as well as PNG images (like those used for shipping labels by most shippers’ current web APIs) and has built-in “drivers” to send the print data to USB and network-connected label printers. The spooler also tries to keep the labels moving by merging jobs over a single connection to the printer rather than starting and stopping like CUPS does to support a wider variety of printers.
LPrint supports the full range of options and features supported by the embedded drivers - currently all Dymo and Zebra ZPL label printers. Whenever possible, LPrint will auto-detect the make and model of your printer and its installed capabilities. And you can configure the default values of all options as well as manually configure the media that is loaded in each printer.
LPrint also offers a simple network server mode that makes any label printers appear as IPP Everywhere™/AirPrint™ printers on your network. Thus, any macOS, iOS®, or Linux client can use any label printer supported by LPrint. And you can, of course, send jobs from LPrint to an LPrint server on the network.
Finally, LPrint offers command-line and web-based monitoring of printer and job status.
I plan on doing a 1.0 beta release very soon. Enjoy!
This release of codedoc adds C++ namespace support. Changes include:
Enjoy!
So today was my last day at Apple. Apple has been a great company to work for and I’m grateful for my time there. I accomplished most of the things I’d hoped for, particularly getting solid Internet Printing Protocol support in almost all network and USB printers sold over the last 10 years. I chaired the Printer Working Group for about half of my time at Apple, met and worked with a lot of really talented and considerate people, and mentored a few young engineers that have either excelled within Apple or moved on to their next challenges.
Going forward I’ll be taking a little time to reboot and start a new company with my amazing wife. I’ve missed working with her every day these last 13 years and I’m really excited to see where our new journey will take us.
This release of codedoc adds basic markdown support in comments and some other minor improvements.
Enjoy!
Download codedoc 3.3 Install codedoc 3.3 Snap Home Page
Changes include:
--language option to override the default documentation language
“en-US”.I’ve updated the ABNF to REGEX web page with a number of bug fixes and improvements.
Enjoy!
Download ABNF to REGEX Online Form Home Page
Changes include:
HTMLDOC 1.9.7 is primarily a bug fix release with added support for PDF links with targets.
Enjoy!
Download HTMLDOC 1.9.7 Install HTMLDOC 1.9.7 Snap Home Page
Changes include:
HTMLDOC 1.9.6 adds support for wrapping with ­, improves markdown support,
fixes some issues, and optimizes font and PDF handling.
Enjoy!
Download HTMLDOC 1.9.6 Install HTMLDOC 1.9.6 Snap Home Page
Changes include:
­ support (Issue #361)Mini-XML 3.1 fixes some installation issues and adds better error reporting.
Enjoy!
Download Mini-XML 3.1 Home Page
Changes include:
mxmlLoad* functions now print an error when the XML does not start with
< and no parent node is supplied (Issue #256, Issue #259)This release of mmd fixes some regressions in the markdown parser.
Enjoy!
Download mmd 1.7 Install mmdutil 1.7 Snap Home Page
Changes include:
This release of codedoc fixes some buffer overflow issues and improves HTML and markdown support.
Enjoy!
Download codedoc 3.2 Install codedoc 3.2 Snap Home Page
Changes include:
This release of mmd adds support for link titles and code languages, adds
functions for controlling which markdown extensions are supported, and fixes
a number of parsing bugs.
Enjoy!
Download mmd 1.6 Install mmdutil 1.6 Snap Home Page
Changes include:
[reference]) didn’t work (Issue #8)testmmd program now supports running tests from the CommonMark
specification and/or from the CommonMark test suite (Issue #9)mmdGetOptions and mmdSetOptions functions to control which
extensions are supported.mmdGetExtra function to get the link title or code language
string associated with certain nodes.Mini-XML 3.0 is a major release that changes the license to Apache 2.0 with
exceptions for linking to GPL2-only code, hides the definition of the internal
mxml_node_t structure, removes the “mxmldoc” utility (which is now maintained
in the separate “codedoc” project), and fixes several bugs.
Enjoy!
Download Mini-XML 3.0 Home Page
Changes include:
mxmldoc to a new codedoc project whose focus is on generating
code documentation (Issue #235, Issue #236, Issue #237)mxmlSetCDATA, mxmlSetElement, mxmlSetOpaque, mxmlSetOpaquef,
mxmlSetText, and mxmlSetTextf functions caused a use-after-free bug if
the value came from the same node (Issue #241)mxmlSetOpaquef and mxmlSetTextf functions did not work (Issue #244)_mxml_strdupf function did not work on Windows (Issue #245)This release of codedoc improves markdown and HTML support.
Enjoy!
Download codedoc 3.1 Install codedoc 3.1 Snap Home Page
Changes include:
This release of mmd adds support for referenced links, additional inline text
markup, and hard line breaks.
Enjoy!
Download mmd 1.5 Install mmdutil 1.5 Snap Home Page
Changes include:
__bold__, _italic_, ~~strikethrough~~, and hard
line breaks (Issue #4)HTMLDOC 1.9.5 fixes some GUI, markdown, and EPUB issues.
Enjoy!
Download HTMLDOC 1.9.5 Install HTMLDOC 1.9.5 Snap Home Page
Changes include:
htmldoc --help now reports whether HTTPS URLs are supported (Issue #339)mOAuth 1.1 adds support for dynamic client registration and PAM-based authentication backends.
Enjoy!
Download mOAuth 1.1 Install mOAuth 1.1 Snap Home Page
Changes in v1.1:
<moauth.h> header, and a man page for the
library.moauthd to look for “/etc/moauthd.conf” and
“/usr/local/etc/moauthd.conf” as the default configuration file, and install
a “moauthd.conf.default” file as a template (Issue #10)This is the first stable release of mOAuth, a basic OAuth 2.0 client/server implementation for testing and development of OAuth-based services.
Enjoy!
This release of mmd fixes some problems found with Clang static analyzer and
with the mmdutil program.
Enjoy!
Download mmd 1.4 Install mmdutil 1.4 Snap Home Page
Changes include:
mmdutil program’s default HTML stylesheet.mmdutil error messages that incorrectly called the program mmdbook.mmd.c.This is the first release of codedoc, a replacement for the mxmldoc utility that was provided with Mini-XML with several enhancements and bug fixes.
Enjoy!
Download codedoc 3.0 Install codedoc 3.0 Snap Home Page
Changes include:
--header and --footer options now support markdown.mxmldoc program now sets the EPUB subject (“Programming”).--framed basename since frame sets are deprecated in
HTML 5.Mini-XML 2.12 fixes several bugs, updates the build system on macOS and Windows, and updates the markdown and EPUB support.
Enjoy!
Download Mini-XML 2.12 Home Page
Changes include:
MXML_OPAQUE_CALLBACK when you want
to get full strings for inline text instead of separated words (Issue #190)va_copy macro for use with BCC (Issue #211)mxmlNewCDATA and mxmlSetCDATA functions incorrectly added the XML
trailer “]]” to the string (Issue #216)mxmlWrite functions (Issue #228)mxmlWrite functions no longer write the siblings of the passed node
(Issue #228)HTMLDOC 1.9.4 fixes a font sizing bug and reduces startup time.
Enjoy!
Download HTMLDOC 1.9.4 Install HTMLDOC 1.9.4 Snap Home Page
Changes include:
I’ve posted updated HTMLDOC and RasterView binaries for macOS to Github that fix a library dependency issue reported by some users.
Enjoy!
RasterView 1.7.1 fixes a crash bug on macOS.
Enjoy!
Download RasterView 1.7.1 Install RasterView 1.7.1 Snap Home Page
RasterView 1.7 updates the page controls to allow navigation to any page and adds mode buttons for zoom, pan, and color (to show the current mode).
Enjoy!
Download RasterView 1.7 Install RasterView 1.7 Snap Home Page
RasterView 1.6 fixes support for 16-bit per color files, adds support for gzip’d files, and changes the license to the Apache License Version 2.0.
Enjoy!
Download RasterView 1.6 Install RasterView 1.6 Snap Home Page
HTMLDOC 1.9.3 fixes some formatting, markdown, and build issues on specific platforms.
Enjoy!
Download HTMLDOC 1.9.3 Install HTMLDOC 1.9.3 Snap Home Page
Changes include:
This release of mmd adds the mmdCopyAllText function and a new conversion
utility called mmdutil.
Enjoy!
Download mmd 1.3 Install mmdutil 1.3 Snap Home Page
Changes include:
mmdCopyAllText function that returns all of the text under the given
node.mmdutil program for converting markdown to HTML and man files.HTMLDOC 1.9.2 fixes parsing of HTML 4.0 tables and adds support for markdown tables.
Enjoy!
Download HTMLDOC 1.9.2 Install HTMLDOC 1.9.2 Snap Home Page
Changes include:
This release of mmd adds support for the common table extension to Markdown
and is provided under the terms of the Apache License Version 2.0.
Enjoy!
Changes include:
Snaps are a convenient way to build binaries for Linux on multiple architectures and for multiple distributions. However, the current documentation for creating snaps is a bit obtuse, making it hard to get a working snap that can be distributed.
Distribution of Linux applications in binary form has long been a challenge. Thousands of distributions, versions, and architectures make delivering a “universal” application pretty much impossible. The Linux Standard Base was one attempt at solving this by providing a common base set of libraries and interfaces that applications could depend on, however the LSB never truly achieved widespread support. Many vendors have historically chosen to support a small subset of popular Linux distributions, typically only on Intel architecture platforms.
Snapcraft is one of several newer application packaging and distribution mechanisms that are available on Linux that attempt to solve this problem. Snaps generally contain all of the libraries and other prerequisites needed to support the application, solving the library dependency problem, and are isolated from other applications and operating system components making it relatively easy (and safe) to install, update, and remove them.
In addition, Snapcraft provides an automated build system that allows you to build and deploy software built from a Github repository on Intel and ARM architecture platforms.
The documentation for creating your first snap is a bit incomplete, so what follows are the steps I used to finally create a working snap for HTMLDOC. I plan to create snaps for my other projects as time permits.
Start by creating a directory called snap in the top directory of your
project. Next, create a new text file called snapcraft.yaml in the snap
directory. The first line should contain the name of the snap as
registered on the Snapcraft dashboard:
name: htmldoc
After the name you provide the current version of the snap along with a short summary and longer description of what the snap does:
version: 1.9.1
summary: HTML and Markdown conversion utility
description: |
HTMLDOC is a program that reads HTML and Markdown source files or web pages
and generates corresponding EPUB, HTML, PostScript, or PDF files with an
optional table of contents.
If you have an icon (most applications do), list it using an icon line:
icon: desktop/htmldoc-128.png
Next the grade and confinement lines tell Snapcraft how to treat your snap.
A stable application will have the following lines:
grade: stable
confinement: strict
An application under active development should report “devel” and “devmode” instead:
grade: devel
confinement: devmode
The application itself is specified in a section called apps:
apps:
htmldoc:
command: desktop-launch $SNAP/bin/htmldoc
desktop: share/applications/htmldoc.desktop
plugs: [home, network, x11]
Here we define a single application called “htmldoc” that is started using the
desktop-launch program. All GUI applications need to use desktop-launch so
that the application is granted the necessary access to the desktop. The
$SNAP variable specifies the snap directory, in which the htmldoc executable
can be found under the bin subdirectory. The application is registered with
a desktop file so it can be run from the application launcher provided by the
desktop environment you are using, e.g., GNOME. The plugs value lists a
named set of things (interfaces) your application needs to use - in this case
“home” for the user’s home directory, “network” for network access, and “x11”
for desktop access. Other plugs values
are incompletely documented, so use the snapcraft interfaces command to list
the currently available values.
Finally, we need to define how to build the application from source. Since HTMLDOC is a typical autoconf-based project we can use the “autotools” plugin with a single build part called “main”:
parts:
main:
plugin: autotools
source: .
after: [desktop-gtk3]
build-packages: [libfltk1.3-dev]
The after line specifies that HTMLDOC is a desktop application with specific
requirements. A FLTK application should use the GTK+ 3.x rules
(“desktop-gtk3”), while Qt and GNOME applications should use the corresponding
strings (“desktop-qt4”, “desktop-qt5”, or “desktop-gnome-platform”,
respectively). I found the
Snapcraft parts wiki particularly
useful for getting this part right - search for “desktop-“ for details.
The build-packages line lists the additional packages required by your
application, in this case “libfltk1.3-dev” (the Fast Light Toolkit) used for
HTMLDOC’s GUI.
Most applications have additional data files they need to run. The SNAP
environment is set to the installed snap path when your application is run.
For example, HTMLDOC calls a function on startup that checks for the SNAP
environment variable to override the default PREFIX/share/htmldoc directory
that is compiled in:
const char *snap;
static char datadir[1024];
if ((snap = getenv("SNAP")) != NULL)
{
snprintf(datadir, sizeof(datadir), "%s/share/htmldoc", snap);
_htmlData = datadir;
}
After you have installed Snapcraft and
the snapcraft tool (sudo snap install snapcraft --classic), you can build
your snap from the current directory by running the snapcraft tool, e.g.:
snapcraft
If successful, you can install the snap locally with:
sudo snap install NAME_VERSION.snap --devmode --dangerous
where NAME is the name of your snap and VERSION is the build version. Once
installed you can run the application to test that everything is working.
After a bunch of experimentation I have finally resolved the GUI bug in the
HTMLDOC snap, so you can now get HTMLDOC on Linux as a
snap package! Run snap install htmldoc to
install the official binaries on Linux.
Enjoy!
This release of mmd fixes a number of bugs, adds C++ support, and adds a
mmdLoadFile function that loads Markdown content from the FILE pointer.
Enjoy!
Changes include:
mmd.h header now includes the C++ extern "C" wrapper around the C
function prototypes.mmdLoadFile function that loads a markdown document from a FILE
pointer.HTMLDOC 1.9.1 is primarily a bug fix release that also adds limited support for UTF-8.
Enjoy!
Download HTMLDOC 1.9.1 Home Page
Changes include:
<element property> is written as
<element property="property">.Mini-XML 2.11 fixes a number of bugs, adds support for reproducible builds, cross-compilation, and enumeration of element attributes, and adds support for generating EPUB documentation using mxmldoc.
Enjoy!
Download Mini-XML 2.11 Home Page
Changes include:
mxmlElementSetAttrf did not work with some versions of Visual Studio
(Issue #184)mxmlElementGetAttrByIndex and mxmlELementGetAttrCount functions
(Issue #185)SOURCE_DATE_EPOCH environment
variable for reproducible builds (Issue #193)mxmlNewOpaquef and mxmlSetOpaquef functions to add and set formatted
opaque string values.@exclude format@ comments to exclude
documentation based on the output format. The format string can be all to
exclude documentation for all formats or a comma-delimited list such as
@exclude man,html@.zipc v1.2 adds ZIP read support using the zipcOpenFile, zipcFileGets, zipcFileRead, zipcFileXMLGets, and zipcXMLGetAttribute functions. It also fixes use from C++ code, fixes Visual C++ support, and adds support for the %f format in the zipcFileXMLPrintf function.
Enjoy!
EPM 4.4 is a maintenance release that fixes RPM packaging and several build issues.
Changes include:
/usr/local (Issue #45)Enjoy!
HTMLDOC 1.9 is a limited feature release that adds support for Markdown input and EPUB output.
Changes include:
Enjoy!
zipc v1.1 adds a zipcCopyFile function to efficiently copy files into ZIP
containers and fixes an issue with some EPUB and OPC applications.
mmd v1.0 is a miniature markdown parsing “library” consisting of a single C
source file and accompanying header file. mmd v1.0 mostly conforms to the
CommonMark version of markdown syntax and supports a couple (otherwise
undocumented) CommonMark extensions.
zipc is a simple ZIP container “library” consisting of a C source file and accompanying header file. Version 1.0 implements writing of ZIP containers with files smaller than 4GB. Files can be stored as-is or compressed with deflate (gzip) compression.
HTMLDOC 1.8.30 fixes some known build and formatting issues. Changes include:
RasterView 1.5 adds support for Apple raster files.
All of the bug reports from the old server have been migrated to the Github issue tracker.
I have moved the main msweet.org web site and projects to Github in order to spend less time maintaining servers and more time programming. All of the recent releases are already available in the corresponding Github projects, and I will be migrating the bug reports to the Github issue tracker over the next couple days.
In lieu of mailing lists, please use the Github issue tracker to ask questions or report problems with the new web site.
Mini-XML 2.10 is now available for download from:
https://github.com/michaelrsweet/mxml/releases
Mini-XML 2.10 fixes some stack overflow, XML, and API issues.
Changes include:
Enjoy!
HTMLDOC 1.8.29 is now available for download from:
https://github.com/michaelrsweet/htmldoc/releases
HTMLDOC 1.8.29 fixes some known build and formatting issues, updates support libraries, and drops support for OpenSSL.
Changes include:
Enjoy!
EPM 4.3 is now available for download from:
https://www.msweet.org/downloads.php/epm
The new release fixes several issues on Linux and OS X and adds support for signed packages.
Changes include:
Enjoy!
RasterView 1.4.1 fixes builds on Linux and includes binaries for OS X and Linux.
RasterView 1.4 adds support for viewing Device-N files and improves the display of PWG Raster page attributes.
Mini-XML 2.9 is now available for download from:
https://github.com/michaelrsweet/mxml/releases
Mini-XML 2.9 fixes a bug in the mxmlLoad* functions when using the default (MXML_NO_CALLBACK or MXML_TEXT_CALLBACK) callback.
HTMLDOC 1.8.28 is now available for download from:
https://github.com/michaelrsweet/htmldoc/releases
HTMLDOC 1.8.28 fixes some known security issues and formatting bugs.
Changes include:
Enjoy!
Mini-XML 2.8 is now available for download from:
https://github.com/michaelrsweet/mxml/releases
Mini-XML 2.8 fixes some minor platform and XML issues.
Changes include:
Enjoy!