Re: Font Glyph?
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,LastResortALA/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.comwrote: 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.comwrote: 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?
Re: Font Glyph?
Let's see if I have any luck obtaining the last resort font for direct inclusion in FOP. If I don't, then we can revisit this. Note that it is a very different problem to create custom fonts than it is to create or slightly modify an FOP configuration file, the former requiring much more know-how, tools, and experience than the latter. You seem to be equating the complexity of these two tasks in your explanation below, but perhaps I misunderstand you. G. On Tue, Jul 27, 2010 at 1:59 AM, Vincent Hennebert vhenneb...@gmail.comwrote: 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,LastResortALA/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.comwrote: 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?
Re: Font Glyph?
On 27/07/10 08:03, Glenn Adams wrote: Let's see if I have any luck obtaining the last resort font for direct inclusion in FOP. The URW free fonts may have a suitable license. They're distributed with GhostScript among other things. As they cover the base set of PostScript fonts, they could be ideal. The BitStream Vera family might also be useful, though they don't have the same metrics and appearance as common base fonts. -- Craig Ringer
RE: Font Glyph?
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?
Re: Font Glyph?
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,LastResortALA/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.comwrote: 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.comwrote: 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?
Re: Font Glyph?
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.comwrote: 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 #x2611; 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
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.comwrote: 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: 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 #x2611; 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
RE: Font Glyph?
Thanks, I'll look into that. Yes, FOP does print a # with the Trunk, at least as it was last I compiled it. FOP prints a square with the 2611, which could be some sort of default invalid? Windows apps (Notepad, Wordpad?) print squares whenever they load a file with an unrecgnized character. I'll have to see what that unicode is all about. If it's supposed to load those chars listed on that unicode.org website, and they're supposed to be in the font file, I may need to load in another font file to get those. I'm still working on installing that font editor to see if it says the font contains those 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 #x2611; 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
RE: Font Glyph?
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 #x2611; 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
Re: Font Glyph?
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.comwrote: 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 #x2611; 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
Re: Font Glyph?
On 15.07.2010 22:44, Eric Douglas wrote: Then I pass a text value of #x2611; 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
