RE: Line-height inheritance
Hi Andrea, -Message d'origine- De : Andreas Delmelle [mailto:[EMAIL PROTECTED] Envoyé : mardi 8 avril 2008 23:36 On Apr 8, 2008, at 15:20, Pascal Sancho wrote: Hi Pascal, Reading the spec 7.16.4, line-height property is inherited and accepts percentages values. FOP behaves as follow: If the line-height value is a percentage, the inherited value is the computed trait: font-size*line-height(in %) I'm not sure if FOP behaviour is correct. I was expecting the percentage value for the inheried line-height. Am I wrong? FOP's behavior is correct, I think. 5.1.4 Inheritance ... For a given inheritable property, if that property is present on a child, ... otherwise, the specified value of that property on the child is the /computed/ value of that property on the parent formatting object. In other words, if you have: fo:block font-size=12pt line-height=120% fo:block font-size=8pt Then the specified line-height for the inner block would be 12pt x 120%, and not, if I interpret your question correctly, 8pt x 120%. Cheers Andreas IIUC, the following snippet should be interpreted as you said above about percentage. The 2nd fo:block line-height should be 12*1.2 fo:block font-size=12pt line-height=1.2 fo:block font-size=8pt IMHO, behaviour should be the same for either percentage or numeric value. IIUC your point of view, in both cases, according to the spec, inherited line-height should be computed value. What I expect, is that inherited line-height should remain relative when possible. (What about line-height expressed in 'em'?) WDYT? Pascal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 0.95b observations
On 09.04.2008 02:32:32 Christopher R. Maden wrote: 1) FOP now complains about empty fo:table-cells. This is strictly correct, I suppose, but annoying. More troubling, it fails with an exception and a stack trace when it happens, rather than a simpler error message. If you want to feed FOP invalid XSL-FO, you can enable relaxed validation (either on FopFactory or through the configuration) as described on the website. The thing with the stacktrace was a temporary measure as some exceptions were swallowed due to suboptimal exception handling. This will be improved with the next release as we add an processing feedback system that allows more fine-grained event handling. 2) Line-wrapping doesnt seem to happen automatically in table cells: Apr 8, 2008 4:09:58 PM org.apache.fop.layoutmgr.inline.LineLayoutManager $LineBreakingAlgorithm updateData2 WARNING: Line 1 of a paragraph overflows the available area by 11431mpt. (fo:block, location: 2/56170) is the message, now. These same paragraphs used to wrap in 0.94 and in 0.20.5. I assume you have a keep-together=always somewhere upstream of the table-cell. Please note that some support for inline keeps has been added. If you do keep-together=always you're indirectly setting keep-together.within-line=always which forbids FOP to break the line. Just change that to keep-together.within-column=always. 3) While this doesnt produce the strange page-breaking behavior seen in 0.94 (thanks!) it still does not appear to honor keep-together=always on table-body. By comparison 0.20.5 kept table-bodies together by default. My document consists of a series of these: fo:table-body border=solid 1pt black keep-together=always Dummy output is available on request, if it would be helpful. Confirmed. There is indeed a bug there. But keep in mind, it should be keep-together.within-column=always! Thanks for the feedback! Thanks, Chris -- Chris Maden, text nerd URL: http://crism.maden.org/ Weve replaced American airports with incompetent mini-police- states. Lets see if they notice! GnuPG Fingerprint: C6E4 E2A9 C9F8 71AC 9724 CAA3 19F8 6677 0077 C319 Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 0.95b observations
On Wed, 2008-04-09 at 09:39 +0200, Jeremias Maerki wrote: The thing with the stacktrace was a temporary measure as some exceptions were swallowed due to suboptimal exception handling. This will be improved with the next release as we add an processing feedback system that allows more fine-grained event handling. Good to know; thanks. I assume you have a keep-together=always somewhere upstream of the table-cell. Please note that some support for inline keeps has been added. If you do keep-together=always you're indirectly setting keep-together.within-line=always which forbids FOP to break the line. Just change that to keep-together.within-column=always. Ah! I helped write XSL, but it was now many years ago, and little things like that occasionally jump up and surprise me, especially when the same stylesheet has been working acceptably for years. (-: Confirmed. There is indeed a bug there. But keep in mind, it should be keep-together.within-column=always! Thanks for the feedback! Gotcha. An anonymized test, if it helps, is at URL: http://crism.maden.org/table-test.fo and URL: http://crism.maden.org/table-test.pdf . Thanks, Chris -- Chris Maden, text nerd URL: http://crism.maden.org/ We’ve replaced American airports with incompetent mini-police- states. Let’s see if they notice! GnuPG Fingerprint: C6E4 E2A9 C9F8 71AC 9724 CAA3 19F8 6677 0077 C319 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 0.95b observations
On 09.04.2008 10:19:09 Christopher R. Maden wrote: snip/ Confirmed. There is indeed a bug there. But keep in mind, it should be keep-together.within-column=always! Thanks for the feedback! Gotcha. Actually, I have to correct myself. I just noticed that keep-together does not apply to fo:table.body: http://www.w3.org/TR/xsl11/#fo_table-body It is an inherited property so a keep is imposed on all table-rows in the body but not the whole body is kept together. So there's actually no bug. So you'll have to work with keep-with-next on all table-rows in the body to keep them together, or you specify the keep on the table itself. An anonymized test, if it helps, is at URL: http://crism.maden.org/table-test.fo and URL: http://crism.maden.org/table-test.pdf . Thanks, Chris -- Chris Maden, text nerd URL: http://crism.maden.org/ Weve replaced American airports with incompetent mini-police- states. Lets see if they notice! GnuPG Fingerprint: C6E4 E2A9 C9F8 71AC 9724 CAA3 19F8 6677 0077 C319 Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javax.xml.transform.TransformerException: java.lang.NullPointerException
Hello Jeremias, Are you saying that I should generate FO file from command line and share it with you? If not, can you please let me know from where I can get the FO file? I am using FOP 0.94 version. With Thanks! Newkid Jeremias Maerki-2 wrote: please just run the XSLT stage and take a look at the FO file that you generate with your stylesheet. -- View this message in context: http://www.nabble.com/javax.xml.transform.TransformerException%3A-java.lang.NullPointerException-tp16577116p16585362.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javax.xml.transform.TransformerException: java.lang.NullPointerException
Yes, that's what I'm saying. You can also do it in your application if you embedded FOP. From the command-line, you can do: fop -xml myxml.xml -xsl myxsl.xsl -foout out.fo This just runs the XSLT transformation. We usually don't like XML + XSLT because there are all sorts of things that can go wrong and it's more work to set it up in a test environment. If we just get the FO, we can more easily reproduce any problem (depending on the case, any images may also need to be made available). On the other hand, if you just run the XSLT stage you can verify yourself what your stylesheet produces and you can figure out what needs to be changed (This is certainly the first step before sending us the FO). HTH On 09.04.2008 15:08:22 Newkid wrote: Hello Jeremias, Are you saying that I should generate FO file from command line and share it with you? If not, can you please let me know from where I can get the FO file? I am using FOP 0.94 version. With Thanks! Newkid Jeremias Maerki-2 wrote: please just run the XSLT stage and take a look at the FO file that you generate with your stylesheet. -- View this message in context: http://www.nabble.com/javax.xml.transform.TransformerException%3A-java.lang.NullPointerException-tp16577116p16585362.html Sent from the FOP - Users mailing list archive at Nabble.com. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Question about simple-page-master known problem
Hello, I am using FOP version 0.94. The problem I am having has been described on the compliance page as: [0.94 and later] The page width may not change among pages of the same page-sequence unless a forced break is inserted. Is there a way I can get around this or a change I can make to the code so that this will work? In case it's needed.. here's my XSL code for the layout-master-set: fo:layout-master-set !-- Layout for first page -- fo:simple-page-master master-name=firstPage page-height=11in page-width=8.5in margin-top=27pt margin-bottom= 27pt margin-left=54pt margin-right=-84pt fo:region-body margin-top=100pt margin-bottom= 57pt margin-left=216pt margin-right=138pt background-color=blue/ fo:region-before precedence=true extent=25pt/ fo:region-after precedence=true extent=30pt/ fo:region-start extent=216pt/ fo:region-end extent=225pt/ /fo:simple-page-master !-- Layout for the rest of the pages -- fo:simple-page-master master-name=restOfPages page-height=11in page-width=8.5in margin-top=27pt margin-bottom= 27pt margin-left=54pt margin-right=54pt fo:region-body margin-bottom=27pt background-color=blue/ fo:region-after precedence=true extent=30pt/ /fo:simple-page-master !-- Set up page sequencing -- fo:page-sequence-master master-name=pgsm fo:repeatable-page-master-alternatives fo:conditional-page-master-reference master-reference=firstPage page-position=first/ fo:conditional-page-master-reference master-reference=restOfPages page-position=rest/ fo:conditional-page-master-reference master-reference=restOfPages/ /fo:repeatable-page-master-alternatives /fo:page-sequence-master /fo:layout-master-set Thank You! Richard C. Forrester IV IBM Global Sales Manual Technical Lead/Analyst/Developer Email : [EMAIL PROTECTED] Phone : (303) 924-6066 T/L : 8-263-6066 Fax: (303) 924-7616 Fax T/L : 8-263-7616
Re: Problems ansi encoding in TTF fonts
Hi again, I am trying with the FOP TRUNK and i have the same problem. I think FontReader can´t read fine the font metrics generated with TTFReader or TTFReader generates a bad font metrics structure when i use encoding ansi. Jose Sanchez wrote: Hi , I generate a pdf file using FOP 0.95 Beta and i am embedding a TTF font, for instance GARAMOND. I generate the appropiate font metrics using TTFReader class. I have no problems to generate the pdf, but when i use Adobe Reader to view it in, in Document Properties, Fonts, shows the following: Garamond-Bold (Embedded Subset) Type: TrueType (CID) Encoding: Identity-H. Then, if i try print the pdf file using JPS (Java Print Service) in the document printed fonts are not showed. This, not occurs when i use one of the fourteen standard fonts of Adobe PDF espec. I think the problem could be font encoding issues, and i generate the metrics using the option -enc ansi, but when i generate the pdf, i have a FontReader exception: 9:35:44,078 ERROR [STDERR] java.lang.NullPointerException 9:35:44,078 ERROR [STDERR] at org.apache.fop.fonts.FontReader.endElement(FontReader.java:231) 9:35:44,078 ERROR [STDERR] at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) 9:35:44,078 ERROR [STDERR] at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) 9:35:44,078 ERROR [STDERR] at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) 9:35:44,078 ERROR [STDERR] at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) 9:35:44,078 ERROR [STDERR] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) 9:35:44,078 ERROR [STDERR] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) 9:35:44,078 ERROR [STDERR] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) 9:35:44,078 ERROR [STDERR] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) 9:35:44,078 ERROR [STDERR] at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) 9:35:44,078 ERROR [STDERR] at org.apache.fop.fonts.FontReader.createFont(FontReader.java:90) 9:35:44,078 ERROR [STDERR] at org.apache.fop.fonts.FontReader.init(FontReader.java:139) 9:35:44,078 ERROR [STDERR] at org.apache.fop.fonts.LazyFont.load(LazyFont.java:113) 9:35:44,078 ERROR [STDERR] at org.apache.fop.fonts.LazyFont.getAscender(LazyFont.java:233) 9:35:44,078 ERROR [STDERR] at org.apache.fop.fonts.Font.getAscender(Font.java:96) 9:35:44,078 ERROR [STDERR] at org.apache.fop.layoutmgr.BlockLayoutManager.initialize(BlockLayoutManager.java:87) 9:35:44,078 ERROR [STDERR] at org.apache.fop.layoutmgr.AbstractLayoutManager.getChildLM(AbstractLayoutManager.java:118) 9:35:44,078 ERROR [STDERR] at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:271) 9:35:44,078 ERROR [STDERR] at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:116) 9:35:44,078 ERROR [STDERR] at org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:107) 9:35:44,078 ERROR [STDERR] at org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:145) 9:35:44,078 ERROR [STDERR] at org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:552) 9:35:44,078 ERROR [STDERR] at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:137) 9:35:44,078 ERROR [STDERR] at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:302) 9:35:44,078 ERROR [STDERR] at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:264) 9:35:44,078 ERROR [STDERR] at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:106) 9:35:44,078 ERROR [STDERR] at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:234) 9:35:44,078 ERROR [STDERR] at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:123) 9:35:44,078 ERROR [STDERR] at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:340) 9:35:44,078 ERROR [STDERR] at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:169) 9:35:44,078 ERROR [STDERR] at net.sf.saxon.event.ContentHandlerProxy.endElement(ContentHandlerProxy.java:372) 9:35:44,078 ERROR [STDERR] at net.sf.saxon.event.NamespaceReducer.endElement(NamespaceReducer.java:192) 9:35:44,078 ERROR [STDERR] at net.sf.saxon.event.ReceivingContentHandler.endElement(ReceivingContentHandler.java:333) 9:35:44,078 ERROR [STDERR] at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) 9:35:44,078 ERROR [STDERR] at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown
Re: Line-height inheritance
On Apr 9, 2008, at 09:03, Pascal Sancho wrote: -Message d'origine- De : Andreas Delmelle [mailto:[EMAIL PROTECTED] Envoyé : mardi 8 avril 2008 23:36 In other words, if you have: fo:block font-size=12pt line-height=120% fo:block font-size=8pt Then the specified line-height for the inner block would be 12pt x 120%, and not, if I interpret your question correctly, 8pt x 120%. IIUC, the following snippet should be interpreted as you said above about percentage. The 2nd fo:block line-height should be 12*1.2 fo:block font-size=12pt line-height=1.2 fo:block font-size=8pt No, because, as Erick and Manuel already pointed out, this is an explicit exception to the general rule. IMHO, behaviour should be the same for either percentage or numeric value. IIUC your point of view, in both cases, according to the spec, inherited line-height should be computed value. What I expect, is that inherited line-height should remain relative when possible. (What about line-height expressed in 'em'?) I agree with you that it may seem inconsistent, but still: only the numeric value is the exception. We can only guess, but it may just have been defined so, because otherwise there would be no way at all to achieve the effect of inheriting a relative value... For em's or other font-size-relative units, the computation/ resolution to an absolute value again will be done relative to the outer block's font-size, and the computed value is inherited by the inner block, unless it is overridden there. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 0.95b observations
On Wed, 2008-04-09 at 11:17 +0200, Jeremias Maerki wrote: Actually, I have to correct myself. I just noticed that keep-together does not apply to fo:table.body: http://www.w3.org/TR/xsl11/#fo_table-body Wow... thanks for catching that. It’s working perfectly now. I can’t explain or understand the rationale for that decision, though... this is one of the things that using multiple table-body elements is great for. Not being able to keep them together doesn’t gain anything. Thanks again, Chris -- Chris Maden, text nerd URL: http://crism.maden.org/ We’ve replaced American airports with incompetent mini-police- states. Let’s see if they notice! GnuPG Fingerprint: C6E4 E2A9 C9F8 71AC 9724 CAA3 19F8 6677 0077 C319 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP memory issues in servlet on Websphere
On Apr 8, 2008, at 22:01, Andreas Delmelle wrote: Just noticed a small error, so slight correction: I have received confirmation in an off-list discussion that one and the same document, rendered with FOP 0.94: This should be 0.20.5, actually... There /are/ a few Bugzilla entries that confirm that the behavior of the IBM 1.4.2 JVM is equally bad for FOP 0.9x, though. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FOP 0.95beta: .BMP color inversion bug?
Hello, I've noticed in testing FOP 0.95beta that 24-bit .BMPs seem to render with their colors flipped (red = blue, cyan = yellow). This seems to affect all colors, except for black and white. All colors render properly when using 8-bit .BMPs. I'm not certain if this is an issue with FOP or with ImageIO, but I figured I would try here first. I've attached a small .fo file and .bmp to illustrate the problem. Let me know if I'm barking up the wrong tree. Thanks, Charlie Flowers attachment: test.bmp test.fo Description: test.fo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svg not working on linux
Hello foppers, We've just put a watermark on our documents it works fine on two PC's using FOP 0.20.5, 0.93 0.94. It's completely ignored on two linux servers (tested with same 3 fop versions). The rest of the document renders fine, just no watermark, except for 20.5 which fails with an erroneous error about an id already existing (yes it only happens with below svg included). fo:block-container width=25cm height=18cm top=0cm left=0cm position=absolute fo:block fo:instream-foreign-object xmlns:svg=http://www.w3.org/2000/svg; svg:svg width=25cm height=18cm svg:g transform=rotate(-35) svg:text x=-200 y=17cm style=font-family:serif; font-size:70pt; font-weight:normal; fill:none; stroke:black; stroke-width:1.0; stroke-opacity:0.30; letter-spacing:14pt; xsl:value-of select=substring-before(Header/Amend_Confirm,':')/ /svg:text /svg:g /svg:svg /fo:instream-foreign-object /fo:block /fo:block-container We've tried changing font, colour opacity set the xslt xml declaration to standalone. The server already has the headless=true option on. Can anyone see any problems with this? Otherwise it's gif time. Another interesting note is that the svg overlays the region-body text, but not the static-content stuff. This is annoying, hence the no-fill. -- Regards, Roland This e-mail is solely for the use of the intended recipient and may contain information which is confidential or privileged. Unauthorised use of its contents is prohibited. If you have received this e-mail in error, please notify the sender immediately via return e-mail and then delete the original e-mail. Any views or opinions presented are solely those of the author. This e-mail is solely for the use of the intended recipient and may contain information which is confidential or privileged. Any unauthorised use of its contents is prohibited. If you have received this e-mail in error, please notify the sender via return e-mail and then delete the original e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javax.xml.transform.TransformerException: java.lang.NullPointerException
Hello Jeremias, I have attached the FO file with this reply for your reference. I am unable to find out the cause of the exceptions as all look pretty fine to me. Please advice. With Thanks! Newkid Jeremias Maerki-2 wrote: Yes, that's what I'm saying. You can also do it in your application if you embedded FOP. From the command-line, you can do: fop -xml myxml.xml -xsl myxsl.xsl -foout out.fo This just runs the XSLT transformation. We usually don't like XML + XSLT because there are all sorts of things that can go wrong and it's more work to set it up in a test environment. If we just get the FO, we can more easily reproduce any problem (depending on the case, any images may also need to be made available). On the other hand, if you just run the XSLT stage you can verify yourself what your stylesheet produces and you can figure out what needs to be changed (This is certainly the first step before sending us the FO). HTH http://www.nabble.com/file/p16601756/TestOutput.fo TestOutput.fo -- View this message in context: http://www.nabble.com/javax.xml.transform.TransformerException%3A-java.lang.NullPointerException-tp16577116p16601756.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
