The current way that fonts are handled is hobbled by the fact that the Graphics2D is 
the class that PDFGraphics2D and 
SVGGraphics2D inherit from. 

One problem is that java.awt.Font can only instantiate fonts that the JVM knows about. 
What is needed is a call to tell both 
PDFGraphics2D and SVGGraphics2D which fonts to map each java.awt.Font to. 

There are a few problems that need to be solved:

1) When generating to PDF one needs a way to tell it to map TrueType fonts to 
metrically equivalent Type 1 fonts.
   ie when it sees a particlar java.awt.Font instance it should use Type 1 font XYZ in 
the output. 
   Rather than the F1, F2,. etc sort of nomenclature that is used in 
FontSetup/FontInfo instead the mapping should be between 
particular java.awt.Font instances and some textually described font (eg "Helvetica" 
or something similar). 
    This has to be callable to be set up in advance before some graphics library that 
only knows Graphics2D calls would be 

2) When generating to a format that supports font lists (eg in CSS where if font a 
isn't available then try fonts b and then c) one 
needs a way to specify to generate a list of fonts in the output format. 
   The problem is that the Graphics2D setFont only allows a single font to be 
currently specified. Well, I want to be able to call 
some other method and tell SVGGraphics2D (or whatever similar class that generates to 
other formats) in advance that when it 
sees a set to a particular java.awt.Font then it should look-up and find a list of 
fonts that will serve in its place in the target 
document that is being generated. 
   The interface here would be the same as for what is described in the first problem 
above but there would be a list of fonts 
rather than a single font in the text that the java.awt.Font object got mapped to. 

3) Some of the font family names that Java uses are unwise for general web page and 
CSS use. 
   For example, on my machine running NT4 SP6a if I instantiate a font of type 
"sansserif" and style Font.ITALIC then the font-
family name that Java assigns to it is "sansserif.italic". If one tries to instantiate 
a font of type "sansserif.italic" and give it style 
Font.ITALIC Java will literally default it to Arial because Java says that the font 
family "sansserif.italic" does not have an italic 
style. The "sansserif.italic" font family has its italic style assigned to PLAIN! 
   As a result Batik will generate a style in a font-face tag that looks like:
         style="font-family:sansserif.italic; font-style:italic; font-weight:normal;"
   Its dumb to put styles in as part of the font family name. Downstream at some point 
some display device is going to say that 
it doesn't even have a font family of "sansserif.italic" and will default to some 
other font. Batik or FOP ought to provide a way for 
programmers to prevent this sort of nonsense from mucking things up at some later 
stage of processing. 
   Font family names that get put into generated output files ought not to be made 
into some overly specific name just because 
Sun or Microsoft (not sure who to blame for this) defined a font family in this 
fashion. That information belongs with font-style. Its 
far more easy to start with "sansserif" and the italic as separate properties and look 
for a font family that puts italic in as part of 
its name than it is to go in the opposite direction. Doing it always in one direction 
for look-ups makes it easier and more 
   Imagine one popped down a combo box on some interface, listed all font families, 
the user chose sansserif.italic, and then the 
user chose the italic property, and then the result was that the display software 
found that that font family used a totally different 

My point in mentioning SVGGraphics2D in this message is that PDFGraphics2D and 
SVGGraphics2D should receive the same 
enhancement in terms of what the added methods should look like. I even think that 
they should inherit from a base class that 
gets these methods (and perhaps supporting other classes to hold the data that gets 
passed to them) defined for them. 

Bottom line: We ought to define some common methods in PDFGraphics2D and SVGGraphics2D 
that will allow a programmer 
to use the same calls in Batik and FOP to handle fonts more intelligently. 

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to