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.


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?

Reply via email to