search

iMyth / flying-saucer

Automatically exported from code.google.com/p/flying-saucer
1 stars 0 forks source link

Font family generic font family names are not properly implemented #133

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Flying Saucer currently makes the following assumptions with generic font 
family names:

SansSerif = BaseFont.HELVETICA
Serif = BaseFont.TIMES
Monospaced = BaseFont.COURIER

This is not fully correct. If you experiment with the implementations of 
different browsers (and even Java font properties), you'll notice that they 
will have a stack of fonts to use for each generic family name. In addition, 
those stacks of fonts change depending on the locale the content is being 
rendered in.

For example, if you were to render English and Kanji characters using just 
SansSerif in a browser in America, you'll notice that the English characters 
will be rendered with a Latin SansSerif font (Arial, Helvetica, or Lucida Sans) 
and the Kanji will be rendered with a Chinese SansSerif font (SimSun). If you 
were to render the same content in a browser installed on a Japanese machine, 
the English characters will be rendered with the same Latin SansSerif font and 
the Kanji will be rendered with a Japanese SansSerif font (Ms Gothic).

In this instance, Flying Saucer will only use Helvetica and any characters not 
having glyphs in Helvetica will not be rendered.

This has implications on generating multilingual and mathematical PDF files.

An example of this can easily be seen by looking at the Java font properties 
installed with the JRE.

Original issue reported on code.google.com by loe...@gmail.com on 23 Mar 2011 at 3:36

GoogleCodeExporter commented 9 years ago 
This is a reasonable default assumption considering how PDF (and the Base 14 
fonts) work (and the requirement that FS not require any additional font files 
out of the box).

If you do make changes to ITextFontResolver to support locale dependent font 
choices, please contribute a patch so we can at least archive the technique.  
It doesn't sound like something that should go into the base product though 
(see first paragraph) so I'm closing the bug for now.

Original comment by Peter.Br...@gmail.com on 24 Mar 2011 at 12:55

GoogleCodeExporter commented 9 years ago 
I would ask you reconsider this. I could imagine this could easily be resolved 
if instead of specifying a font for a generic font family name, you could 
specify a pre-built FontSelector for a given generic font family name. In 
addition, it would be nice to allow users to overwrite each FontSelector with 
their own given if they want to add other fonts. At a minimum, SansSerif would 
only need to have a stack of Helvetica and Symbol.

Granted a lot of this implementation relies on a solution being in place for 
http://code.google.com/p/flying-saucer/issues/detail?id=130

Original comment by loe...@gmail.com on 24 Mar 2011 at 9:36