Here's what I have in mind. pack, in the abstract, takes a substring of the format string, starting at some offset, and an argument to pack, converts the argument to a string that gets appended to the result returned by pack, and updates the offset in the format string so the next argument can be processed. Maybe that's also how the code works, maybe not, as I said, I haven't yet looked. If it were possible for a format item, let's call it Y, to "intercept" the string produced by whatever what follows it in the format string, and return the "printable hex" version as the result (pretty much as the H format does now to the string argument it expects in the argument list), then we would already have all the integer width/endian-ness/sign-edness processing done for us by existing code. Maybe Y[o] could get us octal or Y[X] would yield hex with uppercase A-F. But the heavy lifting would be done by whatever follows in the format string. So

  pack("Yv", -1);      # yields "ffff"
  pack("YN", -1);      # yields "ffffffff"
  pack("Y[X]v", -1);   # maybe yields "FFFF"
  pack("Y[o]v", -1);   # maybe yields "177777"
  pack("Y[b]c", 15);   # maybe yields "00001111"
[download]

The point being, what follows the Y construct determines the content (including length) of the string, and the Y construct turns that string, wherever it came from, into something printable.

Unpack would do the reverse, but it would be a little more complicated, because it would have to determine, from what follows in the format string, how long a string is expected. Knowing that, it could convert a printable string into whatever string the following format expects.

This would make the job of the Y format item nearly trivial, but it would put some demands on the pack/unpack code, like being able to determine the length of the string a format string expects to unpack. If we restricted what could follow Y to a single letter (no skipping, repetitions, etc.), that could easily be provided, and would be adequate for handling all the integer and floating point values, which are the major suspects in packing into unprintable strings.

BrowserUk's suggestions about how to generalize the concept are the sort of wisdom I was hoping for from this forum. I'd like to refine the idea some before digging into the code and maybe bouncing it off p5p.