AFP: Embedding fonts

[Jeremias Maerki <de...@jeremias-maerki.ch>]

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

Re: AFP: Embedding fonts

[Jeremias Maerki <de...@jeremias-maerki.ch>]

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

Re: AFP: Embedding fonts

[Chris Bowditch <bo...@hotmail.com>]

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