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
