Re: fo:inline bpd
linearea bpd=11100 space-before=1650 space-after=1650 inlinearea bpd=9250 textarea font-size=10ptsome 10pt text/textarea inlinearea bpd=11100 textarea font-size=12ptsome 12pt text/textarea /inlinearea textarea font-size=10ptmore 10pt text/textarea /inlinearea linearea All the inline areas also have a line-height trait of 12000 but that is only used when lls=line-height [4.6]. [Manuel] Hmm, the line-height property would be normal everywhere which equates to 1.2 that means the trait would be 14400 for areas generated from fo elements with a font-size of 12pt and 12000 for areas generated from fo elements with a font-size of 10pt. But as you said it doesn't matter really unless lss is line-height. Your are right, my mistake. I believe the line-height trait should be 14400 for all the inline areas. Does it make sense? Yes it does. Does it also means the bpd doesn't bubble up in the case of nested inlines? So if we expand on the example of the nested inline above: fo:blockfo:inline font-size=10ptsome 10pt textfo:inline font-size=14ptsome 14 pt text/fo:inlinemore 10pt text/fo:inline/fo:block Does the line-area generated from that have a bpd corresponding to a 12pt font or 14 pt font (spec [4.5] for lss=max-height: block-progression-direction is the minimum required to enclose both the nominal-requested-line-rectangle and the allocation-rectangles of all the inline-areas stacked within the line-area)? I believe the bpd of the line area will correspond to the 14pt font because [4.5] talks about all the inline-areas. So the bpd on inlines does not bubble up the outer inlines, but it (and/or depth altitude) do bubble up to the calculation of line-rectangles on the line-area. Also, I think that makes sense. The nominal-requested-line-rectangle corresponds to a 12pt font. But is the area generated from the nested inline an inline-area stacked within the line-area or not? Stacked inline-areas must refer to all the desendents, not just the immediate children, see [4.6.1]. regards, finn
Re: fo:inline bpd
On Wed, 14 Sep 2005 03:12 pm, Finn Bock wrote: linearea bpd=11100 space-before=1650 space-after=1650 inlinearea bpd=9250 textarea font-size=10ptsome 10pt text/textarea inlinearea bpd=11100 textarea font-size=12ptsome 12pt text/textarea /inlinearea textarea font-size=10ptmore 10pt text/textarea /inlinearea linearea All the inline areas also have a line-height trait of 12000 but that is only used when lls=line-height [4.6]. [Manuel] Hmm, the line-height property would be normal everywhere which equates to 1.2 that means the trait would be 14400 for areas generated from fo elements with a font-size of 12pt and 12000 for areas generated from fo elements with a font-size of 10pt. But as you said it doesn't matter really unless lss is line-height. Your are right, my mistake. I believe the line-height trait should be 14400 for all the inline areas. Why do you say that the line-height trait should be the same for all areas? In the line-height case the specified value (1.2) is inherited not the computed value. Therefore I was assuming that on the areas generated from fo elements with font-size=10pt the line-height trait would be 12000. Does it make sense? Yes it does. Does it also means the bpd doesn't bubble up in the case of nested inlines? So if we expand on the example of the nested inline above: fo:blockfo:inline font-size=10ptsome 10pt textfo:inline font-size=14ptsome 14 pt text/fo:inlinemore 10pt text/fo:inline/fo:block Does the line-area generated from that have a bpd corresponding to a 12pt font or 14 pt font (spec [4.5] for lss=max-height: block-progression-direction is the minimum required to enclose both the nominal-requested-line-rectangle and the allocation-rectangles of all the inline-areas stacked within the line-area)? I believe the bpd of the line area will correspond to the 14pt font because [4.5] talks about all the inline-areas. So the bpd on inlines does not bubble up the outer inlines, but it (and/or depth altitude) do bubble up to the calculation of line-rectangles on the line-area. Also, I think that makes sense. OK, happy to proceed on that basis. For what its worth I did a quick test against xep and it seems to behave as you suggested Finn. The nominal-requested-line-rectangle corresponds to a 12pt font. But is the area generated from the nested inline an inline-area stacked within the line-area or not? Stacked inline-areas must refer to all the desendents, not just the immediate children, see [4.6.1]. regards, finn BTW, thanks for your patience in this exchange Finn. Certainly clarified things for me. Manuel
DO NOT REPLY [Bug 36625] - Percentage IPD incorrect in side regions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36625. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36625 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2005-09-14 10:42 --- Thanks for the bug report Yannick. I'll take ownership of this bug. When I did the percentage changes recently I did put the non normal regions on my still to be checked list but haven't got around to it yet. I am therefore not surprised that there are still problems in that area. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36625] - Percentage IPD incorrect in side regions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36625. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36625 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|fop-|[EMAIL PROTECTED] |[EMAIL PROTECTED] | Status|ASSIGNED|NEW -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
vertical-align vs baseline alignment properties
As a consequence of the recent discussion on the correct bpd for inline areas I was looking at actually implementing it. Part of that is correct vertical positioning, i.e. baseline alignments, of those areas. Am I correct in saying that the vertical-align property which is a shorthand for a combination of baseline related properties is not currently implemented as shorthand, that is the property system doesn't do the mapping to the corresponding properties (alignment-baseline, alignment-adjust, baseline-shift and dominant-baseline)? Also those 4 properties, while set on the various fo's, don't seem to have getters so are not available to the layout system. So, the first step in moving away from vertical-align and to the four corresponding properties is to fix the property subsystem and the fo definitions. Finn, the property system already has a notion of corresponding properties, etc.. I haven't looked into it in any detail but can that be used for the mapping of vertical-align or do we need some custom mechanism in this case? Manuel
Re: svn commit: r280854 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/TextLayoutManager.java
I wrote: Correct handling of the combination of hyphenation and text-align = center, left or right. At the end, I found out that this was not the same problem as bug 36533, but another bug specifically concerning the elements created to represent hyphens. I think that Manuel has been the first person ever testing hyphenation together with non-justified text, thus awaking this sleeping bug! :-) There is still a detail that has not yet been fixed: the correct handling of characters that can be used as break points (for example a / character in the middle of a long url, that could be used as an emergency break). I'm going to fix that too, I just wanted to commit this correction as soon as possible in order to avoid run time exceptions. Regards Luca
Re: svn commit: r280872 - in /xmlgraphics/fop/trunk/test/layoutengine: disabled-testcases.txt testcases/block_padding_2.xml
Can one of the Knuth specialist please review my element list in the new test case below? Thanks. BTW, if you run this test, the output looks good, but add two or three additional lines and you'll see the problem in the output, too. On 14.09.2005 17:02:28 jeremias wrote: Author: jeremias Date: Wed Sep 14 08:02:24 2005 New Revision: 280872 URL: http://svn.apache.org/viewcvs?rev=280872view=rev Log: Ouch. The penalties are completely wrong if a higher-level block defines non-conditional padding. Added: xmlgraphics/fop/trunk/test/layoutengine/testcases/block_padding_2.xml (with props) Modified: xmlgraphics/fop/trunk/test/layoutengine/disabled-testcases.txt snip/ Jeremias Maerki
Re: svn commit: r280872 - in /xmlgraphics/fop/trunk/test/layoutengine: disabled-testcases.txt testcases/block_padding_2.xml
On Wed, Sep 14, 2005 at 05:05:37PM +0200, Jeremias Maerki wrote: Can one of the Knuth specialist please review my element list in the new test case below? Thanks. The element list seems OK to me. The first page also seems OK to me. What is strange is that the first line on the second page has vpos=190800, i.e. 6 below the end of the last line on page 1. Clearly 3 padding after and padding before are added. Is this not a problem of the area part of the code? BTW, if you run this test, the output looks good, but add two or three additional lines and you'll see the problem in the output, too. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Reg. Can not copy text content from PDF to another editors
Hi, I have generated PDF documents using FOP-0.20.5. We have registered ArialUnicodeMS fonts with FOP. After implementing this feature we are not able to copy the text content from PDF to any editors. Why we are not able to paste the original text contents. Is it possible to do that? Anyone please help me. Regards, LALITH _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/
