You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Eric Douglas <ed...@blockhouse.com> on 2010/07/15 22:44:06 UTC

Font Glyph?

I'm running FOP 0.95 with embedded code.

I'm loading my font in using EmbedFontInfo with font file lucon.ttf
(copied from with Windows XP system font folder), using a file:///
reference to point to the ttf, passing in null for the first parameter
(metrics file), then adding the EmbedFontInfo to a java.util.ArrayList
to pass in to the PDFRenderer (setFontList) which I use on my
FOUserAgent with setRendererOverride.

Maybe this isn't the best or proper way to load in a custom embedded
font but it's working.
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.
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.
I haven't checked if the 1.0 is available for download to test with
that.
I don't remember where I came up with this character value.  Is this
supposed to print a square, which would be an error in the Trunk, or was
this an error in the 0.95 and it was actually supposed to say it
couldn't find the glyph?

RE: Font Glyph?

Posted by Eric Douglas <ed...@blockhouse.com>.
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:j3322ptm@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?

Posted by Craig Ringer <cr...@postnewspapers.com.au>.
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?

Posted by Glenn Adams <gl...@skynav.com>.
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 <vh...@gmail.com>wrote:

> 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 <edouglas@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:glenn@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 <
> vhennebert@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?

Posted by Vincent Hennebert <vh...@gmail.com>.
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 <ed...@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:glenn@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 <vh...@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?

Posted by Glenn Adams <gl...@skynav.com>.
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 <ed...@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:glenn@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 <vh...@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?

Posted by Eric Douglas <ed...@blockhouse.com>.
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:glenn@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
<vh...@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?

Posted by Glenn Adams <gl...@skynav.com>.
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 <vh...@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 <edouglas@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:j3322ptm@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?

Posted by Vincent Hennebert <vh...@gmail.com>.
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 <ed...@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:j3322ptm@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?

Posted by Glenn Adams <gl...@skynav.com>.
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 <ed...@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:j3322ptm@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?

Posted by Eric Douglas <ed...@blockhouse.com>.
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:j3322ptm@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?

Posted by "J.Pietschmann" <j3...@yahoo.de>.
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