Bug report for Fop [2008/05/04]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 1063|New|Nor|2001-03-21|fop does not handle large fo files| | 3280|New|Nor|2001-08-27|PCL Renderer doesn't work | | 3824|New|Blk|2001-09-25|MIF option with tables| | 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S| | 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG | | 5010|New|Enh|2001-11-21|Better error reporting needed | | 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using | | 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output| | 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem| | 6997|New|Nor|2002-03-09|[PATCH] Row-spanned row data breaks over a page wi| | 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on| | 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images | | 8463|New|Nor|2002-04-24|SVG clipping in external.fo example doc when rende| | 8767|Ass|Min|2002-05-03|Image and solid colour background rectangle sizes | | 9379|New|Nor|2002-05-24|MIF Renderer generates incorrect MIF code | |10379|New|Enh|2002-07-01|Improvement to FOP Classloader| |12494|New|Nor|2002-09-10|fop produces pdf file which Acrobat Reader refuses| |12610|New|Enh|2002-09-13|[PATCH] onLoad Action for PDF documents or how to | |13586|New|Blk|2002-10-13|fop will not work on linux alpha because jre is br| |13734|New|Nor|2002-10-17|Hyphenation does not work correctly on long string| |14248|New|Enh|2002-11-05|51-page FO example, could be added to the samples | |14352|New|Enh|2002-11-07|It would be nice if FOP could be plugged into popu| |14356|New|Nor|2002-11-07|*NOT* embedding TrueTypeFont in PDF causes Acrobat| |14419|New|Enh|2002-11-10|Implement SourceResolver, Image Resolver | |14529|New|Nor|2002-11-13|SVG url references do not work| |14679|New|Enh|2002-11-19|Pluggable renderers | |14924|New|Nor|2002-11-28|Table disappears when it ends when the page ends | |15020|New|Enh|2002-12-03|Reuse of fo-tree | |16017|Opn|Nor|2003-01-13|Jpeg's and the PDF Serializer | |16130|New|Nor|2003-01-15|PS-Renderer emits lots of redundant moveto's | |16156|New|Nor|2003-01-16|0.20.5rc SVG example does not work| |16713|New|Nor|2003-02-03|Hyphenation error in tables | |17369|New|Nor|2003-02-25|Footnote duplication | |17380|New|Nor|2003-02-25|Batik Component will not recognize fe SVG elem| |17921|New|Nor|2003-03-12|Kerning is broken for standard fonts | |18292|New|Nor|2003-03-24|24 bit PNG not displayed correctly| |18801|New|Nor|2003-04-08|visibility property is not implemented | |19228|New|Blk|2003-04-22|[PATCH] Child LayoutContext is null in certain cir| |19341|Ver|Nor|2003-04-26|leader doesn't work since 0.20.5.rc2 | |19695|New|Enh|2003-05-06|[PATCH] Allow fox:destination as child of fox:outl| |19717|New|Enh|2003-05-07|Lets add support for JimiClassesPro.zip to build.x| |19769|Ass|Enh|2003-05-08|Indefinite page size is not implemented | |20280|Ass|Enh|2003-05-27|text-align and text-align-last only partially impl| |20407|New|Enh|2003-06-02|[PATCH] Configure image caching using the configur| |20827|New|Enh|2003-06-17|Derive other font styles and weights from normal T| |21265|Opn|Nor|2003-07-02|referencing a custom font (TTF or Adobe Type 1) fo| |21905|New|Nor|2003-07-26|large list-item-label bleeds into following block | |21982|New|Maj|2003-07-30|NullPointer Exception in LazyFont with embedded fo| |22450|New|Maj|2003-08-15|Unterminated iteration in JPEGReader class| |22627|Opn|Nor|2003-08-21|Update mirror/download page HEADER README (was [| |24148|New|Nor|2003-10-27|Kerning upsets text-align=end |
DO NOT REPLY [Bug 39983] AWTRenderer should not call System.exit().
https://issues.apache.org/bugzilla/show_bug.cgi?id=39983 Andreas L. Delmelle [EMAIL PROTECTED] changed: What|Removed |Added Status|VERIFIED|CLOSED --- Comment #7 from Andreas L. Delmelle [EMAIL PROTECTED] 2008-05-04 23:23:49 PST --- Second try... Resolution already set to FIXED. -- 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 43650] [PATCH] PCL Renderer Bug rendered jobs connot be printed on duplex printers
https://issues.apache.org/bugzilla/show_bug.cgi?id=43650 Jeremias Maerki [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Jeremias Maerki [EMAIL PROTECTED] 2008-05-04 23:54:51 PST --- Applied now to FOP Trunk: http://svn.apache.org/viewvc?rev=653311view=rev Thanks and sorry for the delay. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
think I found a bug
Hello, I already posted in the user group, but they only wonder about my error and can't help. So I think that it is a bug. I use Apache FOP 0.95beta but the same error also occured in 0.94 stable version: When trying to make a new instance of the fop factory with FopFactory fopFactory = FopFactory.newInstance(); I get an exception with the following stack trace: java.lang.ClassCastException: org.apache.fop.render.afp.extensions.AFPExtensionHandlerFactory cannot be cast to org.apache.fop.util.ContentHandlerFactory at org.apache.fop.util.ContentHandlerFactoryRegistry.discover(ContentHandlerFactoryRegistry.java:105) at org.apache.fop.util.ContentHandlerFactoryRegistry.init(ContentHandlerFactoryRegistry.java:47) at org.apache.fop.apps.FopFactory.init(FopFactory.java:76) at org.apache.fop.apps.FopFactory.newInstance(FopFactory.java:166) at de.hc.pdf_from_word.PdfCreator.convertXML2PDF(PdfCreator.java:44) at de.hc.pdf_from_word.CorrespondenceCase.createCorrespondence(CorrespondenceCase.java:81) at de.hc.pdf_from_word.CorrespondenceCase.makeCorrespondence(CorrespondenceCase.java:64) at de.hc.pdf_from_word.CorrespondenceCase.initiate(CorrespondenceCase.java:113) at org.apache.jsp.Anmeld_L3_2211_jsp._jspService(Anmeld_L3_2211_jsp.java:524) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:210) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2422) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:163) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:199) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:700) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:584) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:619) In the user group they told me they assume that I use different versions of fop at thte same time but in my classpath and container I only use one fop.jar at the time. Please excuse me, if this doesn't fit in this group. I would be happy about a hint. Andreas Schröder _ In 5 Schritten zur eigenen Homepage. Jetzt
Re: think I found a bug
the funny thing is, that the exception only sometimes occures. sometimes it works just fine. _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071distributionid=0066
DO NOT REPLY [Bug 37579] footnotes within tables and listsl get lost
https://issues.apache.org/bugzilla/show_bug.cgi?id=37579 --- Comment #23 from Luca Furini [EMAIL PROTECTED] 2008-05-05 05:59:03 PST --- Thank you for all your comments and additions, Andreas! It's good to be back after quite a long time (enough to forget the good old habit of using JUnit!) (In reply to comment #22) (In reply to comment #21) The problem with getLengthBase() seems to point to a difficulty with property-inheritance: strictly speaking, the footnote should inherit the computed value for start-indent(), Sorry, I obviously meant end-indent. What I still cannot understand is why there is no such problem with start-indent = body-start, which is resolved ok ... (In reply to comment #17) Right, my first instinct would be to include footnotes for the table-header only on the first page that is spanned by the table, and for the table-footer only on the last page. It's an interesting idea, and probably the easiest to implement. Personally, I would have placed them all in the first page spanned by the table, although this would be a bit more problematic in terms of relative order between the footnotes. What do other think in this regard? Anyway, I think this is a situation not perfectly covered by the specs, which forbid footnotes in static-contents but say nothing about footnotes in table headers / footers, which are not so different. The condition defining where a block area returned by fo:footnote is permitted does not explicitly take into account the situation when a single fo:foonote generates several anchor areas in different pages, although the definition The term anchor-area is defined to mean the last area that is generated and returned by the fo:inline child of the fo:footnote. could maybe be read as a justification for placing all the notes in the last page where the table appears ... -- 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 37579] footnotes within tables and listsl get lost
https://issues.apache.org/bugzilla/show_bug.cgi?id=37579 --- Comment #24 from Andreas L. Delmelle [EMAIL PROTECTED] 2008-05-05 07:15:17 PST --- (In reply to comment #23) Thank you for all your comments and additions, Andreas! It's good to be back after quite a long time (enough to forget the good old habit of using JUnit!) :-) No problem. That's why it's A Good Thing that there's more of us. (In reply to comment #21) The problem with getLengthBase() seems to point to a difficulty with property-inheritance: strictly speaking, the footnote should inherit the computed value for start-indent(), Sorry, I obviously meant end-indent. What I still cannot understand is why there is no such problem with start-indent = body-start, which is resolved ok ... They are implemented differently: see org.apache.fop.fo.expr.BodyStartFunction and .LabelEndFunction. label-end() makes explicit use of a percentage, body-start() does not... It is only that percentage which causes the error. For 'normal' list-item-label descendants, the base-length is found by climbing up the LM tree until the corresponding LM is found. That's what happens in AbstractBaseLM.getBaseLength(). Come to think of it, maybe a way to avoid the warning would be to reimplement getBaseLength() in FootnoteBodyLM, to do something else than try out all ancestors... (long shot) Right, my first instinct would be to include footnotes for the table-header only on the first page that is spanned by the table, and for the table-footer only on the last page. It's an interesting idea, and probably the easiest to implement. Personally, I would have placed them all in the first page spanned by the table, although this would be a bit more problematic in terms of relative order between the footnotes. Yours is probably the better idea... Since the footer can appear on the first page, it would indeed be confusing to have its footnote appear maybe 10 pages after the citation first appears. -- 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 38264] Hyphenation does not play well with preserved linefeed-treatment or white-space-treatment
https://issues.apache.org/bugzilla/show_bug.cgi?id=38264 --- Comment #9 from Andreas L. Delmelle [EMAIL PROTECTED] 2008-05-05 07:27:25 PST --- Trying to gain more understanding of this issue, and as I see it, the full story wrt linefeed-treatment='preserve' and hyphenate='true' is: 1) for blocks of text containing preserved linefeeds, the TextLayoutManager actually generates multiple Paragraphs (see TextLM.getNextKnuthElements() - in case of an explicit break, the 'current' sequence is ended, and a new one is added to the returnList) 2) the optimal line-breaks are determined by the LineLayoutManager per Paragraph ( see LineLM.createLineBreaks() ) 3) the hyphenation-points are determined for each Paragraph in the same loop ( see LineLM.findOptimalBreakingPoints() ) 4) BUT: the integration of hyphenation-points (applyChanges() and getChangedKnuthElements()) operate on the TextLayoutManager instance as a whole. = the entire content generated by the TextLM in question is copied as many times as there are paragraphs/preserved linefeeds in the source Mainly TextLM.getChangedKnuthElements() is a bit problematic in this regard: every time this is called, it generates an element-list based on the complete set of AreaInfos for the LM. In LineLM.findHyphenationPoints(), each of the original paragraphs is replaced by that list. I already tried to change that method to take into account the position-indices of the first and last element in the parameter oldList. This already gets me somewhat further, but still far from committable... -- 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 44933] New: Color palette of .bmp files with 1 bit/ pixel not used
https://issues.apache.org/bugzilla/show_bug.cgi?id=44933
Summary: Color palette of .bmp files with 1 bit/pixel not used
Product: Fop
Version: 0.94
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: images
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]
Depends on: 6178
I found this bug reported for all versions.
It has been marked as fixed, but I still got the same behaveiour.
+++ This bug was initially created as a clone of Bug #6178 +++
The color palette of .bmp files with 1 bit/pixel is not used when loading
image.
Example of a bmp header I've received from Alchemy on Unix:
424DAE8E0100 3E002800
0010 1603FC03 01000100
0020 708E0100C21E C21E
0030 FF00
0040
The palette is inverted (why, I don't know). So a 0 bit means a white pixel and
a 1 bit means a black pixel.
In class org.apache.fop.image.BmpImage, method loadImage ignores the palette in
that case (it's not even constructed). For FOP, a 0 bit means always black
pixel and a 1 bit means always white pixel.
So my image appears in Acrobat Reader as inverted video.
I have fixed the bug with the following statements :
if (headermap[28] == 4 || headermap[28] == 8 || headermap[28] == 1) {
to always build the palette and
for (int countr = 0; countr 8 x this.m_width;
countr++) {
if ((p 0x80) != 0) {
this.m_bitmaps[3 * (i * this.m_width + x)] =
// (byte)0xFF;
palette[3];
this.m_bitmaps[3 * (i * this.m_width + x) + 1] =
// (byte)0xFF;
palette[4];
this.m_bitmaps[3 * (i * this.m_width + x) + 2] =
// (byte)0xFF;
palette[5];
} else {
this.m_bitmaps[3 * (i * this.m_width + x)] =
// (byte)0;
palette[0];
this.m_bitmaps[3 * (i * this.m_width + x) + 1] =
// (byte)0;
palette[1];
this.m_bitmaps[3 * (i * this.m_width + x) + 2] =
// (byte)0;
palette[2];
}
to use it.
I think it could help.
Frédéric.
--
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 6178] Color palette of .bmp files with 1 bit/ pixel not used
https://issues.apache.org/bugzilla/show_bug.cgi?id=6178 diego [EMAIL PROTECTED] changed: What|Removed |Added Blocks||44933 -- 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: think I found a bug
On May 5, 2008, at 10:55, Andreas Schröder wrote:
Hi
I already posted in the user group, but they only wonder about my
error and can't help. So I think that it is a bug.
I use Apache FOP 0.95beta but the same error also occured in 0.94
stable version: When trying to make a new instance of the fop
factory with FopFactory fopFactory = FopFactory.newInstance(); I
get an exception with the following stack trace:
java.lang.ClassCastException:
org.apache.fop.render.afp.extensions.AFPExtensionHandlerFactory
cannot be cast to org.apache.fop.util.ContentHandlerFactory
I dug up the earlier thread on fop-users@, and I suspect that Jörg's
reply is the one that holds the key.
quote
In a web application, this may also be happen if the
AFPExtensionHandlerFactory has been loaded in a different
security context , which means it is an implementation of
the ContentHandlerFactory of the other context.
/quote
From the stack trace, we can deduce that you create a new fopFactory
instance for each run ('newInstance()' always means 'new FopFactory
();').
The original ContentHandlerFactory class has probably already been
loaded when the servlet container first initialized, by the default
ClassLoader (or by the ClassLoader used in the first run).
No idea how this can be verified, though. To ascertain whether this
is the case, my personal first shot would be to try to set up a
central fopFactory instance, which would also be loaded only once,
when the webapp is first initialized. The big difference would be
that you'd use that very same FopFactory for all the requests, which
should eliminate the issue...
HTH!
Andreas
DO NOT REPLY [Bug 44935] New: Table content within tables with margin-left are offset too
https://issues.apache.org/bugzilla/show_bug.cgi?id=44935 Summary: Table content within tables with margin-left are offset too Product: Fop Version: all Platform: PC OS/Version: Windows XP Status: NEW Severity: critical Priority: P2 Component: page-master/layout AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] When a document is created using a table specified with margin-left of any value, the contents of the table are also offset in the cells by the same amount. It appears that the margin-left trait of the table is being inherited by the table cells as well, when it should not be. I was able to recreate this problem with any margin value, but it is especially noticeable with a large left margin, such as 2.5in or 3in. The specific application we were trying to perform was a letter with a form section displaced to the right on the page. When the left margin is set to zero, the problem disappears. I also noticed that all of the test cases do not use left margins for the tables, so it is possible that this has existed for a long time. I have attached the actual letter document that I was trying to render to this bug report. It was created from a Word document, converted using Open-Office and XSLT transforms to convert it to XSL-FO. I have also been able to reproduce the problem with a hand-coded document. -- 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 44935] Table content within tables with margin-left are offset too
https://issues.apache.org/bugzilla/show_bug.cgi?id=44935 --- Comment #1 from Dewayne Hafenstein [EMAIL PROTECTED] 2008-05-05 08:01:20 PST --- Created an attachment (id=21921) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=21921) This is an actual letter that we are using to test our application with -- 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 44935] Table content within tables with margin-left are offset too
https://issues.apache.org/bugzilla/show_bug.cgi?id=44935 Andreas L. Delmelle [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from Andreas L. Delmelle [EMAIL PROTECTED] 2008-05-05 08:10:13 PST --- This is not a bug, but a known peculiarity in the XSL-FO Recommendation. We have dedicated an entire Wiki page to it: http://wiki.apache.org/xmlgraphics-fop/IndentInheritance In short: - margin-left indeed is not inherited, but the corresponding property start-indent is - the value of margin-left is used to compute start-indent on the table (lr-tb writing mode) - the descendants inherit the computed value for start-indent You can sidestep the problem, either by resetting start-indent to 0pt on the table-body, or by using a configuration file that sets the 'break-indent-inheritance' configuration option to true. -- 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 37579] footnotes within tables and listsl get lost
https://issues.apache.org/bugzilla/show_bug.cgi?id=37579 --- Comment #25 from Andreas L. Delmelle [EMAIL PROTECTED] 2008-05-05 09:16:07 PST --- (In reply to comment #24) ... It is only that percentage which causes the error. For 'normal' list-item-label descendants, the base-length is found by climbing up the LM tree until the corresponding LM is found. That's what happens in AbstractBaseLM.getBaseLength(). Come to think of it, maybe a way to avoid the warning would be to reimplement getBaseLength() in FootnoteBodyLM, to do something else than try out all ancestors... (long shot) Did some further research, and the ancestor tree for both footnotes' LMs (label and body) looks like: ListItemContentLayoutManager - BlockLayoutManager - LineLayoutManager - FootnoteLayoutManager - FootnoteBodyLayoutManager The default getBaseLength() in percentage resolution relies on the LM's getFObj() method to find the LM corresponding to the FO on which the percentage is based (the one that is passed as an argument to the PercentLength constructor in LabelEndFunction). For the ListItemContentLayoutManager, this method always returns the ListItemBody (never the ListItemLabel). It would probably work as expected if we had separate ListItemLabelLM and ListItemBodyLM. Similar issues occur with the table-related objects BTW, where we also do not have a 1-1 correspondence between FO and LM... -- 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 37579] footnotes within tables and listsl get lost
https://issues.apache.org/bugzilla/show_bug.cgi?id=37579 --- Comment #26 from Andreas L. Delmelle [EMAIL PROTECTED] 2008-05-05 09:41:40 PST --- (In reply to comment #25) Did some further research, and the ancestor tree for both footnotes' LMs (label and body) looks like: ListItemContentLayoutManager - BlockLayoutManager - LineLayoutManager - FootnoteLayoutManager - FootnoteBodyLayoutManager Strike that... Stopped debugging too early. The label's LM does appear if I leave it running... -- 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 37579] footnotes within tables and listsl get lost
https://issues.apache.org/bugzilla/show_bug.cgi?id=37579 --- Comment #27 from Andreas L. Delmelle [EMAIL PROTECTED] 2008-05-05 10:02:04 PST --- (In reply to comment #26) Strike that... Stopped debugging too early. The label's LM does appear if I leave it running... At the point where getBaseLength() fails, the ancestor tree looks like: FlowLayoutManager - FootnoteBodyLM So, the LM is reparented (in PageBreaker, line 166), and somewhere after that, we get a call to PercentLength.getValue(footnoteBodyLayoutManager) -- 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 37579] footnotes within tables and listsl get lost
https://issues.apache.org/bugzilla/show_bug.cgi?id=37579 --- Comment #28 from Andreas L. Delmelle [EMAIL PROTECTED] 2008-05-05 10:42:16 PST --- Created an attachment (id=21922) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=21922) Patch for FootnoteBodyLayoutManager Naively tried adding an override for getParent() to FootnoteBodyLM that always returns the associated FootnoteLM, and then it works without errors, but as I expected, the footnote's end-indent is then equal to that of the label. May count as a fix, though... I haven't checked yet if there's a situation where FootnoteBodyLM.getParent() is supposed to return the FlowLM. -- 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: svn commit: r653202 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/TextLayoutManager.java
[EMAIL PROTECTED] wrote:
kern = font.getKernValue(previous, c) *
font.getFontSize() / 1000;
-}
+}
if (kern != 0) {
Uh, oh. Something went wrong with autoindentation?
J.Pietschmann
Re: svn commit: r653202 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/TextLayoutManager.java
On May 5, 2008, at 21:15, J.Pietschmann wrote:
[EMAIL PROTECTED] wrote:
kern = font.getKernValue
(previous, c) * font.getFontSize() / 1000;
-}
+}
if (kern != 0) {
Uh, oh. Something went wrong with autoindentation?
Nice catch. More or less. Probably an after-effect from applying and
reversing patches locally. Correction just committed.
Cheers
Andreas
