the Papertrail

Monotype Computer Interface—Complete at last!

Posted on 2026/05/28 by kpmartin Posted in Caster Computer Control, Equipment Acquisition, Repair, and Maintenance, Kevin — No Comments ↓

After far too long the computer interface for my Monotype Composition Caster is complete. In this case, “complete” means that it is a single self-contained unit with no straggling wires.

My last step was to add a housing/support bracket for the power plug connector and 24 volt power supply. The design for this had to be adjusted so the entire unit would still fit on the caster.

Click on any photo for a larger version.

Here’s how it looks on the caster with the air regulator, filter, and pressure gauge installed:

I guess this now qualifies as a finished prototype. I will be updating my drawing files to match how this was made, since as the work progressed I deviated from the original design where the changes seemed like an improvement. The updated design will have some other changes on the internal parts to accommodate a proper case, to replace some of the obsolete components on the PCB, and to relocate the internal cycle sensor.

I should also change the pneumatics on my caster so this filter/regulator unit feeds the entire caster, and a flexible hose tapping off this would connect to the computer interface. This would mean that features like Unit Shift would work, and also that there would be less weight hanging off the front of the interface.

Papermaking in Japan—Part 5

Posted on 2026/05/20 by kpmartin Posted in Hand Papermaking, Kevin, Oguni Washi intensive workshop — 1 Comment ↓

Other notes

This is a bit of a wrap-up along with some reference links shared during the workshop

Papermaking in Japan—Part 4

Posted on 2026/05/16 by kpmartin Posted in Hand Papermaking, Kevin, Oguni Washi intensive workshop — No Comments ↓

The actual papermaking workshop

At last, on to the actual workshop!

Please also see the other parts of this series:

Monotype Fo(u)nt Scheme Oddity

Posted on 2026/04/21 by kpmartin Posted in Font Casting — No Comments ↓

I was casting some type this week when I noticed an oddity on the font schemes listed in the back of the The Monotype Casting Machine Manual, which is the basis for my usual casting font schemes. The font scheme gives the count of how many of each sort are cast to make up a font, and these were based on English text from around the early twentieth century.

Although some foundries would sell type with uppercase, lowercase, points (punctuation), and figures each being packaged separately, allowing the customer to make their own upper-/lowercase balance, the Monotype schemes are for a complete set including both upper- and lowercase as well as figures and points. There are two basic schemes: The ‘body’ scheme represents the letter frequencies encountered when composing running text in full sentences and paragraphs. The ‘jobber’ scheme represents the frequencies encountered when composing titles, headings, point-form lists, and other such items which generally require many more uppercase letters.

If you compare the two classes of schemes, it is generally the case that the counts of lowercase are the same, but in the Jobber schemes, the uppercase count if increased by about 2 less than 0.28 times the count of the corresponding lowercase. So, for instance with the letter ‘e’, either scheme has 118 lowercase, the body scheme has 12 uppercase, and the jobber scheme has 44 uppercase, which is close to 12+0.28×118-2 (equaling about 43).

That 0.28 figure is very vaguely in the ballpark of the reciprocal of the average word length (5 letters), and so what you would expect for titles, where pretty much every word is capitalized.

For the rarer letters, this formula gets fudged a bit, with uppercase ‘Z’ having 4 sorts in either case, and ‘F’ having 6 in body and 10 in jobber, but with 24 lowercase, the formula yields 13.

Some other letters are one or two extra uppercase away from the formula as well.

The real outlier, though, is M, where the jobber scheme actually has 4 fewer than the body scheme, 14 in jobber, 18 in body. It seems that the inconsistency is in the count in the body scheme, where, for instance M far outnumbers L, C, or U (6, 8, and 6 respectively) which have similar lowercase counts (14 or 16).

It is not clear if this is a typo in the table itself, showing 18 instead of 8, or whether they did not, in fact use general English text as their sample, but instead their own books and literature, which would be peppered with the capitalized “Monotype” trademark throughout!

