FOP 1.1: Rendering problem with overflowing table cells
Hi all, please find attached an FO file and two PDFs, which were rendered from it. One was rendered by FOP 0.95, while the other was rendered by FOP 1.1. If you compare the PDFs, you'll see that the header Price (EUR) as well as the value 8,888,888.88 jut out to the right in the FOP 1.1 rendering, while they look fine in the FOP 0.95 output. The structure of the fo:table is such that the rightmost column is too small to fit either of these two items, so they have to overflow the table cell in some way (cut off is not an option here). In FOP 0.95 the items flow out to the left, practically into the previous table cell, but there is enough room to accommodate them. Whereas FOP 1.1 flows the items out to the right of the table cell, which in this case looks ugly. My questions are: can I get the old rendering behavior back? Perhaps by changing something in the FO? And who is actually doing the right thing, FOP 0.95 or FOP 1.1? Note: in FOP 1.1 these were rendered with the Complex Scripts feature off, so as to minimise variation between FOP 0.95 and 1.1. Many thanks in advance for any pointers, Ulrich ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master page-height=29.7cm page-width=21cm master-name=simple fo:region-body margin-right=2cm margin-left=2cm margin-bottom=2.5cm margin-top=5cm/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=simple fo:flow flow-name=xsl-region-body fo:block font-family=Helvetica font-size=10pt line-height=12pt fo:table space-after.optimum=2pt space-before.optimum=2pt width=17cm table-layout=fixed fo:table-column column-width=2.8cm/ fo:table-column column-width=3.5cm/ fo:table-column column-width=9.2cm/ fo:table-column column-width=1.5cm/ fo:table-body fo:table-row font-weight=bold line-height=10pt font-size=12pt background-color=white border-bottom=0.5pt black solid border-top=0.5pt black solidfo:table-cell padding-after=2pt padding-before=4pt padding-start=3ptfo:blockArticle/fo:block/fo:table-cellfo:table-cell padding-after=2pt padding-before=4pt padding-start=3ptfo:blockCode/fo:block/fo:table-cellfo:table-cell padding-after=2pt padding-before=4pt padding-start=3ptfo:blockDescription/fo:block/fo:table-cellfo:table-cell padding-after=2pt padding-before=4ptfo:block end-indent=5pt text-align=endPrice (EUR)/fo:block/fo:table-cell/fo:table-row fo:table-row line-height=10pt font-size=9pt background-color=whitefo:table-cell padding-after=1pt padding-before=3pt padding-start=3ptfo:block65-877318374/fo:block/fo:table-cellfo:table-cell padding-after=1pt padding-before=3pt padding-start=3ptfo:blockH7Z-UUT12a 2012/fo:block/fo:table-cellfo:table-cell padding-after=1pt padding-before=3pt padding-start=3ptfo:blockItem 1/fo:block/fo:table-cellfo:table-cell padding-after=1pt padding-before=3ptfo:block end-indent=5pt text-align=end6723.12/fo:block/fo:table-cell/fo:table-row fo:table-row line-height=10pt font-size=9pt background-color=whitefo:table-cell padding-after=1pt padding-before=1pt padding-start=3ptfo:block36-375819409/fo:block/fo:table-cellfo:table-cell padding-after=1pt padding-before=1pt padding-start=3ptfo:blockH7T-MK431b 2013/fo:block/fo:table-cellfo:table-cell padding-after=1pt padding-before=1pt padding-start=3ptfo:blockItem with a very long description, which is perfectly ok, but we'd still like to use the available space as efficiently as possible ./fo:block/fo:table-cellfo:table-cell padding-after=1pt padding-before=1ptfo:block end-indent=5pt text-align=end553.84/fo:block/fo:table-cell/fo:table-row fo:table-row line-height=10pt font-size=9pt background-color=whitefo:table-cell padding-after=1pt padding-before=1pt padding-start=3ptfo:block53-371223865/fo:block/fo:table-cellfo:table-cell padding-after=1pt padding-before=1pt padding-start=3ptfo:blockUZ6-8PL2Qa 2009/fo:block/fo:table-cellfo:table-cell padding-after=1pt padding-before=1pt padding-start=3ptfo:blockItem 3/fo:block/fo:table-cellfo:table-cell padding-after=1pt padding-before=1ptfo:block end-indent=5pt text-align=end84.47/fo:block/fo:table-cell/fo:table-row fo:table-row line-height=11pt font-weight=bold font-size=9pt background-color=white border-bottom=0.5pt black solid border-top=0.5pt black solidfo:table-cell padding-after=3pt padding-before=4pt padding-start=3pt number-columns-spanned=3fo:blockSum Total/fo:block/fo:table-cellfo:table-cell padding-after=3pt padding-before=4ptfo:block end-indent=5pt text-align=end8,888,888.88/fo:block/fo:table-cell/fo:table-row /fo:table-body /fo:table /fo:block /fo:flow /fo:page-sequence /fo:root overflow-0.95.pdf Description: Adobe PDF document overflow-1.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 1.1: Rendering problem with overflowing table cells
I would suggest you check the current trunk (you can use a nightly build if you don't want to build yourself). There were some fixes in this are since 1.1. On Wed, May 29, 2013 at 6:56 AM, Ulrich Mayring u...@denic.de wrote: Hi all, please find attached an FO file and two PDFs, which were rendered from it. One was rendered by FOP 0.95, while the other was rendered by FOP 1.1. If you compare the PDFs, you'll see that the header Price (EUR) as well as the value 8,888,888.88 jut out to the right in the FOP 1.1 rendering, while they look fine in the FOP 0.95 output. The structure of the fo:table is such that the rightmost column is too small to fit either of these two items, so they have to overflow the table cell in some way (cut off is not an option here). In FOP 0.95 the items flow out to the left, practically into the previous table cell, but there is enough room to accommodate them. Whereas FOP 1.1 flows the items out to the right of the table cell, which in this case looks ugly. My questions are: can I get the old rendering behavior back? Perhaps by changing something in the FO? And who is actually doing the right thing, FOP 0.95 or FOP 1.1? Note: in FOP 1.1 these were rendered with the Complex Scripts feature off, so as to minimise variation between FOP 0.95 and 1.1. Many thanks in advance for any pointers, Ulrich - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 1.1: Rendering problem with overflowing table cells
Hi Glenn, thanks for the pointer, your suspicion was correct. With the latest nightly build the page is rendered like it was in FOP 0.95, which I believe is the correct way. Thanks a lot, Ulrich Glenn Adams wrote: I would suggest you check the current trunk (you can use a nightly build if you don't want to build yourself). There were some fixes in this are since 1.1. On Wed, May 29, 2013 at 6:56 AM, Ulrich Mayring u...@denic.de wrote: Hi all, please find attached an FO file and two PDFs, which were rendered from it. One was rendered by FOP 0.95, while the other was rendered by FOP 1.1. If you compare the PDFs, you'll see that the header Price (EUR) as well as the value 8,888,888.88 jut out to the right in the FOP 1.1 rendering, while they look fine in the FOP 0.95 output. The structure of the fo:table is such that the rightmost column is too small to fit either of these two items, so they have to overflow the table cell in some way (cut off is not an option here). In FOP 0.95 the items flow out to the left, practically into the previous table cell, but there is enough room to accommodate them. Whereas FOP 1.1 flows the items out to the right of the table cell, which in this case looks ugly. My questions are: can I get the old rendering behavior back? Perhaps by changing something in the FO? And who is actually doing the right thing, FOP 0.95 or FOP 1.1? Note: in FOP 1.1 these were rendered with the Complex Scripts feature off, so as to minimise variation between FOP 0.95 and 1.1. Many thanks in advance for any pointers, Ulrich - 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: FOP 1.1: Rendering problem with overflowing table cells
Ooops, the newest Nightly Build has changed the Interface of FopFactory and FontManager. All the setter-methods in those classes are gone. How can I programmatically configure FOP now? The docs under http://xmlgraphics.apache.org/fop/trunk/embedding.html#config-internal still suggest the old way. cheers, Ulrich Ulrich Mayring wrote: Hi Glenn, thanks for the pointer, your suspicion was correct. With the latest nightly build the page is rendered like it was in FOP 0.95, which I believe is the correct way. Thanks a lot, Ulrich Glenn Adams wrote: I would suggest you check the current trunk (you can use a nightly build if you don't want to build yourself). There were some fixes in this are since 1.1. On Wed, May 29, 2013 at 6:56 AM, Ulrich Mayring u...@denic.de wrote: Hi all, please find attached an FO file and two PDFs, which were rendered from it. One was rendered by FOP 0.95, while the other was rendered by FOP 1.1. If you compare the PDFs, you'll see that the header Price (EUR) as well as the value 8,888,888.88 jut out to the right in the FOP 1.1 rendering, while they look fine in the FOP 0.95 output. The structure of the fo:table is such that the rightmost column is too small to fit either of these two items, so they have to overflow the table cell in some way (cut off is not an option here). In FOP 0.95 the items flow out to the left, practically into the previous table cell, but there is enough room to accommodate them. Whereas FOP 1.1 flows the items out to the right of the table cell, which in this case looks ugly. My questions are: can I get the old rendering behavior back? Perhaps by changing something in the FO? And who is actually doing the right thing, FOP 0.95 or FOP 1.1? Note: in FOP 1.1 these were rendered with the Complex Scripts feature off, so as to minimise variation between FOP 0.95 and 1.1. Many thanks in advance for any pointers, Ulrich - 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: FOP 1.1: Rendering problem with overflowing table cells
Apparently the setter methods were deleted by merging a Temp_URI_Unification branch back into the trunk. Unfortunately I can't find this branch in the repository. Also, the supplied examples never configure the FopFactory programmatically. Ulrich Ulrich Mayring wrote: Ooops, the newest Nightly Build has changed the Interface of FopFactory and FontManager. All the setter-methods in those classes are gone. How can I programmatically configure FOP now? The docs under http://xmlgraphics.apache.org/fop/trunk/embedding.html#config-internal still suggest the old way. cheers, Ulrich Ulrich Mayring wrote: Hi Glenn, thanks for the pointer, your suspicion was correct. With the latest nightly build the page is rendered like it was in FOP 0.95, which I believe is the correct way. Thanks a lot, Ulrich Glenn Adams wrote: I would suggest you check the current trunk (you can use a nightly build if you don't want to build yourself). There were some fixes in this are since 1.1. On Wed, May 29, 2013 at 6:56 AM, Ulrich Mayring u...@denic.de wrote: Hi all, please find attached an FO file and two PDFs, which were rendered from it. One was rendered by FOP 0.95, while the other was rendered by FOP 1.1. If you compare the PDFs, you'll see that the header Price (EUR) as well as the value 8,888,888.88 jut out to the right in the FOP 1.1 rendering, while they look fine in the FOP 0.95 output. The structure of the fo:table is such that the rightmost column is too small to fit either of these two items, so they have to overflow the table cell in some way (cut off is not an option here). In FOP 0.95 the items flow out to the left, practically into the previous table cell, but there is enough room to accommodate them. Whereas FOP 1.1 flows the items out to the right of the table cell, which in this case looks ugly. My questions are: can I get the old rendering behavior back? Perhaps by changing something in the FO? And who is actually doing the right thing, FOP 0.95 or FOP 1.1? Note: in FOP 1.1 these were rendered with the Complex Scripts feature off, so as to minimise variation between FOP 0.95 and 1.1. Many thanks in advance for any pointers, Ulrich - 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: FOP 1.1: Rendering problem with overflowing table cells
I've asked some of the team that worked on those changes to respond to you on this issue. On Wed, May 29, 2013 at 9:20 AM, Ulrich Mayring u...@denic.de wrote: Apparently the setter methods were deleted by merging a Temp_URI_Unification branch back into the trunk. Unfortunately I can't find this branch in the repository. Also, the supplied examples never configure the FopFactory programmatically. Ulrich Ulrich Mayring wrote: Ooops, the newest Nightly Build has changed the Interface of FopFactory and FontManager. All the setter-methods in those classes are gone. How can I programmatically configure FOP now? The docs under http://xmlgraphics.apache.org/**fop/trunk/embedding.html#** config-internalhttp://xmlgraphics.apache.org/fop/trunk/embedding.html#config-internalstill suggest the old way. cheers, Ulrich Ulrich Mayring wrote: Hi Glenn, thanks for the pointer, your suspicion was correct. With the latest nightly build the page is rendered like it was in FOP 0.95, which I believe is the correct way. Thanks a lot, Ulrich Glenn Adams wrote: I would suggest you check the current trunk (you can use a nightly build if you don't want to build yourself). There were some fixes in this are since 1.1. On Wed, May 29, 2013 at 6:56 AM, Ulrich Mayring u...@denic.de wrote: Hi all, please find attached an FO file and two PDFs, which were rendered from it. One was rendered by FOP 0.95, while the other was rendered by FOP 1.1. If you compare the PDFs, you'll see that the header Price (EUR) as well as the value 8,888,888.88 jut out to the right in the FOP 1.1 rendering, while they look fine in the FOP 0.95 output. The structure of the fo:table is such that the rightmost column is too small to fit either of these two items, so they have to overflow the table cell in some way (cut off is not an option here). In FOP 0.95 the items flow out to the left, practically into the previous table cell, but there is enough room to accommodate them. Whereas FOP 1.1 flows the items out to the right of the table cell, which in this case looks ugly. My questions are: can I get the old rendering behavior back? Perhaps by changing something in the FO? And who is actually doing the right thing, FOP 0.95 or FOP 1.1? Note: in FOP 1.1 these were rendered with the Complex Scripts feature off, so as to minimise variation between FOP 0.95 and 1.1. Many thanks in advance for any pointers, Ulrich --**--** - To unsubscribe, e-mail: fop-users-unsubscribe@**xmlgraphics.apache.orgfop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-help@xmlgraphics.** apache.org fop-users-h...@xmlgraphics.apache.org --**--**- To unsubscribe, e-mail: fop-users-unsubscribe@**xmlgraphics.apache.orgfop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-help@xmlgraphics.**apache.orgfop-users-h...@xmlgraphics.apache.org
RE: FOP 1.1: Unwanted Ligatures in Latin Scripts
Dear All,
The following features are enabled by default for all scripts which do not
otherwise override this feature set:
GSUB: {ccmp, liga, locl}
GPOS: {kern, mark, mkmk}
talking about ligatures I've made a test for Palatino Linotype on fresh
installed fop 1.1 and no ligature replacement is applied. The font is found
(auto-detected) and embedded correctly.
It works fine in ConTeXt:
http://wiki.contextgarden.net/Palatino_Linotype_under_MKIV
Tested on my Win 7.
So I have the opposite problem. Can I switch this feature on somehow?
Thanks,
Jan
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 1.1: Unwanted Ligatures in Latin Scripts
What, am I supposed to guess your output? Come on now, how about an input
FO and output PDF file? Jeez.
Further, have you checked that this font actually contains a GSUB table
with a 'liga' feature that enables the mapping you wish?
On Wed, May 29, 2013 at 2:40 PM, honyk j.tosov...@email.cz wrote:
Dear All,
The following features are enabled by default for all scripts which do
not
otherwise override this feature set:
GSUB: {ccmp, liga, locl}
GPOS: {kern, mark, mkmk}
talking about ligatures I've made a test for Palatino Linotype on fresh
installed fop 1.1 and no ligature replacement is applied. The font is found
(auto-detected) and embedded correctly.
It works fine in ConTeXt:
http://wiki.contextgarden.net/Palatino_Linotype_under_MKIV
Tested on my Win 7.
So I have the opposite problem. Can I switch this feature on somehow?
Thanks,
Jan
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: FOP 1.1: Unwanted Ligatures in Latin Scripts
What, am I supposed to guess your output?
Come on now, how about an input FO and output PDF file? Jeez.
Sorry for my brevity. I automatically take FOP as a FO to PDF converter (which
is not very precise). And if we talk about ligatures, the classical ones like
fl, fi, or ffi were meant.
My FO code is e.g. fo:blockOffice/fo:block and there is no 'f_f_i' ligature
in the PDF output.
Further, have you checked that this font actually contains
a GSUB table with a 'liga' feature that enables the mapping you wish?
This is the info taken from FontLab for the Regular style:
feature liga { # Standard Ligatures
# Latin
sub f b by f_b;
sub f f b by f_f_b;
sub f f h by f_f_h;
sub f f i by f_f_i;
sub f f k by f_f_k;
sub f f l by f_f_l;
sub f f by f_f;
sub f h by f_h;
sub f i by fi;
sub f j by f_j;
sub f k by f_k;
sub f l by fl;
sub t t by t_t;
sub t z by t_z;
language TRK ; # Turkish
language ROM ; # Romanian
} liga;
So I think that ligatures autoreplacement is somehow disabled. It could be
caused by this:
'...scripts which do not otherwise override this feature set...'
But I don't understand it much.
Jan
On Wed, May 29, 2013 at 2:40 PM, honyk j.tosov...@email.cz wrote:
Dear All,
The following features are enabled by default for all scripts which do not
otherwise override this feature set:
GSUB: {ccmp, liga, locl}
GPOS: {kern, mark, mkmk}
talking about ligatures I've made a test for Palatino Linotype on fresh
installed fop 1.1 and no ligature replacement is applied. The font is found
(auto-detected) and embedded correctly.
It works fine in ConTeXt:
http://wiki.contextgarden.net/Palatino_Linotype_under_MKIV
Tested on my Win 7.
So I have the opposite problem. Can I switch this feature on somehow?
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
Re: FOP 1.1: Rendering problem with overflowing table cells
See this thread: http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/201302.mbox/%3c512d5b3c.8060...@gmail.com%3e On Wednesday, May 29, 2013, Ulrich Mayring wrote: Ooops, the newest Nightly Build has changed the Interface of FopFactory and FontManager. All the setter-methods in those classes are gone. How can I programmatically configure FOP now? The docs under http://xmlgraphics.apache.org/**fop/trunk/embedding.html#**config-internalhttp://xmlgraphics.apache.org/fop/trunk/embedding.html#config-internalstill suggest the old way. cheers, Ulrich Ulrich Mayring wrote: Hi Glenn, thanks for the pointer, your suspicion was correct. With the latest nightly build the page is rendered like it was in FOP 0.95, which I believe is the correct way. Thanks a lot, Ulrich Glenn Adams wrote: I would suggest you check the current trunk (you can use a nightly build if you don't want to build yourself). There were some fixes in this are since 1.1. On Wed, May 29, 2013 at 6:56 AM, Ulrich Mayring u...@denic.de wrote: Hi all, please find attached an FO file and two PDFs, which were rendered from it. One was rendered by FOP 0.95, while the other was rendered by FOP 1.1. If you compare the PDFs, you'll see that the header Price (EUR) as well as the value 8,888,888.88 jut out to the right in the FOP 1.1 rendering, while they look fine in the FOP 0.95 output. The structure of the fo:table is such that the rightmost column is too small to fit either of these two items, so they have to overflow the table cell in some way (cut off is not an option here). In FOP 0.95 the items flow out to the left, practically into the previous table cell, but there is enough room to accommodate them. Whereas FOP 1.1 flows the items out to the right of the table cell, which in this case looks ugly. My questions are: can I get the old rendering behavior back? Perhaps by changing something in the FO? And who is actually doing the right thing, FOP 0.95 or FOP 1.1? Note: in FOP 1.1 these were rendered with the Complex Scripts feature off, so as to minimise variation between FOP 0.95 and 1.1. Many thanks in advance for any pointers, Ulrich --**--** - 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
Conversion of PDF to Postscript Compatible Asset
Hi Guys, Wondering if you could suggest whether I should bother and if so where I would start isolating the root cause of this problem. I'm using fop-pdf-images as a background, and in PDF it looks fine, in postscript the shading part of the document falls off. (I've tried both CMYK based and RGB based PDFs with it.) I ended up having to render the document as PDF, which removes a lot of the smarts I have in place in respects to duplexing and tray selection. I'm currently using FOP 1.1 for the process, with pdf-image add-in - I have re-downloaded the fop 1.1 source and the latest fop-pdf-images and compiled them and it seems to have built OK. The only output which seems PDFBox related is: May 30, 2013 2:57:10 PM org.apache.pdfbox.util.PDFStreamEngine processOperator INFO: unsupported/disabled operation: BDC May 30, 2013 2:57:11 PM org.apache.pdfbox.util.PDFStreamEngine processOperator INFO: unsupported/disabled operation: BX May 30, 2013 2:57:11 PM org.apache.pdfbox.util.PDFStreamEngine processOperator INFO: unsupported/disabled operation: EX May 30, 2013 2:57:11 PM org.apache.pdfbox.util.PDFStreamEngine processOperator INFO: unsupported/disabled operation: EMC I have built a mini test case/example if that helps or if anyone is curious.. Thanks Martin. IntelliMail attachment: pdf_postscript.png - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
