On 03.02.2009 16:43:12 Chris Bowditch wrote: > 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.
Understood. Can do. But I think it's also problematic if some output formats default to true while others default to false. Source for confusion especially for new users. If it's about file size, we better see to it that we can compress images in AFP. That will easily make up for the larger files because of embedded fonts. ;-) Anyway, I don't really expect different output if the fonts are embedded. You'd rather do away with the possible problem that FOP did the layout with a different font than is actually used on the production machine. There are pros and cons, that's all. > > > > 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 > Jeremias Maerki