Right now, the AFP output just loads the configured bitmap and outline fonts for metrics but it requires that the same fonts are correctly set up on the target AFP viewer or printer. Even just registering the fonts for FOP is tricky enough. Doing that for every target environment is sometimes even trickier. The easiest way to simplify the whole thing would be to embed the AFP fonts like we do for PDF and PostScript. That way you can be sure that you have the fonts available on the target environment and you're working exactly with the fonts that you did the layout with. This also seems to be best practice as I learned from an AFP expert a few days ago.
Embedding the fonts is easy enough: you can just copy the files as new objects into the file-level resource group. IBM's AFP Workbench will still ignore the embedded fonts and replace them for system fonts but that's pretty irrelevant. Pixel-oriented AFP viewers and IPDS environments will be able to use the fonts. As for the decision whether to embed the font or not, we could do it the same way we do it for the other output formats: the configuration specifies which fonts NOT to embed. But obviously, that would result in a behavioural change of the AFP output by default. So I'm asking around if everyone would be ok with that or if anyone sees a problem with it. Another change I'd probably do in this context is to create "Coded Fonts" in the resource group. Basically, this just groups the font and the codepage together in one object that can be referenced my "Map Coded Font". I learned this is best practice, too. Doing this should also make it easier to implement double-byte functionality once that pops up on the priority list. Jeremias Maerki
