Hi Andreas, > [BTW (slightly off-topic for this particular thread): I'm > wondering whether we do not need /all/ applicable font- > families. After all, page- numbers can be formatted, so > the eventual font would have to have all the necessary > glyphs. Right now, one single Font instance is stored > in the area, and that one is determined before we can > verify whether it indeed has all the glyphs... Perhaps > a way too exotic use-case?]
I don't quite see what could happen. Formattings like bold or italics are known before, the only thing coming later are instances of [0-9]. There's no way, I think, to make the first digit bold and the second one italic and the third one in a different font. > If you want to try this out, and succeed in getting it > to work, don't forget to send us the patch. ;-) If not, > again, I'll probably have a closer look during the weekend. If I can work on it before the weekend, I'll definitely send you the result. Regards, Georg Datterl ------ Kontakt ------ Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH: www.irs-nbg.de Willmy PrintMedia GmbH: www.willmy.de Willmy Consult & Content GmbH: www.willmycc.de -----Ursprüngliche Nachricht----- Von: Andreas Delmelle [mailto:[email protected]] Gesendet: Mittwoch, 24. Juni 2009 17:47 An: [email protected] Betreff: Re: AW: AW: AW: Another alignment thing, maybe related to [Bug 47380] On 24 Jun 2009, at 17:23, Georg Datterl wrote: > Pity. But proves again: For every problem there's a simple, obvious > and wrong solution. :-) I think the real solution would be to store the referenced FontTriplet in the UnresolvedPageNumber, instead of the Font instance. FontTriplets are fully serializable (used by the FontCache), so we don't need to declare it transient. The only reason we need the font, is for UnresolvedPageNumber.resolveIDRef() (line 110), to know how much space the resolved page-number will occupy given that font. [BTW (slightly off-topic for this particular thread): I'm wondering whether we do not need /all/ applicable font-families. After all, page- numbers can be formatted, so the eventual font would have to have all the necessary glyphs. Right now, one single Font instance is stored in the area, and that one is determined before we can verify whether it indeed has all the glyphs... Perhaps a way too exotic use-case?] I cannot immediately make an estimate as to how many other classes would be affected by such a fix. If it's only that one single area type, it could also prove to be a simple and obvious solution. If you want to try this out, and succeed in getting it to work, don't forget to send us the patch. ;-) If not, again, I'll probably have a closer look during the weekend. HTH! Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
