I can only repeat the following: either the user is advanced enough to know how to configure custom fonts that contain all the glyphs they need, and then a configuration option for a last-resort font will be of no use to them; Or they are not confident enough yet to create their own configuration file (or for some reason don’t want to use one), and then the configuration of a last-resort font will be inaccessible either.
In both cases I believe that the possibility of configuring a last-resort font will not help. Improving the user friendliness of FOP’s behaviour in problematic situations is always welcome, but only if it remains transparent to the user. At the moment a warning is issued when glyphs are missing, listing the affected code points. Along with using the .notdef glyph, I think that’s user-friendly enough. Vincent Glenn Adams wrote: > I agree that one should not simply add new configuration specifications > willy-nilly. As I've said previously, the ideal situation would be to > include a last resort font as a Base14 font as part of the FOP built-in font > set, and I will investigate this possibility. However, in the absence of a > built-in last-resort font, there seem to be four options: > > 1. add information to the FOP config file, which could be as simple as > adding an attribute as follows <font lastResort="true"/>; > 2. add a command line option (even less desirable in my opinion); > 3. require user to specify a last resort font as last element of > font-family attribute; however, that this will not actually work in the > current implementation, since FontSelector.selectFontForCharactersInText > always selects the font that has the most mappings in the context of a > "word"; > - for example, if 'A' is an Arabic character and 'L' is a Latin > character, then one would expect: > - <block font-family="Arabic,LastResort">ALA</inline> > - to produce three glyphs [glyph from Arabic font] [glyph from > LastResort font] [glyph from Arabic font] > - however, this will not happen because selectFontForCharactersInText > finds that two characters in the "word" have a mapping in the Arabic > font > and one character has a mapping in the LastResort font, so it chooses > the > Arabic font to process the entire word > - which results in the following glyphs: [glyph from Arabic font] > [default 'no-mapping' glyph from Arabic font] [glyph from Arabic font] > 4. require user to create their own "aggregate" fonts or modify their > fonts to including last resort glyphs for all unsupported mappings. > > The last solution above is so onerous that effectively makes it a > non-solution, so we can drop that from consideration, but note that this > "non-solution" is the only one that would work now. All of the other three > require some modifications to FOP, even the third solution which requires > the author to insert LastResort font into font family specifications. > > Regards, > Glenn > > On Wed, Jul 21, 2010 at 7:46 PM, Eric Douglas <edoug...@blockhouse.com>wrote: > >> I like your idea of the 'last resort' font, though I didn't like the >> configuration file to begin with. >> You could add an option to the configuration file also if you like the >> configuration file, but I think when the program allows integration using >> embedded code, there should be an option for all custom font setup in the >> API. >> >> ------------------------------ >> *From:* Glenn Adams [mailto:gl...@skynav.com] >> *Sent:* Tuesday, July 20, 2010 8:59 PM >> >> *To:* fop-dev@xmlgraphics.apache.org >> *Subject:* Re: Font Glyph? >> >> 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? >> >> >