As an aside, my earlier remark about using “early twentieth century” text as a sample is reflected in the figure frequencies, where 1 and 9 are heavily represented, as one would expect when usually referring to years in the 20th century. I should probably modify the schemes I use to add more 2’s and 0’s to better reflect the years one might now be mentioning.

Monotype Computer Interface Compatibility Woes

Posted on 2026/04/14 by kpmartin Posted in Caster Computer Control, Equipment Acquisition, Repair, and Maintenance, Kevin — No Comments ↓

MS Windows

So far, I have been using a MS Windows system to connect to my Monotype computer interface. The software that runs on the computer is written in Java so it can be run on other operating systems without needing to be modified or compiled for that system. All you need is to have a sufficiently new Java installation on the computer.

Moving to Linux

I had recently set up a Linux system (specifically, Ubuntu) and one thing I wanted to try was my computer interface.

After a bit of fiddling around, one change in the Java code, and one change in the firmware on the interface, I got it to work. Sort of. There are some issues, though:

The first is that, as with many other devices, Ubuntu presents the connected USB devices as special files in its file system. By default, only root (the “super user”) can access these files, so for now to get things to work I must use the root account to grant access to these special files to my (unprivileged) user account. Each time the USB is disconnected and reconnected, a fresh special file entry is made, so the permissions must be fixed again.

Ubuntu provides a solution to this problem. There is a specific shell script which is run when changes are made to these special files, and this script runs as root, so it can sniff the new files and, based on what it finds, do things, including setting permissions, to suit. For this interface, code can be added to the script to recognize the Monotype interface and set the required permissions automatically.

The second problem is that the communications seem a bit flaky. At times the Java code is unable to obtain even basic information like the device type. It seems that the code on Linux that is communicating with the USB interface does not do any retrying if there is a transient error. Some analysis reveals that at some level this appears as the standard Linux error code EPIPE, but other USB-specific code is referring to a STALL condition on the interface. For some reason this is not a problem on my Windows systems; perhaps either the transient errors are not occurring, or some code in Windows automatically retries on error. This still needs some investigation.

The final issue, for which I currently have a fix on Linux, is that in the Monotype interface, I am using the code provided in the microcontroller’s built-in ROM to manage the device end of the USB interface. This code, however, only gives me the choice of two USB device classes: Mass Storage (like thumb drives and external hard drives) and Human Interface Devices (like mice, keyboards, and such). Of the two only the HID class really matches my communications requirements.

Having some weird unknown HID plugged in doesn’t bother Windows at all, but on Linux, any plugged-in HID gets “claimed” by the system—whether or not it knows what to do with it—and so my Java code was told it could not access the interface because it was already in use. Fortunately, the USB library I am using (known as ‘libusb’ and its Java wrapper ‘usb4java’) has the ability to claim the interface from the system when necessary.

What about MacOS (Linux but not really) ?

I also want this interface to work on MacOS, and using Java should be able to make this work; MacOS is essentially Linux under the covers.

Unfortunately, based on my reading, MacOS has its hold on HIDs well locked down, and it is essentially impossible to wrest control of an HID from the system.

There is the possibility of using another library called ‘hidapi’, which was originally separate from libusb but now appears to be part of newer versions of libusb. It also appears to be part of newer versions of the usb4java Java wrapper so I should be able to access it from Java. Whereas libusb uses ‘ioctl’ (“I/O Control”) system calls to do its work and so needs to own the interface, hidapi uses ‘read’ and ‘write’ system calls instead. This means the system can keep its hold on the interface, and so, at least in theory, this should work on MacOS as well. The only oddity is that the data for the read and write calls includes an extra byte or two, apparently to tell the system which “endpoint” (a USB concept) to communicate with.

So this solution needs me to find and use a newer usb4java that also supports hidapi, and also to ascertain what these extra bytes really are in the read and write data.

