It is true that currently Batik does not have a way for someone to
provide arbitrary fonts to Batik.  However we do support CSS @font-face
to reference arbitrary TrueType fonts via URL.  See the following SVG
file for examples of how to accomplish this:

http://svn.apache.org/viewvc/xmlgraphics/batik/trunk/samples/tests/spec/fonts/fontFace.svg?view=markup

A  lso if you successfuly added the font to the AWT font list then Batik
should see and use it.  The Code Batik uses to know about 'system fonts'
(where system here means the JVM) is:

        GraphicsEnvironment env;
        env = GraphicsEnvironment.getLocalGraphicsEnvironment();
        String[] fontNames = env.getAvailableFontFamilyNames();

   If the fontNames array includes your font then Batik _will_
use it.  It's possible the name of the font Java see's isn't 
what you think it is which could cause problems as well.

Created attachment 23660 [details]
Sample test case that should work.

I am trying to embed a non-system font to a SVG file using the SVGGraphics2D class. 

Batik actually embeds a font, but a standard Java font one I think. The attachment gives a sample that should work but does not.

I found at least one issue with font embedding. 

The way Batik is storing the font usage information is storing the wrong font name, so it generates the glyphs using a default Dialog font when the desired font is not available system-wide.

In svggen.SVGFont.java:

############
private static Font createCommonSizeFont(Font font) {
   Map attributes = new HashMap(font.getAttributes());
   attributes.put(TextAttribute.SIZE, new Float(COMMON_FONT_SIZE));
   // Remove Transform from font otherwise it will be applied twice.
   attributes.remove(TextAttribute.TRANSFORM);
   return new Font(attributes);
}
############

The last line that is calling the Font constructor actually fails silently if the "font" object is not a system font. This is called when creating the map of which characters are used by which font, so the String used to store the font family and weight correspond to the Dialog font used as a fallback.

A simple way to solve this problem would be to use the deriveFont method instead:

############
private static Font createCommonSizeFont(Font font) {
   Map attributes = new HashMap(font.getAttributes());
   attributes.put(TextAttribute.SIZE, new Float(COMMON_FONT_SIZE));
   // Remove Transform from font otherwise it will be applied twice.
   attributes.remove(TextAttribute.TRANSFORM);
   return font.deriveFont(attributes);
}
############

(or maybe just a 
############
private static Font createCommonSizeFont(Font font) {
   return font.deriveFont(new Float(COMMON_FONT_SIZE));
}
############
but I am not sure about the transform you are removing)

Since any generated SVG file contains the non-system font name and family, but uses the default shapes (see the previous attachment), I guess the fonts are stored in a different place, but the toSVG method is calling anyway createCommonSizeFont before generating the glyphs.

Why I am not commiting a patch is because I have not found yet where the xmlwriter is calling the toSVG method of SVGFont that is actually writing the glyph shapes. I am wondering when the method is actually called (non system fonts might be destroyed between the drawString call and the stream call).

I hope this helps.

Hi Alexis.

(In reply to comment #4)
> In svggen.SVGFont.java:
> 
> ############
> private static Font createCommonSizeFont(Font font) {
>    Map attributes = new HashMap(font.getAttributes());
>    attributes.put(TextAttribute.SIZE, new Float(COMMON_FONT_SIZE));
>    // Remove Transform from font otherwise it will be applied twice.
>    attributes.remove(TextAttribute.TRANSFORM);
>    return new Font(attributes);
> }
> ############
> 
> The last line that is calling the Font constructor actually fails silently if
> the "font" object is not a system font. This is called when creating the map of
> which characters are used by which font, so the String used to store the font
> family and weight correspond to the Dialog font used as a fallback.

Makes sense.

> A simple way to solve this problem would be to use the deriveFont method
> instead:
> 
> ############
> private static Font createCommonSizeFont(Font font) {
>    Map attributes = new HashMap(font.getAttributes());
>    attributes.put(TextAttribute.SIZE, new Float(COMMON_FONT_SIZE));
>    // Remove Transform from font otherwise it will be applied twice.
>    attributes.remove(TextAttribute.TRANSFORM);
>    return font.deriveFont(attributes);
> }
> ############
> 
> (or maybe just a 
> ############
> private static Font createCommonSizeFont(Font font) {
>    return font.deriveFont(new Float(COMMON_FONT_SIZE));
> }
> ############
> but I am not sure about the transform you are removing)

When using deriveFont(), all of the existing attributes are kept from the original Font, and only those present in the passed-in Map are overwritten.  So to remove the TRANSFORM attribute, you need to provide a map with a [TRANSFORM, null] entry in it:

  private static Font createCommonSizeFont(Font font) {
      Map attributes = new HashMap();
      attributes.put(TextAttribute.SIZE, new Float(COMMON_FONT_SIZE));
      attributes.put(TextAttribute.TRANSFORM, null);
      return font.deriveFont(attributes);
  }

> Since any generated SVG file contains the non-system font name and family, but
> uses the default shapes (see the previous attachment), I guess the fonts are
> stored in a different place, but the toSVG method is calling anyway
> createCommonSizeFont before generating the glyphs.
> 
> Why I am not commiting a patch is because I have not found yet where the
> xmlwriter is calling the toSVG method of SVGFont that is actually writing the
> glyph shapes. I am wondering when the method is actually called (non system
> fonts might be destroyed between the drawString call and the stream call).

The glyph shapes are extracted with the

  gv.getGlyphOutline(0)

calls that are in SVGFont.toSVG().  Since they are called on a GlyphVector that was obtained from the common size font, that'd be why the wrong shapes were written out in the SVG.


I've just committed the above change as r774981.  It makes your test case work, Alexis.


M.H., are you able to test if this allows FOP to work with other fonts?

Created attachment 28192 [details]
patch with proposal of fix for adding external fonts

Attached a patch with a proposal for allowing external fonts to be used by batik.
It adds 2 extra methods to the useragent. UserAgentAdapter implements the default behavior.

added some extra changes to squiggle, allowing you to test this more easily, this is for me not necessary but nice to have.
* added fonts preferences page
** allow for configuring the default css font. (not yet happy about the layouting)
** allow for configuring extra font directories
*** these extra font directories are first checked before fallbacking to fonts known to the AWT graphics environment.

Created attachment 28193 [details]
icon for font preference page

Created attachment 28194 [details]
icon for font preference page