Just some details on what is currently possible and what not (for PDF

Type 1: embedded or referenced, WinAnsi only
  - embedded subset, CID (default mode)
  - embedded WinAnsi (full font is embedded 1:1, no subset)
  - referenced WinAnsi (works, but is restricted to WinAnsi)
  - referenced subset, CID (no errors by FOP, but Acrobat throws errors)

One thing that might be worth investigating is referencing a font and
using Unicode characters directly (i.e. not the subset mode). I think
that should be possible.

I think the embed="false" setting could be interesting, especially for
PostScript output where you usually have the fonts installed on the
target printer so you can make smaller print files. For PDF, this is
only interesting for closed environments where you have full control
over the installed fonts on every system.

I don't think we need to change embed-url just now. If there's a better
name for specifying the main font file (not all fonts have just one font
file), then we can always support both for a longer period, right?

On 13.07.2007 16:04:59 Chris Bowditch wrote:
> Andreas L Delmelle wrote:
> <snip/>
> > As far as I can judge, /if/ the names of embedded fonts forcibly need  
> > to be altered because they would be overridden by local fonts in the  
> > PDF viewer, then it could turn out to be pretty simple --for someone  
> > who knows what he's doing :/
> > Leave the font-family name alone, and modify related classes in  
> > org.apache.fop.pdf to skip the step of actually embedding the font,  if 
> > the configuration did not specify an embed-uri.
> I envisage a minor problem with omitting the embed-url. Currently FOP 
> uses that to generate metrics on the fly. So it seems Font Referencing 
> and auto metrics generation are mutually exclusive :-/
> What we need is to be able to change the attributes on font element, so 
> that there is an explicit attribute that specifies whether embedding is 
> on/off instead of overloading embed-url to do 2 functions. Something 
> like this:
> <font metrics="arial.xml" font-defintion="arial.ttf" embed="false">
> Although changing configuration files in a backwards incompatible way is 
> not likely to be popular with the users!
> Chris

Jeremias Maerki

Reply via email to