You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xmlgraphics.apache.org by sp...@leverkruid.eu on 2008/12/02 16:49:42 UTC
Re: svn commit: r722108 -
/xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Quoting Jeremias Maerki <de...@jeremias-maerki.ch>:
> Hi Vincent,
>
> these alternatives are only taken as a last resort before mentioning
> that a glyph cannot be found. Unicode does list "minus" (Unicode: 2212,
> MINUS-SIGN) to be related to "hyphen" (Unicode: 002D, HYPHEN-MINUS).
> Otherwise, I wouldn't have made the change. The change is also not about
> replacing minus for a hyphen, but for the other way around. I can of
> course add a warning if an alternative glyph is used. But I guess some
> people would find the warning welcome while others might find it a
> nuisance. Can we get some additional opinions to reach an informed
> decision, please?
Are such substitutions debuggable? If you set the log level high
enough, do you then get messages for each substitution? I guess that
sometimes that may come in handy for users who wonder why they do not
get the glyphs they expect.
Simon
> Jeremias Maerki
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: svn commit: r722108 -
/xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Posted by sp...@leverkruid.eu.
Quoting Jeremias Maerki <de...@jeremias-maerki.ch>:
> No, but that could easily be included in AbstractCodePointMapping where
> the substitution is controlled from. That would be easier to implement
> than an event in the event processing framework as
> AbstractCodePointMapping doesn't have access to the user agent. If we
> decide to make it an event (which is probably a bit cleaner), I probably
> have to change AbstractCodePointMapping a bit to make it a two-stage
> process (we can only return one result, a char, which is not suitable
> for indicating a substitution to the outside). That's the first decision.
> The second is the log level (for both approaches): DEBUG, INFO or WARN.
> I'd vote for DEBUG in this case.
I agree that events are best and that DEBUG is the right level. Simon
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: svn commit: r722108 - /xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Jeremias,
Jeremias Maerki wrote:
> No, but that could easily be included in AbstractCodePointMapping where
> the substitution is controlled from. That would be easier to implement
> than an event in the event processing framework as
> AbstractCodePointMapping doesn't have access to the user agent. If we
> decide to make it an event (which is probably a bit cleaner), I probably
> have to change AbstractCodePointMapping a bit to make it a two-stage
> process (we can only return one result, a char, which is not suitable
> for indicating a substitution to the outside). That's the first decision.
> The second is the log level (for both approaches): DEBUG, INFO or WARN.
> I'd vote for DEBUG in this case.
This may be of interest to the user, so I think an event is necessary.
DEBUG is fine I guess.
(That said, if that were me I wouldn’t do any glyph substitution at all.
If the user spent the time to specify ‘exotic’ glyphs, they’re likely to
have set up their system so that the suitable font is available, aren’t
they?)
> On 02.12.2008 16:49:42 spepping wrote:
>> Quoting Jeremias Maerki <de...@jeremias-maerki.ch>:
>>
>>> Hi Vincent,
>>>
>>> these alternatives are only taken as a last resort before mentioning
>>> that a glyph cannot be found. Unicode does list "minus" (Unicode: 2212,
>>> MINUS-SIGN) to be related to "hyphen" (Unicode: 002D, HYPHEN-MINUS).
>>> Otherwise, I wouldn't have made the change. The change is also not about
>>> replacing minus for a hyphen, but for the other way around. I can of
>>> course add a warning if an alternative glyph is used. But I guess some
>>> people would find the warning welcome while others might find it a
>>> nuisance. Can we get some additional opinions to reach an informed
>>> decision, please?
>> Are such substitutions debuggable? If you set the log level high
>> enough, do you then get messages for each substitution? I guess that
>> sometimes that may come in handy for users who wonder why they do not
>> get the glyphs they expect.
>>
>> Simon
>>
>>> Jeremias Maerki
>
>
> Jeremias Maerki
Vincent
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: svn commit: r722108 - /xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
No, but that could easily be included in AbstractCodePointMapping where
the substitution is controlled from. That would be easier to implement
than an event in the event processing framework as
AbstractCodePointMapping doesn't have access to the user agent. If we
decide to make it an event (which is probably a bit cleaner), I probably
have to change AbstractCodePointMapping a bit to make it a two-stage
process (we can only return one result, a char, which is not suitable
for indicating a substitution to the outside). That's the first decision.
The second is the log level (for both approaches): DEBUG, INFO or WARN.
I'd vote for DEBUG in this case.
On 02.12.2008 16:49:42 spepping wrote:
> Quoting Jeremias Maerki <de...@jeremias-maerki.ch>:
>
> > Hi Vincent,
> >
> > these alternatives are only taken as a last resort before mentioning
> > that a glyph cannot be found. Unicode does list "minus" (Unicode: 2212,
> > MINUS-SIGN) to be related to "hyphen" (Unicode: 002D, HYPHEN-MINUS).
> > Otherwise, I wouldn't have made the change. The change is also not about
> > replacing minus for a hyphen, but for the other way around. I can of
> > course add a warning if an alternative glyph is used. But I guess some
> > people would find the warning welcome while others might find it a
> > nuisance. Can we get some additional opinions to reach an informed
> > decision, please?
>
> Are such substitutions debuggable? If you set the log level high
> enough, do you then get messages for each substitution? I guess that
> sometimes that may come in handy for users who wonder why they do not
> get the glyphs they expect.
>
> Simon
>
> > Jeremias Maerki
>
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org