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:andreas.delme...@telenet.be]
Gesendet: Mittwoch, 24. Juni 2009 17:47
An: fop-users@xmlgraphics.apache.org
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: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
