Hi, I’m not keen on adding Yet Another configuratin option to the config file, there are more than enough already.
I believe that if a user is advanced enough to be aware that a last resort font can be configured, then they are also able to configure custom fonts so as to avoid any glyph missing warning. Moreover this last resort font is a TrueType font, which is not supported by all output formats yet. Both Type1 and TrueType (OpenType) fonts have a dedicated glyph for unsupported characters. I think this is what FOP should fall back to in case of a missing glyph. Vincent Glenn Adams wrote: > Unicode does not prescribe how to render characters for which the assigned > font(s) have no corresponding glyph(s). It does, however, make > recommendations on how an application or system should handle this case, > about which see Unicode 5.1 Section 5.3 Unknown and Missing Characters, > under the sub-heading of *Interpretable but Unrenderable Characters*. See > also the following FAQ: > > http://unicode.org/faq/unsup_char.html?PHPSESSID=a05ee80b0f30ee349b9851a929e4e4e6 > > What FOP should be doing, rather than map an unrenderable character to '#', > is to employ a so called Last Resort font, where each defined character is > associated with some glyph, e.g., one that indicates the script of the > character. In the absence of such a Last Resort font, it is customary to map > the character to a glyph depicting an empty box. > > Unicode has published such a Last Resort font see: > > http://www.unicode.org/policies/lastresortfont_eula.html > > A reasonable strategy for FOP might be to allow the user to specify (in the > FOP configuration file) a font mapping to a last resort font to be used in > such cases. The user would still have to download and install the last > resort font on their system, due to licensing reasons. > > I will post a bug to this effect, and suggesting this solution, if there is > not already one present. Some minor modifications to FOP would be required > to make use of the configuration information specifying a last resort font, > and then using that font when no mapping is present in the assigned font. > > Regards, > Glenn > > On Mon, Jul 19, 2010 at 11:50 PM, Eric Douglas <edoug...@blockhouse.com>wrote: > >> I don't understand what unicode.org is saying if it's just referring to >> what characters the codes should reference if they have to be in the >> font. Fontforge says U2610 and U2611 are not in the font. >> >> Fontforge is an ugly program. It runs within Cygwin, where it displays >> a window showing the characters in the font, but it doesn't show them >> all and doesn't have a scrollbar.. >> I would like an easy way to view the characters in the font to see if I >> have something available that looks like a square/checkbox. >> I can only assume the square I'm getting is a default in FOP 0.95 for >> all missing glyphs. >> >> -----Original Message----- >> From: J.Pietschmann [mailto:j3322...@yahoo.de] >> Sent: Saturday, July 17, 2010 11:20 AM >> To: fop-dev@xmlgraphics.apache.org >> Subject: Re: Font Glyph? >> >> On 15.07.2010 22:44, Eric Douglas wrote: >>> Then I pass a text value of "☑" in my XML. When the >>> transformer uses FOP to translate the XML into output, this prints a >> square. >> Have a look at http://www.unicode.org/charts/charindex.html >> U2611 is "BALLOT BOX WITH CHECK", i.e. not a square (U2610 should be a >> square, are you sure about the entity?) If FOP couldn't find the glyph, >> it would have printed a # instead. >> You could use one of the font editors to check whether your font >> actually has a glyph for the U2611 character (try >> http://fontforge.sourceforge.net/) >> >> >>> I tried replacing my fop.jar with one that I compiled from the Trunk, >>> and instead of printing the square it printed an error message to the >>> Java Console that the font doesn't contain the specified glyph. >> That's mildly odd, I'd guess your method for telling FOP about your font >> doesn't work as in Trunk. >> >> J.Pietschmann >> >