But the real root of the problem is that the Monotype interface is not an HID; it is really a custom device and should not be masquerading as an HID-class device at all. The ROM in the microprocessor is only really providing a thin wrapper for the actual embedded hardware USB controller, and I should be able to make my firmware use this controller directly, and identify itself as a custom-class device.

This may, however, open its own can of worms, for instance making Windows freak out and try (and fail) to find a suitable driver every time you plug in the USB cable. As well, I don’t know if there actually is an official “custom class” to use; if I just pick some random class ID it could turn out to be a real published class (or could become one in the future), with standards that my device does not follow at all.

But I think the latter approach is the better one in the long run, though it could run into a roadblock that requires me to roll back to the HID approach and using hidapi. This approach also means that if I end up having to change which microcontroller I use, I’m not relying on the ROM support and so any microcontroller with a USB interface should suit.

Papermaking in Japan—Part 3

Posted on 2026/04/05 by kpmartin Posted in Kevin, Oguni Washi intensive workshop — No Comments ↓

Extracurricular activities

Outside the actual workshop, we had various activities and side trips to occupy our downtime.
For other parts, please see:

Papermaking in Japan—Part 2

Posted on 2026/03/30 by kpmartin Posted in Kevin, Oguni Washi intensive workshop — No Comments ↓

Travel and sightseeing

For my trip to Japan for the Oguni Washi intensive workshop, I opted to stay a few days in Tokyo beforehand. This gave me a better combination of travel time and airfare for the flights, and also gave me some time to adjust to the 13-hour time difference from home.

Please also see the other parts of this series:

One nice surprise was the cost of things, in general. I’ve heard that Japan has a reputation of being an expensive place to travel, but I found that the costs for meals and local transportation were not much different than back home, and the hotels, at least the ones I stayed at, were cheaper than at home. It was very convenient that at the time, the Japanese Yen was worth almost exactly one Canadian cent, so converting prices in my head was trivial. Given the high standards for the transportation systems, it was actually much better value that at home. Read more ›

Papermaking in Japan—Part 1

Posted on 2026/03/25 by kpmartin Posted in Kevin, Oguni Washi intensive workshop, Past Events — No Comments ↓

Introduction

I recently returned from a week-long workshop on Japanese papermaking at a shop in Japan. The workshop ran from March 15th-21st, and was held at Oguni Washi, located in Oguni, about 20 minutes’ drive south of Nagaoka, in the Niigata prefecture of Japan.

This post is just an introduction. Please also see the other parts of this series:

The workshop was organized and facilitated by Paul Denhoed, who in the distant past was also involved in the origins of the Papertrail, and hosted by Hiroaki and Chihiro Imai who run the paper mill. Paul is originally from Toronto but has been living in Japan for 25 years. The Imais only know a few words of English, so Paul, who speaks fluent Japanese, provided services as an interpreter. Paul did most of the teaching, with Hiroaki, whom we called Imai-san (more or less “Mr. Imai” but gender-neutral) doing most of the demonstrations and material preparations. Chihiro (also “Imai-san” when Hiroaki was not around) filled in the gaps when Horiaki was out on an errand or busy with other work.

There were four participants from diverse backgrounds: myself, Alex Bonton from Montreal but originally from France, Michele (an Italian name, so pronounced mee-kay-lay) from Singapore but originally from northern Italy, and Clara from Florida but originally from Argentina. Alex has recently hosted a su-making workshop at Bishop’s University which I attended.

L-R: Clara, Michele, Paul, Alex, myself, and Imai-san in front of the studio (photo by Imai-san)

The Imais got into paper-making over 25 years ago, sort of inheriting the craft from Chihiro’s parents. They have been running the paper mill as a commercial enterprise for many of those years. Some of the paper they make finds its way onto labels for bottles of sake (rice wine) produced in the area, and their paper was also used as wallpaper (and ceiling covering and upholstery) throughout the Nagaoka civic centre.

