You are right, the way the single fonts from the font collection are added at the moment they are all registered as the same size ... strange. I'm sure it worked at least a year ago, as I tested it on a customer project (the customer wanted to use Windows fonts in the PDF, and some Asia fonts are .ttc files on Windows).

But I think the only think I tested was that the fonts are used correctly. If I remember correctly the .ttc had the same font just with different unicode code ranges in each font inside the collection. And this works fine. I don't think I tested that the font collection really had different weights or styles.

Beside this I would change the way the cache is handled a little bit. I would always use the metric cache, i.e. the builder should always create an instance of the cache; You would just be able to override it from outside to share the cache between runs. This would allow to remove some if(cache == null) checks and simplify the code. FSDefaultCacheStore is not that heavy(memory and GC wise) so wasting it would not harm that much.

You might also want to document that all FSCacheValue's must be immutable. Well ok, saying it must be thread safe is nearly the same.

You could also make a default NOP cache implementation and use that by default if the user does not provide a cache implementation. This would not waste memory (as the NOP cache could be a singleton) and would also allow to simplify the code as the cache would never be null.