|
»
»
»
Another alignment thing, maybe related to [Bug 47380]
|
View:
New views
14 Messages
—
Rating Filter:
Alert me
|
 |
Another alignment thing, maybe related to [Bug 47380]
by Georg Datterl
::
Rate this Message:
Hi Andreas,
since you already had a look at the bug, maybe this is related: <?xml version="1.0" encoding="UTF-8"?> <!-- edited with XMLSpy v2006 sp1 U (http://www.altova.com) by Joerg Geyer (Geneon media solutions gmbh) --> <fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format" xmlns:fox="http://xmlgraphics.apache.org/fop/extensions"> <fo:layout-master-set> <fo:simple-page-master page-height="10cm" page-width="10cm" master-name="main"> <fo:region-body/> </fo:simple-page-master> </fo:layout-master-set> <fo:page-sequence master-reference="main"> <fo:flow flow-name="xsl-region-body"> <fo:block text-align="right" background-color="rgb(255, 0, 0)" id="1"> <fo:inline/> <fo:inline text-align="right" background-color="rgb(255, 255, 0)"> <fo:page-number-citation ref-id="1" background-color="orange" text-align="right"/> </fo:inline> </fo:block> <fo:block background-color="rgb(0, 250, 0)" text-align="right"> <fo:inline text-align="right" background-color="rgb(255, 255, 0)"> <fo:page-number-citation ref-id="1" background-color="orange" text-align="right"/> </fo:inline> </fo:block> </fo:flow> </fo:page-sequence> </fo:root> The flow contains two nearly identical blocks, only the first block contains an additional empty inline. In the result, I'd not expect the inline to result in visual difference. But: The second block is aligned right, the first block is not quite. Filling the empty inline, even with only a non-breaking space, solves the problem. 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 --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscribe@... For additional commands, e-mail: fop-users-help@... |
|
|
Re: Another alignment thing, maybe related to [Bug 47380]
by Andreas Delmelle-2
::
Rate this Message:
On 18 Jun 2009, at 12:00, Georg Datterl wrote:
Hi Georg > since you already had a look at the bug, maybe this is related: > > <snip /> > The flow contains two nearly identical blocks, only the first block > contains an additional empty inline. In the result, I'd not expect > the inline to result in visual difference. But: The second block is > aligned right, the first block is not quite. Filling the empty > inline, even with only a non-breaking space, solves the problem. Which version/revision did you try exactly? I just tried with current FOP Trunk, and the output does not show any difference between the two blocks (apart from the background-color, obviously...) Could still be that I have made some local changes that fix the issue, but I'd rather see this confirmed before digging deeper... Thanks! Regards Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscribe@... For additional commands, e-mail: fop-users-help@... |
|
|
AW: Another alignment thing, maybe related to [Bug 47380]
by Georg Datterl
::
Rate this Message:
Hi Andreas,
Latest version. Just checked, no updates in svn since yesterday. 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.delmelle@...] Gesendet: Donnerstag, 18. Juni 2009 12:19 An: fop-users@... Betreff: Re: Another alignment thing, maybe related to [Bug 47380] On 18 Jun 2009, at 12:00, Georg Datterl wrote: Hi Georg > since you already had a look at the bug, maybe this is related: > > <snip /> > The flow contains two nearly identical blocks, only the first block > contains an additional empty inline. In the result, I'd not expect the > inline to result in visual difference. But: The second block is > aligned right, the first block is not quite. Filling the empty inline, > even with only a non-breaking space, solves the problem. Which version/revision did you try exactly? I just tried with current FOP Trunk, and the output does not show any difference between the two blocks (apart from the background-color, obviously...) Could still be that I have made some local changes that fix the issue, but I'd rather see this confirmed before digging deeper... Thanks! Regards Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscribe@... For additional commands, e-mail: fop-users-help@... --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscribe@... For additional commands, e-mail: fop-users-help@... |
|
|
Re: AW: Another alignment thing, maybe related to [Bug 47380]
by Andreas Delmelle-2
::
Rate this Message:
On 18 Jun 2009, at 12:26, Georg Datterl wrote:
Hi Georg > Latest version. Just checked, no updates in svn since yesterday. What I feared... ;-) That means I have /some/ local change(s) that would solve the issue. Only I have no idea at the moment /where/ precisely. I'm almost done with a basic implementation for keep-*.within-column. As soon as the commit has been made, I'll run the test against Trunk again, and see if it persists. If not, I'll definitely add your sample to the test- suite. If yes, then at least I have a lot less classes to check. More later. Thanks! Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscribe@... For additional commands, e-mail: fop-users-help@... |
|
|
|
|
|
Re: AW: Another alignment thing, maybe related to [Bug 47380]
by Andreas Delmelle-2
::
Rate this Message:
On 24 Jun 2009, at 15:34, Georg Datterl wrote:
Hi Georg > <snip /> > Maybe that's helpfull. Definitely! I just looked at the code for org.apache.fop.area.inline.UnresolvedPageNumber, and the issue is that those areas are serializable, but the Font instance member is explicitly declared as 'transient', which means it will never be serialized/deserialized. > What I find interesting is, the error appears somewhere after > generating all the pages, since the table of contents is far earlier > than Position 25986. I guess, it appears when the page-number- > citation is revisited with the actual page numbers. Indeed. > Are there any requirements for using setConserveMemoryPolicy? I only > added the above line, because I have long page sequences I can not > shorten. > The setConserveMemoryPolicy() option was introduced into Trunk fairly recently. Currently, its only effect is precisely to serialize pages containing unresolved forward references to disk, to avoid having to keep them in memory until they can be resolved. If the document runs without enabling that option, then there's your workaround for the moment. If your TOC is in a separate page-sequence (with its own numbering), you could also consider moving it to the end of the FO file. Using the new IF or area tree XML, it should prove rather easy to relocate the corresponding pages to the beginning of the document. Such a strategy would at least avoid forward references (may also lead to a much better-looking layout, since all the page-numbers would be known) Thanks for the extra info. I'll look deeper into it as soon as I see the opportunity. Regards Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscribe@... For additional commands, e-mail: fop-users-help@... |
|
|
AW: AW: Another alignment thing, maybe related to [Bug 47380]
by Georg Datterl
::
Rate this Message:
Hi Andreas,
Thanks for the help. Since I am rebuilding fop.jar anyway, wouldn't it work if I just declare the font member not-transient? 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.delmelle@...] Gesendet: Mittwoch, 24. Juni 2009 16:38 An: fop-users@... Betreff: Re: AW: Another alignment thing, maybe related to [Bug 47380] On 24 Jun 2009, at 15:34, Georg Datterl wrote: Hi Georg > <snip /> > Maybe that's helpfull. Definitely! I just looked at the code for org.apache.fop.area.inline.UnresolvedPageNumber, and the issue is that those areas are serializable, but the Font instance member is explicitly declared as 'transient', which means it will never be serialized/deserialized. > What I find interesting is, the error appears somewhere after > generating all the pages, since the table of contents is far earlier > than Position 25986. I guess, it appears when the page-number- > citation is revisited with the actual page numbers. Indeed. > Are there any requirements for using setConserveMemoryPolicy? I only > added the above line, because I have long page sequences I can not > shorten. > The setConserveMemoryPolicy() option was introduced into Trunk fairly recently. Currently, its only effect is precisely to serialize pages containing unresolved forward references to disk, to avoid having to keep them in memory until they can be resolved. If the document runs without enabling that option, then there's your workaround for the moment. If your TOC is in a separate page-sequence (with its own numbering), you could also consider moving it to the end of the FO file. Using the new IF or area tree XML, it should prove rather easy to relocate the corresponding pages to the beginning of the document. Such a strategy would at least avoid forward references (may also lead to a much better-looking layout, since all the page-numbers would be known) Thanks for the extra info. I'll look deeper into it as soon as I see the opportunity. Regards Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscribe@... For additional commands, e-mail: fop-users-help@... --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscribe@... For additional commands, e-mail: fop-users-help@... |
|
|
Re: AW: AW: Another alignment thing, maybe related to [Bug 47380]
by Andreas Delmelle-2
::
Rate this Message:
On 24 Jun 2009, at 16:43, Georg Datterl wrote:
Hi Georg > Thanks for the help. Since I am rebuilding fop.jar anyway, wouldn't > it work if I just declare the font member not-transient? Unfortunately not. The Java runtime will try to serialize the UnresolvedPageNumber, and throw a NonSerializableException because Font does not implement the java.io.Serializable interface. It will take a bit more work to correct this issue, I'm afraid... Regards Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscribe@... For additional commands, e-mail: fop-users-help@... |
|
|
AW: AW: AW: Another alignment thing, maybe related to [Bug 47380]
by Georg Datterl
::
Rate this Message:
Hi Andreas,
Pity. But proves again: For every problem there's a simple, obvious and wrong solution. Mit freundlichen Grüßen 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.delmelle@...] Gesendet: Mittwoch, 24. Juni 2009 17:16 An: fop-users@... Betreff: Re: AW: AW: Another alignment thing, maybe related to [Bug 47380] On 24 Jun 2009, at 16:43, Georg Datterl wrote: Hi Georg > Thanks for the help. Since I am rebuilding fop.jar anyway, wouldn't it > work if I just declare the font member not-transient? Unfortunately not. The Java runtime will try to serialize the UnresolvedPageNumber, and throw a NonSerializableException because Font does not implement the java.io.Serializable interface. It will take a bit more work to correct this issue, I'm afraid... Regards Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscribe@... For additional commands, e-mail: fop-users-help@... --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscribe@... For additional commands, e-mail: fop-users-help@... |
|
|
Re: AW: AW: AW: Another alignment thing, maybe related to [Bug 47380]
by Andreas Delmelle-2
::
Rate this Message:
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-unsubscribe@... For additional commands, e-mail: fop-users-help@... |
|
|
AW: AW: AW: AW: Another alignment thing, maybe related to [Bug 47380]
by Georg Datterl
::
Rate this Message:
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.delmelle@...] Gesendet: Mittwoch, 24. Juni 2009 17:47 An: fop-users@... 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-unsubscribe@... For additional commands, e-mail: fop-users-help@... --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscribe@... For additional commands, e-mail: fop-users-help@... |
|
|
Re: AW: AW: AW: AW: Another alignment thing, maybe related to [Bug 47380]
by Andreas Delmelle-2
::
Rate this Message:
On 24 Jun 2009, at 18:15, Georg Datterl wrote:
[Me: ] >> [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. Actually, I was thinking in the direction of languages that don't use the same numerals we do... and strictly speaking --although I think FOP does not implement it completely-- a user/author can specify whatever format they require. See the conversion properties mentioned in the note: http://www.w3.org/TR/xsl/#fo_page-number >> 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. Thanks in advance! Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscribe@... For additional commands, e-mail: fop-users-help@... |
|
|
R: AW: AW: AW: Another alignment thing, maybe related to [Bug 47380]
by Laera Dario
::
Rate this Message:
Hi Andreas,
> -----Messaggio originale----- > Da: Andreas Delmelle [mailto:andreas.delmelle@...] > Inviato: mercoledì 24 giugno 2009 17.47 > A: fop-users@... > Oggetto: Re: AW: AW: AW: Another alignment thing, maybe related to [Bug > 47380] > > 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. I feel a bit responsible of this bug :P I hope to have time to help you solving this problem. Dario -- CONFIDENTIALITY NOTICE: This e-mail message from the IMA Group (including all attachments) is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Please note that any opinions expressed in this e-mail are those of the author personally and not the IMA Group, who do not accept responsibility for the contents of the message. Any unauthorised review, use, disclosure, copying or distribution is strictly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and its attachments. --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscribe@... For additional commands, e-mail: fop-users-help@... |
|
|
Re: R: AW: AW: AW: Another alignment thing, maybe related to [Bug 47380]
by Andreas Delmelle-2
::
Rate this Message:
On 25 Jun 2009, at 09:45, Laera Dario wrote:
Hi Dario >> -----Messaggio originale----- >> Da: Andreas Delmelle [mailto:andreas.delmelle@...] >> >> 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. > > I feel a bit responsible of this bug :P I hope to have time to help > you solving this problem. No problem. I'm as responsible as you are. Should have checked this more thoroughly before committing... Good thing that there are so many trunk-users, else this issue would have popped up after a release. Thanks! Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscribe@... For additional commands, e-mail: fop-users-help@... |
| Free embeddable forum powered by Nabble | Forum Help |