They produce paper from kozo that they grow, when possible cooked using alkali from wood ash from their own cooking stoves, with other materials like kaki-shibu, konnyaku, and tororo-aoi roots being supplied from elsewhere. Some of the paper they produce qualifies as Oguni-gami (a controlled name referring to paper made using particular traditional materials and methods), but in the interests of commercial viability they will also use other methods, such as cooking with soda ash or beating using a naginata beater instead of by hand, producing paper which cannot be sold as “Oguni-gami”.

The workshop covered papermaking starting from the kozo bark all the way to finished paper, plus some additional topics such as traditional Japanese stab bindings, decorative sheet-forming, and paper treatments with konnyaku and kaki-shibu. In this spring workshop we also covered snow bleaching; there is also sometimes a fall workshop where the participants instead get a try at harvesting and stripping the kozo stems.

This post is the start of a series covering our journey through the papermaking process.

Monotype Computer Interface—Creeping Obsolescence

Posted on 2026/02/10 by kpmartin Posted in Caster Computer Control, Kevin — 1 Comment ↓

It appears that my progress on my Monotype computer interface is so slow that parts obsolescence is catching up with me.

A few months ago I was looking into future supply of parts for the interface and found that the UDN2987 IC’s I was using had been discontinued by the manufacturer and were no longer available. These convert the individual air line signals from the low-power digital outputs of the microcontroller to high-current sources that can activate the solenoid pneumatic valves. There was nothing else with similar functionality (8 logic inputs driving 8 high-current loads) available either. All the new high-current drivers either use a custom single-bit interface to control them or use I²C (a standard for communications between digital components). This would ultimately simplify the circuit because these can all be chained and so use only one digital output on the microcontroller , whereas the current circuit needs 31 digital outputs, one for each air signal. But is still requires changing the circuit and PCB layout.

Just this week, I received a notification that the NXP LPC1343 microcontroller chip I’m using was also becoming obsolete, and only available up until about a year from now. It is also implied that the entire family of microcontrollers was discontinued. I might switch to one of the ATMega microcontrollers used in Arduino products. That should at least ensure me reasonable support into the future.

So it looks like I’m in for a major circuit redesign, but it should ultimately simplify the circuit and require a lower-line microcontroller. All that will be needed is one or two digital outputs (or I²C lines) and one analog (A/D) input to read the caster cycle sensor, a far cry from the 32 signals in the current design. On the other hand, this will allow the PCB to shrink a bit, providing an easier fit (it looks like the current version will require removing the ribbon take-up spool). The new controller version would also move the cycle sensor and re-arrange some of the other parts.

And of course the firmware for the microcontroller will also change, but the basic logic should be the same. What would need to be adapted is timing code and USB handling.

All this while I’m still making the bracket to attach the power supply to the controller I have, to finally make it into a single unit with no dangling wires!

Grimsby Wayzgoose, April 25^th, 2026

Posted on 2026/02/05 by kpmartin Posted in Grimsby Wayzgoose, Upcoming Events, Us — 2 Comments ↓

The 48^th Grimsby Wayzgoose book arts fair will be held on Saturday, April 25^th, 2026, and the Grimsby Public Art Gallery in Grimsby, Ontario.

This fair features dozens of artists and artisans selling their book-arts-related wares, including paper, marbling, fine press books, and printed ephemera. the Papertrail will have a table there selling some of our handmade paper, marbled paper, and other supplies for the book arts. If there is something specific you want to purchase from us, contact us ahead of the fair and we can bring your order along with us, so you avoid shipping charges.

This event takes place at the Grimsby Public Library building, 18 Carnegie Lane, Grimsby, Ontario, and runs from 9am to 5pm.

Admission is free, and free parking is available at both the front and rear entrances of the library as well as any of several nearby municipal parking lots. If you want to use public transit, the library is less than a block away from the Grimsby GO station (note this is a bus-only service; the GO Train does not stop in Grimsby, though there is infrequent Via Rail service).