Re: Font Symbol doesn't work
According to FOP developers [1], when rendering SVGs, FOP uses batik library - which doesn't use FOP's font configuration, using system fonts instead. I am using a work-around I described in that thread [1] to get SVGs to use proper fonts; you can also pre-render them in your vector editor (e.g., in Inkscape: Path - Object to path). [1] http://permalink.gmane.org/gmane.text.xml.fop.user/34984 Regards, Alexey. On Thursday, December 05, 2013 07:45:29 am markus.sticker.e...@zf.com wrote: Hello, I tried to use (for PDF) a SVG which is using the font “symbol”. (I know the font is a BASE14 font and is embedded in the Adobe Reader. So I tried with symbol.ttf in the config and also without. I also cleaned the Font Cache) I also have take a look in to the sources and the desired glyph are described. So this is confusing me, because they got width but are not in the font ? Expected: formula.png I got: formula_fail.png -- FOP message -- [WARN] DefaultEventListener - glyphNotAvailable - Glyph ( (0x28, parenleft) not available in font SymbolMT. [WARN] DefaultEventListener - glyphNotAvailable - Glyph ) (0x29, parenright) not available in font SymbolMT. [WARN] DefaultEventListener - glyphNotAvailable - Glyph ò (0xf2, ograve) not available in font SymbolMT. [WARN] DefaultEventListener - glyphNotAvailable - Glyph + (0x2b, plus) not available in font SymbolMT. [WARN] DefaultEventListener - glyphNotAvailable - Glyph = (0x3d, equal) not available in font SymbolMT. -- FOP message -- Symbol.java è width[0x2b] = 549; è width[0xf2] = 274; è …. So want’s wrong? Thanks for your help in advance Best regards Markus - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
[PATCH] Re: Incorrect leaders at FOP example
[CC'ed fop-dev - please review/commit the patch] Hi Ognjen, On Thursday, November 14, 2013 09:09:21 AM Ognjen Blagojevic wrote: Alexey, On 13.11.2013 21:46, Alexey Neyman wrote: On Wednesday, November 13, 2013 03:21:47 am Ognjen Blagojevic wrote: I need to create leaders for TOC. I started with researching FOP examples (examples/fo/basic/leaders.fo), but the generated PDF doesn't contain expected results. (...) Are my expectations too high? Hard to say, since you didn't attach neither sample FO code, nor the resulting PDF. Leaders work for me with 1.1 on multiple Java versions, 1.6.x and 1.7.x. Thank you for taking look at this. I was testing with unmodified leader.fo example which is part of the FOP distro. Here is FO file based on that example, and the resulting PDF. I used FOP 1.1, Oracle JDK 1.7.0_40-b43 on Windows 7 64-bit (also other FOP versions and OSes, but the result is always the same). It seems the leader.fo example lacks the text-align-last=justify property on the enclosing block. Because of that, FOP assumes the same alignment (start) on the line containing the leader and does not extend the leader to the end boundary of the reference area. See the attached diff - this makes the leaders work fine. FOP developers, could someone review/commit the attached diff? Regards, Alexey. Here's an example fo:leader I am using: fo:leader padding-left=4pt padding-right=4pt leader-pattern=dots leader-pattern-width=3pt leader-alignment=reference-area keep-with-next.within-line=always/ The only difference I notice to FO file I attached are attributes keep-with-next.within-line, padding-left and padding-right. Adding them to attached example does not solve the problem in the resulting PDF. -Ognjen Index: examples/fo/basic/leader.fo === --- examples/fo/basic/leader.fo (revision 1542026) +++ examples/fo/basic/leader.fo (working copy) @@ -391,7 +391,7 @@ fo:table-row line-height=12pt fo:table-cellfo:block text-align=endA) /fo:block/fo:table-cell -fo:table-cellfo:block text-align=startThis is some longer sample textfo:leader leader-pattern=dots +fo:table-cellfo:block text-align=start text-align-last=justifyThis is some longer sample textfo:leader leader-pattern=dots leader-pattern-width=8pt leader-alignment=reference-area //fo:block/fo:table-cell @@ -401,7 +401,7 @@ fo:table-row line-height=12pt fo:table-cellfo:block text-align=endB) /fo:block/fo:table-cell -fo:table-cellfo:block text-align=startSome textfo:leader leader-pattern=dots +fo:table-cellfo:block text-align=start text-align-last=justifySome textfo:leader leader-pattern=dots leader-pattern-width=8pt leader-alignment=reference-area //fo:block/fo:table-cell @@ -410,7 +410,7 @@ fo:table-row line-height=12pt fo:table-cellfo:block text-align=end C) /fo:block/fo:table-cell -fo:table-cellfo:block text-align=startTextfo:leader leader-pattern=dots +fo:table-cellfo:block text-align=start text-align-last=justifyTextfo:leader leader-pattern=dots leader-pattern-width=8pt leader-alignment=reference-area //fo:block/fo:table-cell @@ -419,7 +419,7 @@ fo:table-row line-height=12pt fo:table-cellfo:block text-align=endD) /fo:block/fo:table-cell -fo:table-cellfo:block text-align=startThis text is even longer than the first entry fo:leader leader-pattern=dots +fo:table-cellfo:block text-align=start text-align-last=justifyThis text is even longer than the first entry fo:leader leader-pattern=dots leader-pattern-width=8pt leader-alignment=reference-area //fo:block/fo:table-cell @@ -428,7 +428,7 @@ fo:table-row line-height=12pt fo:table-cellfo:block text-align=endE) /fo:block/fo:table-cell -fo:table-cellfo:block text-align=startShorter text examplefo:leader leader-pattern=dots +fo:table-cellfo:block text-align=start text-align-last=justifyShorter text examplefo:leader leader-pattern=dots leader-pattern-width=8pt leader-alignment=reference-area //fo:block/fo:table-cell - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Incorrect leaders at FOP example
On Wednesday, November 13, 2013 03:21:47 am Ognjen Blagojevic wrote: Hi, I need to create leaders for TOC. I started with researching FOP examples (examples/fo/basic/leaders.fo), but the generated PDF doesn't contain expected results. In section Table of Contents I get only one dot: A)This is some longer sample text. 1 B)Some text. 2 C)Text. 3 While I would expect to get this: A)This is some longer sample text1 B)Some text..2 C)Text...3 Are my expectations too high? Hard to say, since you didn't attach neither sample FO code, nor the resulting PDF. Leaders work for me with 1.1 on multiple Java versions, 1.6.x and 1.7.x. Here's an example fo:leader I am using: fo:leader padding-left=4pt padding-right=4pt leader-pattern=dots leader-pattern-width=3pt leader-alignment=reference-area keep-with-next.within-line=always/ Regards, Alexey. I tested with FOP 0.93, 0.95, 1.0, 1.1 and nightly 20131113 on Windows 7 64-bit, and CentOS 5.9 64-bit, and Java 1.7.0_40. -Ognjen - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Aligning an Image Caption with the Image?
Jeffrey, This is a mailing list for FOP. For questions like this, you're better off asking at docbook-a...@lists.oasis-open.org list. For control of the title appearance, including the alignment, you'd need to customize the formal.title.properties attribute set. This [1], along with a whole lot of other recipes, is described in Bob Stayton's DocBook XSL: The Complete Guide. [1] http://www.sagehill.net/docbookxsl/TitleFontSizes.html Regards, Alexey. On Monday, November 04, 2013 02:00:17 PM Jeffrey Walton wrote: Hello, When I use the following in a document: figure id=figure-nnn titleY/title mediaobject imageobject imagedata align=center fileref=xxx.png scale=NN/ /imageobject /mediaobject /figure The image is aligned center (or even aligned right) but the caption (title) remains blocked left. I've tried to put the `align` attributes on other objects, including `imageobject`, `mediaobject`, and `figure`. All result in an error. How does one align the caption with the image? Thanks in advance. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Floating an image (block right and wrap text)?
Jeffrey, FOP compliance page [1] gives the HEAD status (refer to FOP dev column). [1] http://xmlgraphics.apache.org/fop/compliance.html Alexey. On Monday, November 04, 2013 01:56:14 PM Jeffrey Walton wrote: Hello, I'm having trouble anchoring an image to the right margin and flowing text around it. I'm using FOP 1.1 and I recently learned the `floatstyle` attribute on a figure is not supported. Does anyone know if this issue is fixed in HEAD? Would anyone be willing to accept a PayPal donation in return for a timely delivery of a source code patch? I'd be happy to provide a few simple test cases. And I don't care about other object types - I just need the figure. Thanks in advance. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Right alignment of page references in TOC
Looks like this issue: https://issues.apache.org/jira/browse/FOP-1444 Regards, Alexey. On Thursday, October 24, 2013 06:39:50 PM honyk wrote: Dear All, I've encountered a weird alignment issue (FOP 1.1) when formatting TOC, see http://drifted.in/other/_toc.fo http://drifted.in/other/_toc.pdf It is partly caused by the combination of itemized lists (the second level) and blocks (the rest). Every case is almost consistent, but the right edge is different. I am writing 'almost' as there are slight fluctuations in the former group which depends on the text before the leader line. Please compare items 2.1, 2.2 (iii iii iii) and 2.3 (iii). Is there any workaround for this? Thanks, Jan - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
[PATCH] [FOP-2106] Footnote overlapping with body
Hi all,
I hope this list is still alive... as there has not been any reaction to my
previous posts.
Attached is a patch that resolves the issue for the .fo attached to FOP-2106
issue, as well as with the document where I had the issue. With that patch,
all ~60 footnotes in my document have been placed where they should've been,
without any of them going to the previous page or overlapping with the body.
The issue is that when the PageBreakingAlgorithm class backtracks to handle a
page break (via its parent, BreakingAlgorithm), it does not reset the
footnoteListIndex/footnoteElementIndex fields. As a result, in the second pass
the footnote position is not calculated properly - then first/last
element/list indexes on pagebreaks are not correct, and footnote is placed on
the page before one where it has been successfully fitted. This happens when
two conditions are met: (a) there is at least one page break inserted before
the problematic footnote, and (b) if not for the footnote, the containing
block would fit at the bottom of the previous page.
I am not sure about s/insertedFootnoteLength/totalFootnoteLength/ change in
createNode(). I haven't seen any immediate effect from this, but it looks like
the total length of all the footnotes should also reset when BreakingAlgorithm
backtracks to a previous active node. Feedback welcome.
If the patch is deemed acceptable, I could probably add a test case for that
issue.
Regards,
Alexey.Index: src/java/org/apache/fop/layoutmgr/PageBreakingAlgorithm.java
===
--- src/java/org/apache/fop/layoutmgr/PageBreakingAlgorithm.java (revision 1523182)
+++ src/java/org/apache/fop/layoutmgr/PageBreakingAlgorithm.java (working copy)
@@ -287,7 +287,7 @@
int difference, double totalDemerits, KnuthNode previous) {
return new KnuthPageNode(position, line, fitness,
totalWidth, totalStretch, totalShrink,
- insertedFootnotesLength, footnoteListIndex, footnoteElementIndex,
+ totalFootnotesLength, footnoteListIndex, footnoteElementIndex,
adjustRatio, availableShrink, availableStretch,
difference, totalDemerits, previous);
}
@@ -405,6 +405,8 @@
resetFootnotes(((KnuthBlockBox) resetElement).getElementLists());
}
}
+ footnoteElementIndex = ((KnuthPageNode) restartingNode).footnoteElementIndex;
+ footnoteListIndex = ((KnuthPageNode) restartingNode).footnoteListIndex;
}
return returnValue;
}
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: [PATCH] [FOP-2106] Footnote overlapping with body
[Moving to fop-dev] Thanks Pascal, I couldn't mark the existing Jira entry as [PATCH], as I am not the original submitter of the issue - I cannot edit the subject. I attached the diff to the issue. As to the tests - I'd like to get the patch reviewed first - if it is the right thing to do. Then I can create a minimal layout test. Regards, Alexey. On Thursday, September 19, 2013 09:11:56 AM Pascal Sancho wrote: Hi, 1st, thanks for your proposal, all contributions are welcome. Yes, this list is still alive, while activity is a little bit lower than the past. Note that for FOP internal development, there is another list, more appropriate: fop-dev (follow [1]); you are welcome there ;-). About submitting a patch, you should either open a new Jira entry, or change the existing one ([2]) to turn it into a patch entry (see [3]: submitting a patch). Adding a test case to complete the patch is a good practice, so if you can add it, this will help in the merge process. [1] http://xmlgraphics.apache.org/fop/dev/#mail-fop-dev [2] https://issues.apache.org/jira/browse/FOP-2106 [3] http://xmlgraphics.apache.org/fop/dev/#patches 2013/9/19 Alexey Neyman sti...@att.net: Hi all, I hope this list is still alive... as there has not been any reaction to my previous posts. Attached is a patch that resolves the issue for the .fo attached to FOP-2106 issue, as well as with the document where I had the issue. With that patch, all ~60 footnotes in my document have been placed where they should've been, without any of them going to the previous page or overlapping with the body. The issue is that when the PageBreakingAlgorithm class backtracks to handle a page break (via its parent, BreakingAlgorithm), it does not reset the footnoteListIndex/footnoteElementIndex fields. As a result, in the second pass the footnote position is not calculated properly - then first/last element/list indexes on pagebreaks are not correct, and footnote is placed on the page before one where it has been successfully fitted. This happens when two conditions are met: (a) there is at least one page break inserted before the problematic footnote, and (b) if not for the footnote, the containing block would fit at the bottom of the previous page. I am not sure about s/insertedFootnoteLength/totalFootnoteLength/ change in createNode(). I haven't seen any immediate effect from this, but it looks like the total length of all the footnotes should also reset when BreakingAlgorithm backtracks to a previous active node. Feedback welcome. If the patch is deemed acceptable, I could probably add a test case for that issue. Regards, Alexey. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Footnotes overlapping body [FOP-2106]
I further reduced the test case to just 4 fo:block elements, one with a footnote; attached. I did some initial debugging, and what I see is that if I remove the first two fo:block elements in the source file, the footnote is rendered properly (see without- page-1.pdf) - even though the content on page 2 does not change. This leads me to think that the PageBreakingAlgorithm.restartFrom() is not resetting the context correctly when it introduces a page break point after the 1st page. I am currently at my end of my knowledge about FOP's internals. Is there anybody here that could offer some pointers where to look, or am I talking to myself on this list? Regards, Alexey. On Saturday, September 14, 2013 11:53:09 PM Alexey Neyman wrote: Hi, If someone would be interested in looking into this, I've reduced the test case to much smaller FO file - 29 lines, 3 pages in the generated PDF. Attached to this email. Regards, Alexey. On Friday, September 13, 2013 03:23:35 PM Alexey Neyman wrote: Hi FOP developers, I am hitting the issue described in FOP issue 2106 [1]. I tried the workaround mentioned in that issue (remove line-height-shift-adjustment from fo:root) and while it helped the test FO attached to that issue, it didn't make any effect on the document I have. I am also seeing other manifestations of the same issue - where a footnote is placed on the page before it is referenced, even though in other cases there is sufficient space at the bottom of the page to accommodate that footnote. As far as I see, it always happens when the reference to that footnote is placed on the first line of the page. This is probably why the workaround in [1] worked for the bad-footnote.fo attached to that issue, as without line-height-shift-adjustment the reference to that footnote moves from the first line of the page down. Any pointers as to what may be causing that issue and/or workarounds would be appreciated. [1] https://issues.apache.org/jira/browse/FOP-2106 Regards, Alexey. ?xml version=1.0? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; font-family=serif,Symbol,ZapfDingbats font-size=10pt text-align=justify fo:layout-master-set fo:simple-page-master master-name=pm page-width=100pt page-height=100pt fo:region-body column-count=1/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=pm fo:static-content flow-name=xsl-footnote-separator fo:block fo:leader color=black leader-pattern=rule leader-length=100pt/ /fo:block /fo:static-content fo:flow flow-name=xsl-region-body fo:block-container height=56pt background-color=red fo:block/ /fo:block-container fo:blockA line/fo:block fo:blockHere is some textfo:footnotefo:inline font-size=75% baseline-shift=superX/fo:inlinefo:footnote-bodyfo:blockA/fo:blockfo:blockB/fo:block/fo:footnote-body/fo:footnote with a footnote. We will see how it is formatted./fo:block /fo:flow /fo:page-sequence /fo:root a.pdf Description: Adobe PDF document without-page-1.pdf Description: Adobe PDF document - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Footnotes overlapping body [FOP-2106]
Oops, attached the wrong FO file. Here is the right one, with PDF output. Regards, Alexey. On Monday, September 16, 2013 12:11:55 AM Alexey Neyman wrote: I further reduced the test case to just 4 fo:block elements, one with a footnote; attached. I did some initial debugging, and what I see is that if I remove the first two fo:block elements in the source file, the footnote is rendered properly (see without- page-1.pdf) - even though the content on page 2 does not change. This leads me to think that the PageBreakingAlgorithm.restartFrom() is not resetting the context correctly when it introduces a page break point after the 1st page. I am currently at my end of my knowledge about FOP's internals. Is there anybody here that could offer some pointers where to look, or am I talking to myself on this list? Regards, Alexey. On Saturday, September 14, 2013 11:53:09 PM Alexey Neyman wrote: Hi, If someone would be interested in looking into this, I've reduced the test case to much smaller FO file - 29 lines, 3 pages in the generated PDF. Attached to this email. Regards, Alexey. On Friday, September 13, 2013 03:23:35 PM Alexey Neyman wrote: Hi FOP developers, I am hitting the issue described in FOP issue 2106 [1]. I tried the workaround mentioned in that issue (remove line-height-shift-adjustment from fo:root) and while it helped the test FO attached to that issue, it didn't make any effect on the document I have. I am also seeing other manifestations of the same issue - where a footnote is placed on the page before it is referenced, even though in other cases there is sufficient space at the bottom of the page to accommodate that footnote. As far as I see, it always happens when the reference to that footnote is placed on the first line of the page. This is probably why the workaround in [1] worked for the bad-footnote.fo attached to that issue, as without line-height-shift-adjustment the reference to that footnote moves from the first line of the page down. Any pointers as to what may be causing that issue and/or workarounds would be appreciated. [1] https://issues.apache.org/jira/browse/FOP-2106 Regards, Alexey. ?xml version=1.0? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; font-family=serif font-size=10pt fo:layout-master-set fo:simple-page-master master-name=body page-width=100pt page-height=35pt fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=body fo:flow flow-name=xsl-region-body fo:block space-before.optimum=1em space-before.minimum=0.8em space-before.maximum=1.2empublisher./fo:block fo:block space-before.optimum=1em space-before.minimum=0.8em space-before.maximum=1.2emaccess content./fo:block fo:block space-before.optimum=1em space-before.minimum=0.8em space-before.maximum=1.2emare harmed./fo:block fo:block space-before.optimum=1em space-before.minimum=0.8em space-before.maximum=1.2emWilliam Fisher.fo:footnotefo:inline baseline-shift=super font-size=50%11/fo:inlinefo:footnote-bodyfo:block font-size=6ptThis footnote is on a page before its inline reference./fo:block/fo:footnote-body/fo:footnote/fo:block /fo:flow /fo:page-sequence /fo:root a.pdf Description: Adobe PDF document - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Footnotes overlapping body [FOP-2106]
Hi, If someone would be interested in looking into this, I've reduced the test case to much smaller FO file - 29 lines, 3 pages in the generated PDF. Attached to this email. Regards, Alexey. On Friday, September 13, 2013 03:23:35 PM Alexey Neyman wrote: Hi FOP developers, I am hitting the issue described in FOP issue 2106 [1]. I tried the workaround mentioned in that issue (remove line-height-shift-adjustment from fo:root) and while it helped the test FO attached to that issue, it didn't make any effect on the document I have. I am also seeing other manifestations of the same issue - where a footnote is placed on the page before it is referenced, even though in other cases there is sufficient space at the bottom of the page to accommodate that footnote. As far as I see, it always happens when the reference to that footnote is placed on the first line of the page. This is probably why the workaround in [1] worked for the bad-footnote.fo attached to that issue, as without line-height-shift-adjustment the reference to that footnote moves from the first line of the page down. Any pointers as to what may be causing that issue and/or workarounds would be appreciated. [1] https://issues.apache.org/jira/browse/FOP-2106 Regards, Alexey. ?xml version=1.0? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; font-family=serif font-size=10pt text-align=justify line-height=normal font-selection-strategy=character-by-character fo:layout-master-set fo:simple-page-master master-name=body page-width=148mm page-height=210mm margin-top=0.5in margin-bottom=0.5in margin-left=1in margin-right=1in fo:region-body margin-bottom=0.5in margin-top=0.5in column-gap=12pt column-count=1/ fo:region-before region-name=xsl-region-before-odd extent=0.4in/ fo:region-after region-name=xsl-region-after-odd extent=0.4in/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=body language=en fo:static-content flow-name=xsl-footnote-separator fo:block fo:leader color=black leader-pattern=rule leader-length=1in/ /fo:block /fo:static-content fo:flow flow-name=xsl-region-body start-indent=4pc end-indent=0pt fo:block space-before.optimum=1em space-before.minimum=0.8em space-before.maximum=1.2embe to facilitate the access to this content, ideally in a way that returns something to the artist./fo:block fo:block space-before.optimum=1em space-before.minimum=0.8em space-before.maximum=1.2emAgain, the model here is the used book store. Once a book goes out of print, it may still be available in libraries and used book stores. But libraries and used book stores don't pay the copyright owner when someone reads or buys an out-of-print book. That makes total sense, of course, since any other system would be so burdensome as to eliminate the possibility of used book stores' existing. But from the author's perspective, this sharing of his content without his being compensated is less than ideal./fo:block fo:block space-before.optimum=1em space-before.minimum=0.8em space-before.maximum=1.2emThe model of used book stores suggests that the law could simply deem out-of-print music fair game. If the publisher does not make copies of the music available for sale, then commercial and noncommercial providers would be free, under this rule, to share that content, even though the sharing involved making a copy. The copy here would be incidental to the trade; in a context where commercial publishing has ended, trading music should be as free as trading books./fo:block fo:block space-before.optimum=1em space-before.minimum=0.8em space-before.maximum=1.2emAlternatively, the law could create a statutory license that would ensure that artists get something from the trade of their work. For example, if the law set a low statutory rate for the commercial sharing of content that was not offered for sale by a commercial publisher, and if that rate were automatically transferred to a trust for the benefit of the artist, then businesses could develop around the idea of trading this content, and artists would benefit from this trade./fo:block fo:block space-before.optimum=1em space-before.minimum=0.8em space-before.maximum=1.2emThis system would also create an incentive for publishers to keep works available commercially. Works that are available commercially would not be subject to this license. Thus, publishers could protect the right to charge whatever they want for content if they kept the work commercially available. But if they don't keep it available, and instead, the computer hard disks of fans around the world keep it alive, then any royalty owed for such copying should be much less than the amount owed a commercial publisher./fo:block fo:block space-before.optimum=1em space-before.minimum=0.8em space-before.maximum=1.2emThe hard case is content of types A and B, and again, this case is hard only because the extent
Footnotes overlapping body [FOP-2106]
Hi FOP developers, I am hitting the issue described in FOP issue 2106 [1]. I tried the workaround mentioned in that issue (remove line-height-shift-adjustment from fo:root) and while it helped the test FO attached to that issue, it didn't make any effect on the document I have. I am also seeing other manifestations of the same issue - where a footnote is placed on the page before it is referenced, even though in other cases there is sufficient space at the bottom of the page to accommodate that footnote. As far as I see, it always happens when the reference to that footnote is placed on the first line of the page. This is probably why the workaround in [1] worked for the bad-footnote.fo attached to that issue, as without line-height-shift-adjustment the reference to that footnote moves from the first line of the page down. Any pointers as to what may be causing that issue and/or workarounds would be appreciated. [1] https://issues.apache.org/jira/browse/FOP-2106 Regards, Alexey.
Re: fo:leader inconsistent alignment (fop 1.1 regression)
Thanks! Our stylesheets indeed added one space before and after fo:leader, to
separate it from the title and page numbers. Converting that to
padding-{left,right} properties on fo:leader solved the misalignment issue.
Just out of curiosity, was the misalignment caused by a stricter
interpretation of XSL-FO specification by FOP 1.1, or is it a bug in FOP that
can be worked around by not using whitespace before/after fo:leader?
Regards,
Alexey.
On Tuesday, April 02, 2013 05:22:32 am Pascal Sancho wrote:
Hi,
Behavior is related to xml blanks (white-space, line-feed, etc.) that are
before or after fo:inline tags.
You should avoid to use fo:inline when it is not required (replacing it
with fo:wrapper when it is just used as properties carrier), or avoid to
get extra blanks in your resulting xsl-fo.
The latter can be done by surrending all constant strings with xsl:text
element in XSLT.
2013/3/31 Alexey Neyman sti...@att.net
**
Hi all,
I've noticed that since the upgrade from FOP 1.0 to FOP 1.1, the page
numbers in the Table of Contents are misaligned. Attached is XSL-FO
input, and two PDFs, produced by FOP 1.0 and FOP 1.1.
Also attached are a couple of images, magnified screenshot of the
resulting PDFs with a vertical line close to the page numbers to show
misalignment more clearly.
Could you please have a look at what's causing this misalignment?
Thanks,
Alexey.
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Change bars support in FOP?
Thanks. That issue does not have any further comments/changes than the one in Bugzilla, though. Regards, Alexey. On Monday, March 11, 2013 01:24:20 am Pascal Sancho wrote: Hi, Just for convenience, you should monitor the corresponding issue in Jira: https://issues.apache.org/jira/browse/FOP-1760 Bugzilla Fop issues became read-only when we migrated them to Jira. 2013/3/10 Alexey Neyman sti...@att.net Hi, Are there any plans to implement change bars in FOP? I found the bug in JIRA that claims to implement that: https://issues.apache.org/bugzilla/show_bug.cgi?id=48548 It is in NEEDSINFO state for almost a year now, even though the author has updated the patch and (presumably) addressed the review feedback on the previous version of the patch (which is why it was switched to NEEDSINFO, as far as I understand). Is this patch going to be integrated? Regards, Alexey. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Change bars support in FOP?
Hi, Are there any plans to implement change bars in FOP? I found the bug in JIRA that claims to implement that: https://issues.apache.org/bugzilla/show_bug.cgi?id=48548 It is in NEEDSINFO state for almost a year now, even though the author has updated the patch and (presumably) addressed the review feedback on the previous version of the patch (which is why it was switched to NEEDSINFO, as far as I understand). Is this patch going to be integrated? Regards,Alexey.
Re: fop-ttfreader - output bounding box information for characters?
Hi Chris, On Tuesday, January 08, 2013 12:10:36 am Chris Bowditch wrote: Sounds like we need a FOP plug-in for pMML2SVG to replace the ageing JEuclid one. Pardon my ignorance, but what is FOP using for the XSL transformation? Is it Xalan-based? In that case, it probably won't be sufficient: pMML2SVG requires XSLT 2.0, which, as far as I understand, is only supported by Saxon. You can use whichever XSLT processor you choose with FOP, as long as you feed FOP with XSL-FO. I know that; you mentioned *plug-in* pMML2SVG - I assumed, plug-in is something to be integrated into FOP - which is why I asked what FOP uses for XSLT. Regards, Alexey. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: fop-ttfreader - output bounding box information for characters?
Hi Chris, On Monday, January 07, 2013 11:44:46 AM Chris Bowditch wrote: Patch from pMML2SVG, slightly modified to apply to FOP 1.1 sources, attached. Thanks for the patch. To get this added to the code base please raise an issue in JIRA, add the diff as an attachment and include [PATCH] in the subject line. A committer will then review the patch before applying it. Created an issue: https://issues.apache.org/jira/browse/FOP-2180 Thank you. So, can this patch be reviewed/integrated? I know Peter Hancock is looking into doing something similar as he is working on getting Batik to use FOP configured fonts instead of the system ones. Peter mentioned to me offlist that he was going to need to expose a few extra things in TTFReader to facilitate this, could be you are covering similar ground here. Maybe. Then again, the root of the issue is not Batik - that issue I work around by embedding fonts. It is JEuclid's use of system fonts which is why I am switching to pMML2SVG - which needs bounding box information for glyphs. BTW, another useful feature in pMML2SVG that was not available in JEuclid is that pMML2SVG outputs baseline position information in the generated SVG - so that inline equations can be properly positioned on the line. Sounds like we need a FOP plug-in for pMML2SVG to replace the ageing JEuclid one. Pardon my ignorance, but what is FOP using for the XSL transformation? Is it Xalan-based? In that case, it probably won't be sufficient: pMML2SVG requires XSLT 2.0, which, as far as I understand, is only supported by Saxon. Regards, Alexey.
Re: fop-ttfreader - output bounding box information for characters?
Hi Chris, On Friday, January 04, 2013 06:50:30 am Chris Bowditch wrote: Hi Alexey, Apologies for the slow reply. I'm just catching up on e-mail after the holidays. No problem and Happy New Year! On 28/12/2012 05:56, Alexey Neyman wrote: Hi all, As I mentioned in another email, I am trying to constrain FOP to use only local fonts (i.e. ones described in fop.cfg). For SVGs, I have a workaround: - Generate fonts in SVG format using ttf2svg utility from Batik; - Use an XSL stylesheet to embed all the fonts used by an SVG image into the image itself; - Use such preprocessed SVG image as the input to FOP. Interesting workaround. We are trying to tackle this issue by providing an alternative implementation of GVTFont in Batik that uses FOP's Font Library to load the font metrics. First, as I was told on the list previously, it is not a small feat and it would take some time before this fix is released. Then, even though it would solve the issue for SVGs, it won't help with font selection for MathML. As I explained below, JEuclid pre-renders the glyphs into paths. And as far as I can tell, JEuclid project is all but dead: the last non- trivial commit was 16 months ago, and the last release 30 months ago. I don't think it is likely JEuclid will catch up with FOP improvements, even when they're available. This does not work well with JEuclid, though. When JEuclid generates SVG from MathML, it performs font rendering - that is, replaces characters by actual paths. And again, it uses system fonts, not the fonts available in FOP - even if running as FOP plugin. To work around this issue for MathML, I am currently switching from JEuclid to pMML2SVG (http://pmml2svg.sourceforge.net). It generates SVGs with text characters, not paths. But in order to do so, it needs font metrics. Unfortunately, font metrics produced by stock FOP TTFReader are not sufficient - this stylesheet also needs bounding box for each glyph. To obtain these, pMML2SVG currently packages an augmented TTFReader Java sources which are to be compiled and used in lieu of the stock one. Given that the patch is very small and as far as I can tell, compatible with current users of font metrics (it just adds 4 attributes to glyph description), is it possible to integrate this support into stock FOP? Patch from pMML2SVG, slightly modified to apply to FOP 1.1 sources, attached. Thanks for the patch. To get this added to the code base please raise an issue in JIRA, add the diff as an attachment and include [PATCH] in the subject line. A committer will then review the patch before applying it. Created an issue: https://issues.apache.org/jira/browse/FOP-2180 I know Peter Hancock is looking into doing something similar as he is working on getting Batik to use FOP configured fonts instead of the system ones. Peter mentioned to me offlist that he was going to need to expose a few extra things in TTFReader to facilitate this, could be you are covering similar ground here. Maybe. Then again, the root of the issue is not Batik - that issue I work around by embedding fonts. It is JEuclid's use of system fonts which is why I am switching to pMML2SVG - which needs bounding box information for glyphs. BTW, another useful feature in pMML2SVG that was not available in JEuclid is that pMML2SVG outputs baseline position information in the generated SVG - so that inline equations can be properly positioned on the line. Regards, Alexey. Anyway, please raise the JIRA issue otherwise your patch could get lost. Thanks, Chris Regards, Alexey. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
fop-ttfreader - output bounding box information for characters?
Hi all,
As I mentioned in another email, I am trying to constrain FOP to use only
local fonts (i.e. ones described in fop.cfg). For SVGs, I have a workaround:
- Generate fonts in SVG format using ttf2svg utility from Batik;
- Use an XSL stylesheet to embed all the fonts used by an SVG image into the
image itself;
- Use such preprocessed SVG image as the input to FOP.
This does not work well with JEuclid, though. When JEuclid generates SVG from
MathML, it performs font rendering - that is, replaces characters by actual
paths. And again, it uses system fonts, not the fonts available in FOP - even
if running as FOP plugin.
To work around this issue for MathML, I am currently switching from JEuclid to
pMML2SVG (http://pmml2svg.sourceforge.net). It generates SVGs with text
characters, not paths. But in order to do so, it needs font metrics.
Unfortunately, font metrics produced by stock FOP TTFReader are not sufficient
- this stylesheet also needs bounding box for each glyph. To obtain these,
pMML2SVG currently packages an augmented TTFReader Java sources which are to
be compiled and used in lieu of the stock one.
Given that the patch is very small and as far as I can tell, compatible with
current users of font metrics (it just adds 4 attributes to glyph
description), is it possible to integrate this support into stock FOP?
Patch from pMML2SVG, slightly modified to apply to FOP 1.1 sources, attached.
Regards,
Alexey.diff -urpN fop-1.1/src/java/org/apache/fop/fonts/apps/TTFReader.java fop-1.1-modified/src/java/org/apache/fop/fonts/apps/TTFReader.java
--- fop-1.1/src/java/org/apache/fop/fonts/apps/TTFReader.java 2012-10-16 22:47:36.0 -0700
+++ fop-1.1-modified/src/java/org/apache/fop/fonts/apps/TTFReader.java 2012-12-27 11:45:33.775793336 -0800
@@ -401,6 +401,12 @@ public class TTFReader extends AbstractF
for (int i = 0; i wx.length; i++) {
Element wxel = doc.createElement(wx);
wxel.setAttribute(w, String.valueOf(wx[i]));
+// Add bounding box
+int[] bbox = ttf.getBBox(i);
+wxel.setAttribute(xMin, String.valueOf(bbox[0]));
+wxel.setAttribute(yMin, String.valueOf(bbox[1]));
+wxel.setAttribute(xMax, String.valueOf(bbox[2]));
+wxel.setAttribute(yMax, String.valueOf(bbox[3]));
el.appendChild(wxel);
}
}
diff -urpN fop-1.1/src/java/org/apache/fop/fonts/truetype/TTFFile.java fop-1.1-modified/src/java/org/apache/fop/fonts/truetype/TTFFile.java
--- fop-1.1/src/java/org/apache/fop/fonts/truetype/TTFFile.java 2012-10-16 22:47:36.0 -0700
+++ fop-1.1-modified/src/java/org/apache/fop/fonts/truetype/TTFFile.java 2012-12-27 11:48:51.371903307 -0800
@@ -978,6 +978,20 @@ public class TTFFile {
}
/**
+ * Returns an array of (xMin,yMin,xMax,yMax) for a glyph.
+ * @return int[] Array defining bounding box.
+ */
+public int[] getBBox(int id) {
+ int[] bbox = new int[4];
+
+ for (int i = 0; i 4; i++) {
+ bbox[i] = (int)convertTTFUnit2PDFUnit(mtxTab[id].getBoundingBox()[i]);
+ }
+
+ return bbox;
+}
+
+/**
* Returns the width of a given character.
* @param idx Index of the character
* @return int Standard width
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: How to find out why fop needs a certain font?
Hi Chris, On Friday, December 21, 2012 03:50:43 am Chris Bowditch wrote: Hi Alexey, On 21/12/2012 03:07, Alexey Neyman wrote: Yes, I want to understand how FOP treats the fonts in SVG (and, if you know that, how fonts are selected in embedded MathML via JEuclid plugin - we use that, too). We've had some font discrepancies in the past depending on the fonts installed on each developer's machine (in part, because some of the authors are on Windows machines and some are on Linux - so they're likely to have different fonts). Thus, we've decided to do away with using system fonts and use only local fonts (i.e. fonts checked out from the repository along with the document sources). Understood. We have similar challenges too. On Thursday, December 20, 2012 03:32:04 pm Luis Bernardo wrote: With SVG, fonts are more complicated. The font used in the SVG needs to be installed in the system and needs to be configured in fop.xconf too. The warning you got usually happens when the font is in the system but not configured in fop.xconf, which looking at your example does not seem to be the case... Are you saying that the font used in SVG needs to be present both as a system font, even if it is listed in fop.conf? What is FOP going to use then, system font or local font? If it is using system font, that's more than disturbing. As I mentioned, this completely prevents setting up a controlled environment with known fonts. yes that is true. Just to be clear, this is a limitation of Batik, not FOP. Batik uses the AWT Font system as mentioned by Mehdi and Pascal. Peter is researching the possibility of changing Batik so that it can use fonts defined in fop.xconf, but that is a long term project with no quick fix. A couple more questions: 1. do you know if Batik would still use system font if there's an embedded font in the SVG? E.g., svg defs font font-face font-family=Times New Roman font-weight=normal font-style=normal glyph .../ ... /font-face /font /defs text font-family='Times New Roman' font-weight=normal font-style=normalSomething/text /svg Will Batik use system font in this example? 2. Do you know how fonts are selected by JEuclid plugin for FOP (which handles MathML)? Is it also using system fonts? Regards, Alexey. Thanks, Chris If you want to get to the bottom of the matter please indicate what version of fop you are using and what OS. FOP 1.1, Linux (RedHat Enterprise, 6.2). Also, the use of metrics-url is not needed anymore (and is not recommended) so you can remove that. I tried, it didn't have any effect on the warning. I see you refer to the font file TimesNewRoman.ttf without specifying a font-base path (which only works if you have the file in the same directory you have your *.fo file). I made it so for this reduced test case. Originally, it was embed- url=../fonts/TimesNewRoman.ttf - as I mentioned above, we want to have a controlled font environment. Is that font file an exact copy of the installed font in the system of the same name? The machine does not have a 'Times New Roman' system font (it's a Linux machine, it comes with a different set of system fonts by default). But why would FOP need a system font if it has the required font specified in the configuration file? Another question is, would embedding fonts in SVGs prevent FOP from using system fonts? Regards, Alexey. On 12/20/12 6:44 PM, Alexey Neyman wrote: Hi Luis, No, it is not the case. In the FO I am using, fo:root has a font-family specified, and that font family is described in the fop.cfg. Actually, I traced this warning down to the watermark image specified for the background. However, that SVG does not refer to 'Serif' font, either. Can somebody please explain how does FOP treat the fonts in the included SVG files? I even tried to add a substitution from font-family=Serif to font- family=Times New Roman, it did not help either. Here is the reduced FO file that exhibits the issue: [[[ ?xml version=1.0? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; font-family=Times New Roman fo:layout-master-set fo:simple-page-master master-name=draft fo:region-body background-image=url(draft.svg)/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=draft fo:flow flow-name=xsl-region-body fo:block/ /fo:flow /fo:page-sequence /fo:root ]]] And here is the draft.svg: [[[ ?xml version=1.0 encoding=UTF-8 standalone=no? svg xmlns=http://www.w3.org/2000/svg; viewBox=80 80 600 600 version=1.1 width=5in height=5in text font-weight=normal xml:space=preserve
Re: How to find out why fop needs a certain font?
Hi Luis, No, it is not the case. In the FO I am using, fo:root has a font-family specified, and that font family is described in the fop.cfg. Actually, I traced this warning down to the watermark image specified for the background. However, that SVG does not refer to 'Serif' font, either. Can somebody please explain how does FOP treat the fonts in the included SVG files? I even tried to add a substitution from font-family=Serif to font- family=Times New Roman, it did not help either. Here is the reduced FO file that exhibits the issue: [[[ ?xml version=1.0? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; font-family=Times New Roman fo:layout-master-set fo:simple-page-master master-name=draft fo:region-body background-image=url(draft.svg)/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=draft fo:flow flow-name=xsl-region-body fo:block/ /fo:flow /fo:page-sequence /fo:root ]]] And here is the draft.svg: [[[ ?xml version=1.0 encoding=UTF-8 standalone=no? svg xmlns=http://www.w3.org/2000/svg; viewBox=80 80 600 600 version=1.1 width=5in height=5in text font-weight=normal xml:space=preserve transform=matrix(0.70710678,-0.70710678,0.70710678,0.70710678,0,0) font-size=250px y=640 x=-315 font-family='Times New Roman' fill=#f2f2f2Draft/text /svg ]]] And fop.cfg: [[[ ?xml version=1.0? fop version=1.0 renderers renderer mime=application/pdf fonts font kerning=yes metrics-url=TimesNewRoman.metric embed- url=TimesNewRoman.ttf font-triplet name=Times New Roman weight=normal style=normal/ /font /fonts /renderer /renderers /fop ]]] Regards, Alexey. On Wednesday, December 19, 2012 04:45:31 pm Luis Bernardo wrote: This is of no consequence although is it puzzling at first. If you specify a global font-family in the fo root element I think the warning goes away. I think what you are seeing has been discussed here: http://apache-fop.1065347.n5.nabble.com/ZapfDingbats-and-Symbol-not-found-w hereas-they-are-not-needed-td31330.html On 12/19/12 11:05 PM, Alexey Neyman wrote: Hi all, I see the following warning message reported by FOP: $ fop -c fop.cfg -dpi 150 apiguide.fo apiguide.pdf Dec 19, 2012 2:59:02 PM org.apache.fop.events.LoggingEventListener processEvent WARNING: Font Serif,normal,400 not found. Substituting with any,normal,400. ... However, apiguide.fo does not contain any references to 'serif' font: $ grep -i serif apiguide.fo $ Why does FOP need 'Serif' font? Is there some built-in expectation that 'Serif' font must be always available? Regards, Alexey. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: How to find out why fop needs a certain font?
Yes, I want to understand how FOP treats the fonts in SVG (and, if you know that, how fonts are selected in embedded MathML via JEuclid plugin - we use that, too). We've had some font discrepancies in the past depending on the fonts installed on each developer's machine (in part, because some of the authors are on Windows machines and some are on Linux - so they're likely to have different fonts). Thus, we've decided to do away with using system fonts and use only local fonts (i.e. fonts checked out from the repository along with the document sources). On Thursday, December 20, 2012 03:32:04 pm Luis Bernardo wrote: With SVG, fonts are more complicated. The font used in the SVG needs to be installed in the system and needs to be configured in fop.xconf too. The warning you got usually happens when the font is in the system but not configured in fop.xconf, which looking at your example does not seem to be the case... Are you saying that the font used in SVG needs to be present both as a system font, even if it is listed in fop.conf? What is FOP going to use then, system font or local font? If it is using system font, that's more than disturbing. As I mentioned, this completely prevents setting up a controlled environment with known fonts. If you want to get to the bottom of the matter please indicate what version of fop you are using and what OS. FOP 1.1, Linux (RedHat Enterprise, 6.2). Also, the use of metrics-url is not needed anymore (and is not recommended) so you can remove that. I tried, it didn't have any effect on the warning. I see you refer to the font file TimesNewRoman.ttf without specifying a font-base path (which only works if you have the file in the same directory you have your *.fo file). I made it so for this reduced test case. Originally, it was embed- url=../fonts/TimesNewRoman.ttf - as I mentioned above, we want to have a controlled font environment. Is that font file an exact copy of the installed font in the system of the same name? The machine does not have a 'Times New Roman' system font (it's a Linux machine, it comes with a different set of system fonts by default). But why would FOP need a system font if it has the required font specified in the configuration file? Another question is, would embedding fonts in SVGs prevent FOP from using system fonts? Regards, Alexey. On 12/20/12 6:44 PM, Alexey Neyman wrote: Hi Luis, No, it is not the case. In the FO I am using, fo:root has a font-family specified, and that font family is described in the fop.cfg. Actually, I traced this warning down to the watermark image specified for the background. However, that SVG does not refer to 'Serif' font, either. Can somebody please explain how does FOP treat the fonts in the included SVG files? I even tried to add a substitution from font-family=Serif to font- family=Times New Roman, it did not help either. Here is the reduced FO file that exhibits the issue: [[[ ?xml version=1.0? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; font-family=Times New Roman fo:layout-master-set fo:simple-page-master master-name=draft fo:region-body background-image=url(draft.svg)/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=draft fo:flow flow-name=xsl-region-body fo:block/ /fo:flow /fo:page-sequence /fo:root ]]] And here is the draft.svg: [[[ ?xml version=1.0 encoding=UTF-8 standalone=no? svg xmlns=http://www.w3.org/2000/svg; viewBox=80 80 600 600 version=1.1 width=5in height=5in text font-weight=normal xml:space=preserve transform=matrix(0.70710678,-0.70710678,0.70710678,0.70710678,0,0) font-size=250px y=640 x=-315 font-family='Times New Roman' fill=#f2f2f2Draft/text /svg ]]] And fop.cfg: [[[ ?xml version=1.0? fop version=1.0 renderers renderer mime=application/pdf fonts font kerning=yes metrics-url=TimesNewRoman.metric embed- url=TimesNewRoman.ttf font-triplet name=Times New Roman weight=normal style=normal/ /font /fonts /renderer /renderers /fop ]]] Regards, Alexey. On Wednesday, December 19, 2012 04:45:31 pm Luis Bernardo wrote: This is of no consequence although is it puzzling at first. If you specify a global font-family in the fo root element I think the warning goes away. I think what you are seeing has been discussed here: http://apache-fop.1065347.n5.nabble.com/ZapfDingbats-and-Symbol-not-foun d-w hereas-they-are-not-needed-td31330.html On 12/19/12 11:05 PM, Alexey Neyman wrote: Hi all, I see the following warning message reported by FOP: $ fop -c fop.cfg -dpi 150 apiguide.fo
How to find out why fop needs a certain font?
Hi all, I see the following warning message reported by FOP: $ fop -c fop.cfg -dpi 150 apiguide.fo apiguide.pdf Dec 19, 2012 2:59:02 PM org.apache.fop.events.LoggingEventListener processEvent WARNING: Font Serif,normal,400 not found. Substituting with any,normal,400. ... However, apiguide.fo does not contain any references to 'serif' font: $ grep -i serif apiguide.fo $ Why does FOP need 'Serif' font? Is there some built-in expectation that 'Serif' font must be always available? Regards, Alexey. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
FOP 0.95 exception
Hi All, I got the following crash dump from FOP 0.95 when using fo:list-block inside fo:table-cell: java.lang.ClassCastException: org.apache.fop.layoutmgr.SpaceElement cannot be cast to org.apache.fop.layoutmgr.KnuthElement It has to do something with widow-content-limit FOP extension. If I remove either fox:widow-content-limit attribute from fo:table, or space-before attribute from fo:list-item, there is no exception. Minimal testcase and full stacktrace attached. Regards, Alexey. ?xml version=1.0? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=bodyfo:region-body//fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=body fo:flow flow-name=xsl-region-body fo:table xmlns:fox=http://xmlgraphics.apache.org/fop/extensions; fox:widow-content-limit=3em fo:table-body fo:table-row fo:table-cell fo:list-block fo:list-item space-before=0.5em fo:list-item-labelfo:block//fo:list-item-label fo:list-item-bodyfo:block//fo:list-item-body /fo:list-item /fo:list-block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:flow /fo:page-sequence /fo:root java.lang.ClassCastException: org.apache.fop.layoutmgr.SpaceElement cannot be cast to org.apache.fop.layoutmgr.KnuthElement at org.apache.fop.layoutmgr.ElementListUtils.removeLegalBreaks(ElementListUtils.java:82) at org.apache.fop.layoutmgr.list.ListBlockLayoutManager.getNextKnuthElements(ListBlockLayoutManager.java:124) at org.apache.fop.layoutmgr.table.TableCellLayoutManager.getNextKnuthElements(TableCellLayoutManager.java:170) at org.apache.fop.layoutmgr.table.RowGroupLayoutManager.createElementsForRowGroup(RowGroupLayoutManager.java:120) at org.apache.fop.layoutmgr.table.RowGroupLayoutManager.getNextKnuthElements(RowGroupLayoutManager.java:60) at org.apache.fop.layoutmgr.table.TableContentLayoutManager.getKnuthElementsForRowIterator(TableContentLayoutManager.java:220) at org.apache.fop.layoutmgr.table.TableContentLayoutManager.getNextKnuthElements(TableContentLayoutManager.java:172) at org.apache.fop.layoutmgr.table.TableLayoutManager.getNextKnuthElements(TableLayoutManager.java:247) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:107) at org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:145) at org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:552) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:137) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:302) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:264) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:106) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:234) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:123) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:340) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:169) at org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1102) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:485) at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:214) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:125) at org.apache.fop.cli.Main.startFOP(Main.java:166) at org.apache.fop.cli.Main.main(Main.java:197) - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 - bug with tables?
Hi Pascal, So, is height property supported on fo:table-row by FOP? FOP compliance page says yes (not partial) on height support, and XSL-FO specification says this property is applicable to fo:table-row. Yet, I cannot get it to work. Am I doing something wrong? Regards, Alexey. On Wednesday, September 15, 2010 10:08:29 am Alexey Neyman wrote: Hi Pascal, Just tried. While there is no exception, fo:table-row min-height=1em still does not work in FOP 1.0 (still no effect whatsoever). See quoted email as to why fo:table-cell height=... is not sufficient to solve this issue. Regards, Alexey. On Wednesday, September 15, 2010 12:35:00 am Pascal Sancho wrote: Hi Alexey this Exception issue seems to be fixed in FOP 1.0 (I've noticed in the pdf attached to your initial post that you used FOP 0.95). I suggest you to upgrade, at least min-height will work as expected without any Exception. Pascal Le 14/09/2010 22:10, Alexey Neyman a écrit : Hi Pascal, I see your point, although this advice is not particularly useful to what I am doing. As I mentioned, this table is generated by DocBook, and its templates for tables are probably the most convoluted in the whole stylesheet. I was trying to avoid heavy customizations of these templates. Another issue is that what I really want is min-height property in this case: at XSLT stage, it is not known whether text inside the table cell will occupy 1, 2, 3 or 15 rows. I tried using min-height in the test case I posted before, but this causes an exception in FOP (see below). According to spec, using min-height is perfectly legal: it should set minimum height, while retaining optimum and maximum height as auto. An finally, what you suggested won't work if another cell is more than 1 row. With the example I posted: AB AC DC If I set height to 2em, it looks okay. But, if cell B contains a text that wraps into 2nd line, the table again looks as AB DC but now the whole row containing C and D cells is 2em in height. Given that DocBook stylesheet does not know how many lines of text there will be in each cell - that is determined by FO processor - I cannot calculate the height value beforehand. So, I tried to set height/min-height on a fo:table-row instead. Setting min-height= on fo:table-row results in a different exception (also, see below). Setting height= on fo:table-row does not have any effect at all. According to XSL-FO spec, block-progression-dimension property (that is set through height property) is allowed on fo:table-row. Is this a FOP bug/missing feature? Regards, Alexey. Exception with min-height= on fo:table-cell: 8-8-8-8-8-8-8 Sep 14, 2010 12:37:47 PM org.apache.fop.cli.Main startFOP SEVERE: Exception java.lang.NullPointerException at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:2 1 7) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:125) at org.apache.fop.cli.Main.startFOP(Main.java:166) at org.apache.fop.cli.Main.main(Main.java:197) Caused by: java.lang.NullPointerException at org.apache.fop.layoutmgr.table.RowGroupLayoutManager.computeRowHeights( Ro wGroupLayoutManager.java:165) at org.apache.fop.layoutmgr.table.RowGroupLayoutManager.createElementsForR ow Group(RowGroupLayoutManager.java:127) at org.apache.fop.layoutmgr.table.RowGroupLayoutManager.getNextKnuthElemen ts (RowGroupLayoutManager.java:60) at org.apache.fop.layoutmgr.table.TableContentLayoutManager.getKnuthElemen ts ForRowIterator(TableContentLayoutManager.java:220) at org.apache.fop.layoutmgr.table.TableContentLayoutManager.getNextKnuthEl em ents(TableContentLayoutManager.java:172) at org.apache.fop.layoutmgr.table.TableLayoutManager.getNextKnuthElements( Ta bleLayoutManager.java:247) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElement s( BlockStackingLayoutManager.java:294) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockL ay outManager.java:116) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLay ou tManager.java:107) at org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.j av a:145) at org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreak er .java:552) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java: 13 7) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java: 30 2
Re: FOP 0.95 - bug with tables?
Hi Pascal, Just tried. While there is no exception, fo:table-row min-height=1em still does not work in FOP 1.0 (still no effect whatsoever). See quoted email as to why fo:table-cell height=... is not sufficient to solve this issue. Regards, Alexey. On Wednesday, September 15, 2010 12:35:00 am Pascal Sancho wrote: Hi Alexey this Exception issue seems to be fixed in FOP 1.0 (I've noticed in the pdf attached to your initial post that you used FOP 0.95). I suggest you to upgrade, at least min-height will work as expected without any Exception. Pascal Le 14/09/2010 22:10, Alexey Neyman a écrit : Hi Pascal, I see your point, although this advice is not particularly useful to what I am doing. As I mentioned, this table is generated by DocBook, and its templates for tables are probably the most convoluted in the whole stylesheet. I was trying to avoid heavy customizations of these templates. Another issue is that what I really want is min-height property in this case: at XSLT stage, it is not known whether text inside the table cell will occupy 1, 2, 3 or 15 rows. I tried using min-height in the test case I posted before, but this causes an exception in FOP (see below). According to spec, using min-height is perfectly legal: it should set minimum height, while retaining optimum and maximum height as auto. An finally, what you suggested won't work if another cell is more than 1 row. With the example I posted: AB AC DC If I set height to 2em, it looks okay. But, if cell B contains a text that wraps into 2nd line, the table again looks as AB DC but now the whole row containing C and D cells is 2em in height. Given that DocBook stylesheet does not know how many lines of text there will be in each cell - that is determined by FO processor - I cannot calculate the height value beforehand. So, I tried to set height/min-height on a fo:table-row instead. Setting min-height= on fo:table-row results in a different exception (also, see below). Setting height= on fo:table-row does not have any effect at all. According to XSL-FO spec, block-progression-dimension property (that is set through height property) is allowed on fo:table-row. Is this a FOP bug/missing feature? Regards, Alexey. Exception with min-height= on fo:table-cell: 8-8-8-8-8-8-8 Sep 14, 2010 12:37:47 PM org.apache.fop.cli.Main startFOP SEVERE: Exception java.lang.NullPointerException at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:21 7) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:125) at org.apache.fop.cli.Main.startFOP(Main.java:166) at org.apache.fop.cli.Main.main(Main.java:197) Caused by: java.lang.NullPointerException at org.apache.fop.layoutmgr.table.RowGroupLayoutManager.computeRowHeights(Ro wGroupLayoutManager.java:165) at org.apache.fop.layoutmgr.table.RowGroupLayoutManager.createElementsForRow Group(RowGroupLayoutManager.java:127) at org.apache.fop.layoutmgr.table.RowGroupLayoutManager.getNextKnuthElements (RowGroupLayoutManager.java:60) at org.apache.fop.layoutmgr.table.TableContentLayoutManager.getKnuthElements ForRowIterator(TableContentLayoutManager.java:220) at org.apache.fop.layoutmgr.table.TableContentLayoutManager.getNextKnuthElem ents(TableContentLayoutManager.java:172) at org.apache.fop.layoutmgr.table.TableLayoutManager.getNextKnuthElements(Ta bleLayoutManager.java:247) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements( BlockStackingLayoutManager.java:294) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLay outManager.java:116) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayou tManager.java:107) at org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.jav a:145) at org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker .java:552) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:13 7) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:30 2) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:26 4) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSeq uenceLayoutManager.java:106) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java: 234) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:123 ) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.ja va:340
Re: FOP 0.95 - bug with tables?
Actually, test case can be reduced even more. Desired result: AB AC DC Essential XSL-FO code: fo:table fo:table-body fo:table-row fo:table-cell number-rows-spanned=2 fo:blockA/fo:block /fo:table-cell fo:table-cell fo:blockB/fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cel number-rows-spanned=2 fo:blockC/fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:blockD/fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table Got result (see attached 1.fo and 1.pdf): AB DC Is it a bug? Regards, Alexey. On Monday, September 13, 2010 01:39:06 pm Alexey Neyman wrote: Hi All, I am trying to format a table with cells spanning as shown below: AAB AAC DEC To do this, I am using attached .fo file (it is actually a stripped-down DocBook-generated table). The essential piece is: fo:table fo:table-body fo:table-row fo:table-cell number-rows-spanned=2 number-columns-spanned=2 fo:blockA/fo:block /fo:table-cell fo:table-cell fo:blockB/fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell number-rows-spanned=2 fo:blockC/fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:blockD/fo:block /fo:table-cell fo:table-cell fo:blockE/fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table However, it gets rendered like this: AAB DEC (there is no row that includes both A-cell and C-cell). See the attached PDF. It looks like a bug; could somebody confirm and suggest a fix/workaround? PS. Using FOP 0.95, Ubuntu 10.04. Regards, Alexey. ?xml version=1.0? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=body page-width=5in page-height=5in margin=0.5in fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=body fo:flow flow-name=xsl-region-body fo:block fo:table table-layout=fixed width=100% border-top=solid black 0.5pt border-left=solid black 0.5pt fo:table-body fo:table-row fo:table-cell border-bottom=solid black 0.5pt border-right=solid black 0.5pt number-rows-spanned=2 fo:blockA/fo:block /fo:table-cell fo:table-cell border-bottom=solid black 0.5pt border-right=solid black 0.5pt fo:blockB/fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell border-bottom=solid black 0.5pt border-right=solid black 0.5pt number-rows-spanned=2 fo:blockC/fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell border-bottom=solid black 0.5pt border-right=solid black 0.5pt fo:blockD/fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:block /fo:flow /fo:page-sequence /fo:root 1.pdf Description: Adobe PDF document - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 - bug with tables?
) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:485) at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:214) ... 3 more 8-8-8-8-8-8-8 Exception with min-height= on fo:table-row: 8-8-8-8-8-8-8 Sep 14, 2010 12:53:10 PM org.apache.fop.cli.Main startFOP SEVERE: Exception java.lang.NullPointerException at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:217) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:125) at org.apache.fop.cli.Main.startFOP(Main.java:166) at org.apache.fop.cli.Main.main(Main.java:197) Caused by: java.lang.NullPointerException at org.apache.fop.layoutmgr.MinOptMaxUtil.toMinOptMax(MinOptMaxUtil.java:106) at org.apache.fop.layoutmgr.table.RowGroupLayoutManager.computeRowHeights(RowGroupLayoutManager.java:155) at org.apache.fop.layoutmgr.table.RowGroupLayoutManager.createElementsForRowGroup(RowGroupLayoutManager.java:127) at org.apache.fop.layoutmgr.table.RowGroupLayoutManager.getNextKnuthElements(RowGroupLayoutManager.java:60) at org.apache.fop.layoutmgr.table.TableContentLayoutManager.getKnuthElementsForRowIterator(TableContentLayoutManager.java:220) at org.apache.fop.layoutmgr.table.TableContentLayoutManager.getNextKnuthElements(TableContentLayoutManager.java:172) at org.apache.fop.layoutmgr.table.TableLayoutManager.getNextKnuthElements(TableLayoutManager.java:247) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:294) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:116) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:107) at org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:145) at org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:552) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:137) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:302) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:264) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:106) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:234) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:123) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:340) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:169) at org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1102) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:485) at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:214) ... 3 more 8-8-8-8-8-8-8 On Tuesday, September 14, 2010 01:04:02 am Pascal Sancho wrote: Hi, I think the behaviour is correct here: Cells height is not sufficient to see the effect you want. try to increase the height of vertically spanned cells (by setting the height property to 2em) and you will see what I mean. Pascal Le 13/09/2010 22:39, Alexey Neyman a écrit : fo:table table-layout=fixed width=100% border-top=solid black 0.5pt border-left=solid black 0.5pt fo:table-body fo:table-row fo:table-cell border-bottom=solid black 0.5pt border-right=solid black 0.5pt number-rows-spanned=2 number-columns-spanned=2 fo:blockA/fo:block /fo:table-cell fo:table-cell border-bottom=solid black 0.5pt border-right=solid black 0.5pt
FOP 0.95 - bug with tables?
Hi All, I am trying to format a table with cells spanning as shown below: AAB AAC DEC To do this, I am using attached .fo file (it is actually a stripped-down DocBook-generated table). The essential piece is: fo:table fo:table-body fo:table-row fo:table-cell number-rows-spanned=2 number-columns-spanned=2 fo:blockA/fo:block /fo:table-cell fo:table-cell fo:blockB/fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell number-rows-spanned=2 fo:blockC/fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:blockD/fo:block /fo:table-cell fo:table-cell fo:blockE/fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table However, it gets rendered like this: AAB DEC (there is no row that includes both A-cell and C-cell). See the attached PDF. It looks like a bug; could somebody confirm and suggest a fix/workaround? PS. Using FOP 0.95, Ubuntu 10.04. Regards, Alexey. 1.pdf Description: Adobe PDF document ?xml version=1.0? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=body page-width=5in page-height=5in margin=0.5in fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=body fo:flow flow-name=xsl-region-body fo:block fo:table table-layout=fixed width=100% border-top=solid black 0.5pt border-left=solid black 0.5pt fo:table-body fo:table-row fo:table-cell border-bottom=solid black 0.5pt border-right=solid black 0.5pt number-rows-spanned=2 number-columns-spanned=2 fo:blockA/fo:block /fo:table-cell fo:table-cell border-bottom=solid black 0.5pt border-right=solid black 0.5pt fo:blockB/fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell border-bottom=solid black 0.5pt border-right=solid black 0.5pt number-rows-spanned=2 fo:blockC/fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell border-bottom=solid black 0.5pt border-right=solid black 0.5pt fo:blockD/fo:block /fo:table-cell fo:table-cell border-bottom=solid black 0.5pt border-right=solid black 0.5pt fo:blockE/fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:block /fo:flow /fo:page-sequence /fo:root - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 - bug with tables?
Actually, test case can be reduced even more. Desired result: AB AC DC Essential XSL-FO code: fo:table fo:table-body fo:table-row fo:table-cell number-rows-spanned=2 fo:blockA/fo:block /fo:table-cell fo:table-cell fo:blockB/fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cel number-rows-spanned=2 fo:blockC/fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:blockD/fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table Got result (see attached 1.fo and 1.pdf): AB DC Is it a bug? Regards, Alexey. On Monday, September 13, 2010 01:39:06 pm Alexey Neyman wrote: Hi All, I am trying to format a table with cells spanning as shown below: AAB AAC DEC To do this, I am using attached .fo file (it is actually a stripped-down DocBook-generated table). The essential piece is: fo:table fo:table-body fo:table-row fo:table-cell number-rows-spanned=2 number-columns-spanned=2 fo:blockA/fo:block /fo:table-cell fo:table-cell fo:blockB/fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell number-rows-spanned=2 fo:blockC/fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:blockD/fo:block /fo:table-cell fo:table-cell fo:blockE/fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table However, it gets rendered like this: AAB DEC (there is no row that includes both A-cell and C-cell). See the attached PDF. It looks like a bug; could somebody confirm and suggest a fix/workaround? PS. Using FOP 0.95, Ubuntu 10.04. Regards, Alexey. ?xml version=1.0? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=body page-width=5in page-height=5in margin=0.5in fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=body fo:flow flow-name=xsl-region-body fo:block fo:table table-layout=fixed width=100% border-top=solid black 0.5pt border-left=solid black 0.5pt fo:table-body fo:table-row fo:table-cell border-bottom=solid black 0.5pt border-right=solid black 0.5pt number-rows-spanned=2 fo:blockA/fo:block /fo:table-cell fo:table-cell border-bottom=solid black 0.5pt border-right=solid black 0.5pt fo:blockB/fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell border-bottom=solid black 0.5pt border-right=solid black 0.5pt number-rows-spanned=2 fo:blockC/fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell border-bottom=solid black 0.5pt border-right=solid black 0.5pt fo:blockD/fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:block /fo:flow /fo:page-sequence /fo:root 1.pdf Description: Adobe PDF document - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 - bug with tables?
I found a workaround for this. An zero-width column can be added to the table: fo:table-column column-width=proportional-column-width(0)/ And then, add fo:table-cellfo:block#160;/fo:block/fo:table-cell to the problematic row. This causes a warning about area overflow, but looks okay. Ugly, but at least it works... Regards, Alexey. On Monday, September 13, 2010 02:12:34 pm Alexey Neyman wrote: Actually, test case can be reduced even more. Desired result: AB AC DC Essential XSL-FO code: fo:table fo:table-body fo:table-row fo:table-cell number-rows-spanned=2 fo:blockA/fo:block /fo:table-cell fo:table-cell fo:blockB/fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cel number-rows-spanned=2 fo:blockC/fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:blockD/fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table Got result (see attached 1.fo and 1.pdf): AB DC Is it a bug? Regards, Alexey. On Monday, September 13, 2010 01:39:06 pm Alexey Neyman wrote: Hi All, I am trying to format a table with cells spanning as shown below: AAB AAC DEC To do this, I am using attached .fo file (it is actually a stripped-down DocBook-generated table). The essential piece is: fo:table fo:table-body fo:table-row fo:table-cell number-rows-spanned=2 number-columns-spanned=2 fo:blockA/fo:block /fo:table-cell fo:table-cell fo:blockB/fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell number-rows-spanned=2 fo:blockC/fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:blockD/fo:block /fo:table-cell fo:table-cell fo:blockE/fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table However, it gets rendered like this: AAB DEC (there is no row that includes both A-cell and C-cell). See the attached PDF. It looks like a bug; could somebody confirm and suggest a fix/workaround? PS. Using FOP 0.95, Ubuntu 10.04. Regards, Alexey. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Is keep-together.within-line=always working with nested fo:inline?
Hi, I am trying to prevent a line from breaking, so I wrapped it inside a fo:inline keep-together.within-line=always.../fo:inline. This works as long as the line is a plain text, but does not work if there is a nested fo:inline. In that case, the line breaks at the nested fo:inline. Here is a FO snippet: === fo:inline keep-together.within-line=alwaysvery long and nasty fo:inline/line that should not probably wrap unless somebody is using a nested fo inline fo:inline/ which allows this line to wrapping aroundfo:inline/ even though it should not/fo:inline === Is it intended behavior or a bug? I tried googling, but haven't found any definitive answer. The most relevant result was an item in FOP 0.94 change list which said that UAX+14 line breaking is implemented, but it does not propagate to nested fo:inlines. I am not sure if this explains such behavior. I am using FOP 0.95, packages from Ubuntu 10.04. Thanks, Alexey. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
