Jeremias Maerki wrote: Hi Jeremias,
<snip/>
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.
The ability to embed AFP Fonts would be a useful feature.
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.
I don't like the idea of changing the default behaviour as existing users may suddenly get different output when they upgrade their FOP version. Embedding fonts also increases the size of the AFP Output File. AFP Users tend to be pretty fussy about the size of AFP Output as the key benefit of AFP over other formats is its concise nature. Can we not just add a new attribute embed to the font definition that defaults to false? That is my preference.
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.
Support for Coded Fonts would be great too. Most AFP Software supports Coded Fonts, but currently FOP can't deal with them and insists on specifying the code page and character set separately.
Thanks, Chris
