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

Reply via email to