Comment inline. Note that I have assigned the new bug to myself, so I will undertake the work to satisfy this.
On Wed, Jul 21, 2010 at 1:25 AM, Vincent Hennebert <vhenneb...@gmail.com>wrote: > Hi, > > I’m not keen on adding Yet Another configuratin option to the config > file, there are more than enough already. > What's the purpose in having a configuration file if it isn't used for configuration information? > 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. > That's possible as a temporary work around, but it is not really sufficient in the long term to satisfy documented Unicode behavior. > Moreover this last resort font is a TrueType font, which is not > supported by all output formats yet. > It can be converted. Ideally, FOP would ship with a reasonable built-in last resort font. I will discuss with the Unicode Consortium whether this might be possible. I am acquainted with the original designer of that font, Michael Everson, so perhaps I can obtain a contributed copy that could be distributed. > 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. > Yes, that is well when there is no last resort font, but it is not really adequate. > 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: firstname.lastname@example.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 > >> > > >