On 26.11.2003 21:32:30 J.Pietschmann wrote:
> 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.
Javadoc tells me this works since 1.3 (Font.createFont method).
Anyway, it's the opposite of what Victor wanted.
> 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...);}
I think you meant return Font.createFont(Font.TRUETYPE_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.
--> Support questions
And there's still the question if we can produce font metric information
for the target formats (there's PCL and PostScript and..., too) that
result in the desired output.
> 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.
Yeah, but it will be sooooo slow. You'd need some persistent cache to
overcome that.
Seriously, I don't think working with AWT's Font will do us any good.
The differences between JDKs are too great.
We need java.awt.Font objects for the Java2D-related renderers, but
producing/getting these objects is the renderer's job, just as it's the
PDFRenderer's job to produce PDF font objects for serialization. IMO
it's better to have full control over what happens.
Jeremias Maerki
