On 12.11.2007 11:13:52 Vincent Hennebert wrote: > Hi, > > > Author: jeremias > > Date: Mon Nov 12 01:40:16 2007 > > New Revision: 594067 > > > > URL: http://svn.apache.org/viewvc?rev=594067&view=rev > > Log: > > Avoid null values in generated Font classes so the encoding can be > > inspected. > > Don't warn about missing hyphenation characters for fonts such as Symbol > > and ZapfDingbats which don't have the default hyphenation character. > > Is this really necessary?
I think, yes. > If hyphenation must occur within a block with > the Symbol or ZapfDingbats fonts, doesn’t that mean that something is > wrong somewhere, and may lead to an output unexpected by the user? Not necessarily. Maybe someone likes to decorate his documents with lots of characters from one of two fonts. :-) > Moreover I can’t see how hyphenation can be performed with ZapfDingbats > (and even for Symbol, although that might be discussed), simply due to > a lack of hyphenation patterns. Sure. That's why I actually chose this path. I didn't want to make LineLM more complicated by handling the differences there. Ultimately, the hyphenation character will probably never be used when one of those two fonts is active. > The encoding-agnostic version from the revision just before actually > looked fine to me. There was one problem: You get lots of meaningless warnings about the hyphenation char being substituted. If I just switch of the warning completely, I'm back where I started. Having a "cannot map character" when using a Symbol font loaded from a Type 1 font which is not very helpful. The way it is now I get properly warned with a meaningful message that the hyphenation character I have chosen is not available for the current font. And I don't have to manually redefine the hyphenation character in FO each time I use Symbol or ZapfDingbats. > WDYT? > Vincent Jeremias Maerki
