You're on the right track (subclassing Font) but I don't think it will be easy. For one, it might be not enough to only have widths (/W entry). But since you have the array you pretty much just make look up in that array according to your chosen encoding to implement character_with_by_code. compute_width_of is essentially a sum of individual character width look ups.
In theory you can drop /W from your document as it's optional, saving a few more bytes.
I think an easier approach would be to subclass Font::TTF class, give it your font file for metrics but change the objects it generates for PDF.
However, This approach is counterproductive. PDF is has Portable in its name and your approach is not portable. It requires external resources. If your user for whatever reason don't have the resource the document will be blank, no fallback font will be used. This is not as unlikely situation as you might think: user might not have internet connection, user might use a renderer that doesn't download missing fonts (i.e any other than Adobe Acrobat), etc. Then there are issues with the base font lookup. It's not very robust. The font is identified by a string, not any globally unique identifier or concrete address. This can fail in a number of ways too: user has a font installed with the same name but it doesn't provide required glyphs, user has the font installed but system identifies it by a different string, etc.