search

fzxs8 / flying-saucer

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

CSS font-family font stack is not honored #130

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
when supplying a list of fonts in the CSS font-family descriptor, Flying Saucer 
only uses the first one it recognizes. This is counter to what is supposed to 
happen according to the CSS definition of font-family

"The font-family property should hold several font names as a "fallback" 
system. If the browser does not support the first font, it tries the next 
font." ~w3schools.com

Example:

Making the assumption that Arial and Symbol are registered fonts, and given the 
string of text "ABCΩ123" and the following CSS snipet:

body {
  font-family: Arial, Symbol, sans-serif;
}

Arial will be used to render the omega symbol. Being that Arial does not 
contain the glyph for the omega symbol, it will not be rendered in the 
generated PDF. Instead, Flying Saucer, once upon determining that the omega 
symbol is not a glyph contained in Arial, should attempt to render the 
character with Symbol. This is currently not the case.

This issue has implications for generating multilingual PDF files.

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

GoogleCodeExporter commented 9 years ago 
This is unfortunately a relatively involved bug to fix.  iText does support the 
necessary APIs to query whether a font contains a glyph for a particular 
character though so it is possible.  The tricky part is that this affects both 
layout and rendering because the metrics of a particular chunk of text would be 
dependent on the text itself and could not be statically determined from the 
CSS and available font files.  Additionally, since this is a feature most 
people don't need, performance regressions would be unacceptable (although it 
would be OK to hide this feature behind a config file switch).

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

GoogleCodeExporter commented 9 years ago 
I noticed that this would be the issue with the greatest ripple. Unfortunately 
I feel this is a critical bug and that many people would need it. It just may 
be in most cases that others have found a way around it by embedding fonts 
directly into their PDF files. But for anyone trying to display characters that 
are not in the base font, like foreign characters (Japanese) and mathematical 
characters (omega symbol) without wanting to embed physical fonts, they will 
need this or be forced to add additional unnecessary markup to their html to 
get it to work.

iText has a utility that already breaks a piece of text into chunks and each 
chunk has the appropriate font needed associated to it. Take a look at the 
FontSelector class. I am not sure if this would help in getting the correct 
information during layout and rendering.

Could you please take a look at this again as this issue is critical to our 
project completion?

Thank you.

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

GoogleCodeExporter commented 9 years ago 
Another vote for symbol fallback. This would be an excellent (and expected) 
thing to have working..

Original comment by jamiespe...@gmail.com on 27 Oct 2014 at 2:17