Certainly no simple formula for the catalog B-tree. In part that is because the size of the catalog is determined in part by the lengths of the file and directory names (even more so on HFS Plus, where the keys in index nodes are variable length). And for volumes that are modified over time, the order of operations will affect the size of the B-tree in complex ways. I'm sure you could come up with a statistical guess based on average name lengths, average density of nodes (i.e. how "full" they are), etc. .... If that's too complicated, you could always fall back to assuming a constant size (maximum or average) for all of the records. Don't forget that for thread records, the key is of fixed size but the data is variable (since it contains a variable-length string).
That's what I did for the mkhybrid code - I didn't want the catalog "file" to grow, so by trial and error, I set the initial size of the catalog file to twice the "default" used by the libhfs routines in hfsutils. This seems to work OK for virtually all cases (if this is isn't big enough, the mkhybrid code uses a brute force approach and 're-creates' the HFS side of the file system with a new default size twice as big again ...).
James Pearson