DO NOT REPLY [Bug 51639] Height of element is not correctly computed if the text contains white space only
https://issues.apache.org/bugzilla/show_bug.cgi?id=51639 --- Comment #4 from Glenn Adams 2011-10-06 00:35:39 UTC --- (In reply to comment #2) > Hi Vincent, > > Thank you very much for explanation. I offer a solution of this problem: > > Height of each line is computed in > LineLayoutManager.makeLineBreakPosition(...) > by choosing the largest value from all > KnuthInlineBox.alignmentContent.lineHeight values belonging to current line. > If > we add attribute alignmentContent to class KnuthGlue we'll have the > possibility > to assign glue elements line height and then possibility to choose the largest > value of line height from both all KnuthInlineBox.alignmentContent.lineHeight > and all KnuthGlue.alignmentContent.lineHeight values belonging to current > line. > > Can you proove that it is the idea FOP needs? If it is I'll start > implementation of this. > > Kind Regards, > Alexey i would not agree with this approach; the correct approach is to use one of the following Unicode space characters: U+2001 EM QUAD U+2003 EM SPACE the EM QUAD is 1 'em' high and 1'em' wide; while the EM SPACE is 1 'em' wide these would generate Knuth boxes (not glue) of the desired width and height, and scale to the font size so as to affect line height; if there is any modification to FOP to resolve this issue, then it should be to have FOP synthesize at least these (and perhaps a few other) 'spacing' space characters in case the selected font does not contain a mapping for them; since these 'spacing' space characters generate inline boxes, they are treated just like any other character; as such they are *not* treated as whitespace for the purpose of collapsing, glue behavior, etc regards, glenn -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51639] Height of element is not correctly computed if the text contains white space only
https://issues.apache.org/bugzilla/show_bug.cgi?id=51639 --- Comment #3 from Vincent Hennebert 2011-10-05 17:26:10 UTC --- (In reply to comment #2) Hi Alexey, I'm not too familiar with inline-level layout but, yes, its does indeed seem like what we want is to get the height of KnuthGlue instances in addition to KnuthInlineBox. I suppose AlignmentContext instances would be passed the same way as for KnuthInlineBox. There may be undesirable side effects I can't think of right now. Obviously this would have to be made only for KnuthGlue instances that are actually derived from white space characters. HTH, Vincent -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51962] New: [PATCH] last simple-page-master not chosen when force-page-count=odd
https://issues.apache.org/bugzilla/show_bug.cgi?id=51962 Bug #: 51962 Summary: [PATCH] last simple-page-master not chosen when force-page-count=odd Product: Fop Version: 1.0 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: page-master/layout AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: med1...@gmail.com Classification: Unclassified If force-page-count="odd" and the first page has an overflowing region onto a second page, then the 3rd and last page should use the page-position="last" simple-page-master in the conditional-page-master-reference. However, it was using the "rest". I'm having a few issues with the apache git server, so I'll attach the patch when the issues have been resolved. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51664] [PATCH] Tagged PDF performance improvement + tests
https://issues.apache.org/bugzilla/show_bug.cgi?id=51664 --- Comment #5 from Mehdi Houshmand 2011-10-05 10:38:18 UTC --- (In reply to comment #4) > Thanks for the patch Mehdi. Looking at [1] I realised that you haven't yet > filed an ICLA. The ASF encourages all contributors to do so and it is a > pre-requisite to becoming a committer. Since you have filed a number of > patches its about time you filed in the ICLA as described in [2]. Thanks > > [1] http://people.apache.org/committer-index.html > [2] http://www.apache.org/licenses/ I have faxed the appropriate documents. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: omit first table header/last footer
It seems although it does happen.. there are some work arounds this. 1) Setting line height and height to 0mm this includes that of any inline objects however within inline objects the content height does not effect 2) the location of any parent for-each statement. if specified within the table body the error occurs, if specified within a block all works ok. I shall continue to try and diagnose where errors occur. Maybe if I can find the cause somebody can modify to fix. Unfortunately I am by no means competent to look at code to do the same. Carlos Villegas wrote: > > It probably behaves that way. I wasn't sure about the implementation. It > was enough for my purposes so I didn't checked it further. > > Cheers > > On 9/21/11 6:16 PM, champagne_chary wrote: >> Would I be right in assuming that this method removes the header however >> places a space at the bottom of the page. This is unfortunately what i am >> finding. :(... The space at the bottom of the parent object (be it a >> page/ >> table row) is equivelent in height to that the header / more >> specifically >> the text within. >> >> I have tried to implement in a couple of ways and this phenominum keeps >> occuring. Hope somebody that uses this nifty mod can enlighten me on if >> there is a way around this. >> >> Cheers >> >> >> >> >> >> >> Carlos Villegas wrote: >>> I implemented this extension. I added fox:table-omit-last-footer and >>> fox:table-omit-first-header attributes to fo:table. It seems to work >>> well in my use case. >>> If anyone is interested I can submit a patch. >>> >>> Cheers, >>> Carlos >>> >>> Carlos Villegas wrote: Thanks for the pointers. I agree that implementing retrieve-table-marker is not only a more generic solution but also what the spec requires. However, I'm short on time and this seems easier so I'll give it a try first. Regards, Carlos Vincent Hennebert wrote: > Hi Carlos, > > Carlos Villegas wrote: >> Hi, >> >> I searched the mailing lists and it seems that although some people >> had >> worked at several times at trying to implement retrieve-table-marker, >> it's not yet done. Is somebody working on this? What's the status? > It’s not being worked on at the moment. This is still a missing > feature. > > >> In many use cases omitting the first table header and the last table >> footer will do the trick. >> >> How easy is this to implement? >> What will be the steps to add such an extension to FOP? >> I just started looking at the code so I'm exploring whether this is >> viable solution. > That might work. You would need to change the > o.a.f.layoutmgr.table.TableContentLayoutManager.getNextKnuthElements > method. There is a “if (getTableLM().getTable().omitHeaderAtBreak())” > test that you could augment with a “&& !(omitFirstHeader)” clause. > Likewise for the footer. > > The easiest is to directly modify that class and re-build FOP. A bit > less easy would be to add a variable in the configuration file, so > that > you can enable it only for certain FO files. Even less easy would be > to > add an extension property to fo:table so that you can enable it only > for > some tables of an FO document. Please ask if you need more details. > > All that said, such a change would be very hacky and, unless there is > overwhelming demand from the user community, I would oppose to > integrate > it in the code base. This is a patch that you would have to maintain > on > your side. Better would be of course to actually implement > retrieve-table-marker. Although this would be more involving than > implementing this little trick... > > > HTH, > Vincent > >>> > > > -- View this message in context: http://old.nabble.com/omit-first-table-header-last-footer-tp25640345p32595267.html Sent from the FOP - Dev mailing list archive at Nabble.com.
DO NOT REPLY [Bug 51664] [PATCH] Tagged PDF performance improvement + tests
https://issues.apache.org/bugzilla/show_bug.cgi?id=51664 --- Comment #4 from Chris Bowditch 2011-10-05 09:55:37 UTC --- Thanks for the patch Mehdi. Looking at [1] I realised that you haven't yet filed an ICLA. The ASF encourages all contributors to do so and it is a pre-requisite to becoming a committer. Since you have filed a number of patches its about time you filed in the ICLA as described in [2]. Thanks [1] http://people.apache.org/committer-index.html [2] http://www.apache.org/licenses/ -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
