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 <[EMAIL PROTECTED]>: > > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
