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
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
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
Extracurricular activities
Outside the actual workshop, we had various activities and side trips to occupy our downtime.
For other parts, please see:
Tagged with: Paul Denhoed
Papermaking in Japan—Part 2
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
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
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 25th, 2026
The 48th Grimsby Wayzgoose book arts fair will be held on Saturday, April 25th, 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).
BOUND Book Arts Fair, December 7th, 2025
The annual BOUND Book Arts Fair will take place this year on Saturday, December 7th, 2025, at the Arts & Letters Club, 14 Elm Street, in Toronto (just west off Yonge, a block south of Gerrard).
This fair will feature limited edition handmade books, artist’s books, prints, broadsides, cards, ephemera, and more. We’ll have a table there (on the third floor) selling paper, both marbled and handmade, bookbinding tools and supplies, as well as a few letterpress things too!
The fair is open from 11am-5pm and admission is free.
Whitlock Timing Issue?
When setting up the Mackenzie Printery‘s Whitlock press for this summer’s Marshville Heritage Festival, I noticed that the press bed has a line marked across it clearly labeled “H L”. I assume this stands for “Head Line”, which is the line on the bed which aligns with the leading edge of the sheet of paper (or, perhaps, just clears the grippers).
I had noticed that the actual forme of type on the bed, which was printing at the correct place on the paper, was well over this line and in fact almost hanging over the edge of the bed. I felt this might be an issue with the timing of the press.
I took a copy of the poster that had just been printed, placed it on the inked forme still in the press (in the same orientation as the original impression), with the edge of the paper lined up with the “H L” mark, and rubbed the back of the paper to take a crude impression of the form. The two impressions were about 1⅛″ apart. This made me feel that the bed was off by a tooth in the gearing that drives it. I also took an impression of the bed drive gear using the oil/grease that was on it, and determined that the drive rack had a pitch of ¾″.
Later, when the forme had been removed, I placed some lumps of Plasticine on the press bed to measure exactly how the edges of the impression area of the cylinder lined up with the bed. This required a bit of timing finesse and manual turning of the press to get good measurements rather than just smearing off the top of the Plasticine. This is how things looked at the leading edge; unfortunately, camera perspective distorts the apparent measurements off the measuring tape. The 7″ mark lines up with the “H L” line, and the impression in the Plasticine is about at the 5⅞″ mark, confirming my other measurement.
There is another fainter line on the bed ¾″ from the “H L” line, but this seems so faint, it might not be factory-original.
I did the same sort of measurement at the trailing edge, and found that the trailing edge of the cylinder was ¾″ away from the raised edge of the bed (again, perspective distorts the apparent measurement):
Together, these observations imply to me that the bed should be shifted one tooth on its rack, so that the printing area of the cylinder lies between the “H L” line and the stop at the foot of the bed.
This ¾″ shift would still leave a ⅜″ discrepancy, but I think this represents the difference between the leading edge of the cylinder and the area that is safe from gripper damage. This allows a generous ⅜″ space for grippers to grab the sheet edge between the cylinder leading edge and “H L”. One of the formes we had been printing has a border all round which we want close to the edge of the paper, so this would have to be placed on the bed beyond the head line, but this is fine because the grippers on the press are set very close to the edge of the sheet.
However, the same timing discrepancy might also be caused by the cylinder itself being out of position by one tooth so I would like to do a bit more research before actually shifting the bed. The grippers and sheet lifters are all driven by the cylinder itself and would not be affected by retiming the cylinder, but changing the timing these two ways would have subtle differences in the relative motion of the cylinder and bed, particularly on the bed’s return stroke. I would have to look closely at the relative timing of the bed motion vs. when the cylinder lowers to impression height and rises again.
Changing the timing would mean that printing close to the end of a full-height sheet would require the forme to be right against the raised edge at the foot of the bed, with no room for a chase. As things stand currently there is ¾″ of room for a chase frame.
There is another Whitlock press in Cumberland, near Ottawa, and although it is not identical (it does not have the reversing stacker), I’m hoping the bed and cylinder motion are the same. I’d like to get the chance to visit it and make some measurements on it next time I’m in the area. I could measure the actual limits of the bed’s motion, and also observe the cylinder position when the bed stops moving at either end of its stroke.