Victor Mote wrote:
Yes, this can get ugly. If anybody knows of a way to find the physical font
file from an awt Font object, please speak up.

Currently (as of 1.4.1 you can create a awt.Font from an InputStream, but you cant get back whatever physical representation the font has from the awt.Font object.

I thought of the following approach

interface fop.font.Font {
 public InputStream getFontInputStream();
 public awt.Font getAWTFont();
 // duplicate AWT methods, with certain stuff like metrics
 // replaced with FOP objects
}

class fop.font.AWTFont implements fop.font.Font {
 // delegate to AWT font
 // encapsulate awt.FontMetric in FOP font metric

 public InputStream getFontInputStream() { return null; }
}

class fop.font.Type1Font implements fop.font.Font {
 public awt.Font getAWTFont() { return null;}
 // use FOP type 1 font reader
}

class fop.font.TrueTypeFont implements fop.font.Font {
 public awt.Font getAWTFont() { return new Font(new FileInputStream...);}
 // use FOP TTF reader or delegate to the AWT font.
}

class fop.font.PDFBuiltinFont implements fop.font.Font {
 public InputStream getFontInputStream() { return null; }
 public awt.Font getAWTFont() { return null;}
 // return generated classes for metrics etc.
}

This means users can use AWT fonts for creating PDF, but they can't
embed them. This may cause the resulting PDF to fail, but so what.

We *could* try to use the TTF reader to search through the fonts
in the Windows font directory (or XFonts) in order to find the
file for an AWT font.

J.Pietschmann



Reply via email to