[jira] [Commented] (FOP-1969) Surrogate pairs not treated as single unicode codepoint for display purposes
[ https://issues.apache.org/jira/browse/FOP-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15535284#comment-15535284 ] Luis Bernardo commented on FOP-1969: You should have write permissions now. > Surrogate pairs not treated as single unicode codepoint for display purposes > > > Key: FOP-1969 > URL: https://issues.apache.org/jira/browse/FOP-1969 > Project: FOP > Issue Type: Improvement > Components: unqualified >Affects Versions: trunk > Environment: Operating System: All > Platform: All >Reporter: Glenn Adams > Attachments: Urdu.zip, pcltest.zip, single-byte.zip, testing.fo, > testing.fo, testing.pdf, testing.pdf, testing.xml, testing.xsl, tiffttc.zip > > > unicode codepoints outside of the BMP (base multilingual plane), i.e., whose > scalar value is greater than 0x (65535), are coded as UTF-16 surrogate > pairs in Java strings, which pair should be treated as a single codepoint for > the purpose of mapping to a glyph in a font (that supports extra-BMP > mappings); > at present, FOP does not correctly handle this case in simple (non complex > script) rendering paths; > furthermore, though some support has been added to handle this in the complex > script rendering path, it has not yet been tested, so is not necessarily > working there either; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: JavaIO Default ICC Profiles
Yes, that is what I was suspecting. My suggestion then is to do the check
when loading the image, as you propose. If there is no embedded profile in
the PNG do not embed one by default. We could make this configurable but I
don;t see the need for that until we find an example where having the
default profile embedded helps.
On Wed, Jan 13, 2016 at 1:19 PM, Matthias Reischenbacher <
matthias8...@gmx.at> wrote:
> Hi,
>
> FOP-1575 seems to be similar, but isn't the same. I also can't reproduce
> it on my platform (win, jdk 8), so perhaps it has been fixed in the
> meantime by some other change.
>
> Regarding your other questions: getEffectiveICCProfile() is always
> called, regardless of embedded or non-embedded profiles. In fact I just
> tried with more sample PNG images (with and without embedded profiles)
> and my fix is definitely wrong, because embedded ICC profiles for Gray
> color space are also of type ICC_ProfileGray, so also embedded profiles
> are now being ignored by my change. I think my fix needs to be added
> more deep down, probably in the image loader
> (ImageLoaderImageIO.loadImage). Perhaps it would be a good thing to mark
> the Image there as having or not an embedded profile, so that the
> ImageRendererAdapter can better decide, if the profiles should be used.
> I will create a jira issue and check in more detail.
>
> BR,
> Matthias
>
> On 12.01.2016 19:27, Luis Bernardo wrote:
> >
> > Can you check whether FOP-1575 is the same problem?
> >
> > Is getEffectiveICCProfile() only called if there is no embedded
> > profile? Could there be cases where that profile is in fact correct?
> >
> > On 1/12/16 9:25 PM, Matthias Reischenbacher wrote:
> >> Hi,
> >>
> >> I've been struggling today with the PDF display of a PNG with "gray"
> >> color space. When using the default PNG loader (with the raw PNG loader
> >> all works fine), the colors are displayed very "light" and "dull".
> >> During a debug session I found out that the ImageIO loader assigns a
> >> default Gray ICC profile (of type java.awt.color.ICC_ProfileGray), if
> >> the PNG file doesn't have an embedded ICC profile. So the
> >> ImageRenderedAdapter.getEffectiveICCProfile method returns this Java
> >> "ICC_ProfileGray" profile, which is then embedded in the output PDF.
> >> Displaying the PNG with this profile, causes the "incorrect" color
> >> display.
> >> I'm aware that an ICC profile should be embedded in the PNG file, in
> >> order to have full control over color reproduction, but I'm wondering if
> >> it doesn't go a bit too far to output a profile, which is internally
> >> assigned by the JRE. As a quick fix I locally changed the
> >> ImageRenderedAdapter.getEffectiveICCProfile method the following way:
> >>
> >> protected ICC_Profile getEffectiveICCProfile() {
> >> ColorSpace cs = getImageColorSpace();
> >> if (cs instanceof ICC_ColorSpace) {
> >> ICC_ColorSpace iccSpace = (ICC_ColorSpace)cs;
> >> return !(iccSpace.getProfile() instanceof ICC_ProfileGray) ?
> >> iccSpace.getProfile() : null;
> >> } else {
> >> return null;
> >> }
> >> }
> >>
> >> Please let me know, if anybody disagrees with this approach or if it
> >> should be handled somewhere else.
> >>
> >> Thanks,
> >> Matthias
> >>
> >
>
>
>
Re: JavaIO Default ICC Profiles
Can you check whether FOP-1575 is the same problem?
Is getEffectiveICCProfile() only called if there is no embedded profile?
Could there be cases where that profile is in fact correct?
On 1/12/16 9:25 PM, Matthias Reischenbacher wrote:
Hi,
I've been struggling today with the PDF display of a PNG with "gray"
color space. When using the default PNG loader (with the raw PNG loader
all works fine), the colors are displayed very "light" and "dull".
During a debug session I found out that the ImageIO loader assigns a
default Gray ICC profile (of type java.awt.color.ICC_ProfileGray), if
the PNG file doesn't have an embedded ICC profile. So the
ImageRenderedAdapter.getEffectiveICCProfile method returns this Java
"ICC_ProfileGray" profile, which is then embedded in the output PDF.
Displaying the PNG with this profile, causes the "incorrect" color display.
I'm aware that an ICC profile should be embedded in the PNG file, in
order to have full control over color reproduction, but I'm wondering if
it doesn't go a bit too far to output a profile, which is internally
assigned by the JRE. As a quick fix I locally changed the
ImageRenderedAdapter.getEffectiveICCProfile method the following way:
protected ICC_Profile getEffectiveICCProfile() {
ColorSpace cs = getImageColorSpace();
if (cs instanceof ICC_ColorSpace) {
ICC_ColorSpace iccSpace = (ICC_ColorSpace)cs;
return !(iccSpace.getProfile() instanceof ICC_ProfileGray) ?
iccSpace.getProfile() : null;
} else {
return null;
}
}
Please let me know, if anybody disagrees with this approach or if it
should be handled somewhere else.
Thanks,
Matthias
Re: [VOTE] Release XML Graphics FOP 2.1 (2nd attempt)
+1 On 1/7/16 3:23 PM, Simon Steiner wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, This is a vote to release XML Graphics FOP 2.1, status.xml has been removed. Artifacts can be found there: https://people.apache.org/~ssteiner/fop-2.1 The release is signed with the key: https://people.apache.org/~ssteiner/KEYS The vote will end on 14/1/2016 +1 from me. Thanks -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJWjnStAAoJEFuT8d98223qzs4QAKqo+dNlr8yTD8NRBF23tdeh gpy7GwW6zQMHMihbRLZVbV+uUAg7KwV9H3WxBMmoZegasTKY6IS+CQulUeQHyJRE K/blb9E0wGFJzXDq9HbgLFlq+rYPtAN2myW9KdJ6+Wy219mW7bKOPQwLSQkFCpxi MmKFsXLV3BHPPWUK4gTlHkptZwu8L2b/LKw3p9FW3+02S/athgbBeUiG5Qri7yuF +Zl1bNoXT6mJ/41aYB6qLIYN/LCgoQoMzoMEKk9IfPcQ5twvB3OP7p4U47mCR0kQ Ij7KbuLvUAI44+SFqcVcJ7okBwPoPaE0blPck9yJaEcUNadfXkOpvN/LiapH+9MY 41rtKtCczsQBrSYjkF1ubtC4p957oxxvFBDoJf8Qfh3YHTHDBUCP52hTzZYkMBTD kZQRoTp5BnhIoJFNHr4F6uTrt9bDLdKsJhM9xL32jWuKFB/VkVbytFbj70kmy5PL FXI/6Z8CpkjcVDa9GJpStgRvHTiGNX3vC1kOrMZUzaSg/HwKdpfGMMnaUwWtVvmo TxmCWPM+UlMHwGAxhgm+M2ernpkllbgaT1ps4rX1OklYTkK0BVovM5UaWDIamtie klPszMDqPjHHuA2a9/OoHIUnYHvely9Ges7Dy8BGFD/BGce7RyM3wH+faxUkxHqg 9FqOHlwPkgZHbZMNuP06 =fPbU -END PGP SIGNATURE-
[jira] [Commented] (FOP-2157) Deadlock in CompareUtil class
[
https://issues.apache.org/jira/browse/FOP-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15087469#comment-15087469
]
Luis Bernardo commented on FOP-2157:
Did you check revision 1703427?
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/util/CompareUtil.java
2015/09/16 15:30:52 1703426
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/util/CompareUtil.java
2015/09/16 15:43:21 1703427
@@ -44,7 +44,7 @@
*/
public static boolean equal(Object o1, Object o2) {
int o1Hash = System.identityHashCode(o1);
-int o2Hash = System.identityHashCode(o1);
+int o2Hash = System.identityHashCode(o2);
if (o1Hash == o2Hash && o1 != o2 && o1Hash != 0) {
// in the rare case of different objects with the same hash code,
// the tieLock object is used to synchronize access
> Deadlock in CompareUtil class
> -
>
> Key: FOP-2157
> URL: https://issues.apache.org/jira/browse/FOP-2157
> Project: FOP
> Issue Type: Bug
> Components: unqualified
>Affects Versions: trunk
> Environment: Operating System: All
> Platform: PC
>Reporter: Matthias Reischenbacher
>Assignee: Alexios Giotis
> Fix For: trunk
>
> Attachments: FOP DEADLOCK jakarta_service_20121107.log,
> FOP-2157-test.patch, FOP-2157.patch, report-dump.txt, thread-dump.txt
>
>
> I'm getting a dead lock in the CompareUtil class, see the attached thread
> dump.
> Here small fragment of the thread dump
> [2012-11-07 14:06:25] [info] Found one Java-level deadlock:
> [2012-11-07 14:06:25] [info] =
> [2012-11-07 14:06:25] [info]
> [2012-11-07 14:06:25] [info] "http-80-exec-58":
> [2012-11-07 14:06:25] [info] waiting to lock monitor 0x06ca9480
> [2012-11-07 14:06:25] [info] (object 0x00071fe9bd00, a java.util.Vector)
> [2012-11-07 14:06:25] [info] ,
> which is held by "http-80-exec-5"
> [2012-11-07 14:06:25] [info]
> [2012-11-07 14:06:25] [info] "http-80-exec-5":
> [2012-11-07 14:06:25] [info] waiting to lock monitor 0x116ecfc8
> [2012-11-07 14:06:25] [info] (object 0x00071fe9a000, a java.util.Vector)
> [2012-11-07 14:06:25] [info] ,
> which is held by "http-80-exec-18"
> [2012-11-07 14:06:25] [info]
> [2012-11-07 14:06:25] [info] "http-80-exec-18":
> [2012-11-07 14:06:25] [info] waiting to lock monitor 0x06ca9480
> [2012-11-07 14:06:25] [info] (object 0x00071fe9bd00, a java.util.Vector)
> [2012-11-07 14:06:25] [info] ,
> which is held by "http-80-exec-5"
> [2012-11-07 14:06:25] [info]
> [2012-11-07 14:06:25] [info]
> [2012-11-07 14:06:25] [info] Java stack information for the threads listed
> above:
> [2012-11-07 14:06:25] [info]
> ===
> [2012-11-07 14:06:25] [info] "http-80-exec-58":
> [2012-11-07 14:06:25] [info] at java.util.Vector.equals(Vector.java:925)
> [2012-11-07 14:06:25] [info] - waiting to lock <0x00071fe9bd00>
> [2012-11-07 14:06:25] [info] (a java.util.Vector)
> [2012-11-07 14:06:25] [info] at
> org.apache.fop.util.CompareUtil.equal(CompareUtil.java:38)
> [2012-11-07 14:06:25] [info] at
> org.apache.fop.fo.properties.ListProperty.equals(ListProperty.java:123)
> [2012-11-07 14:06:25] [info] at
> org.apache.fop.fo.properties.PropertyCache.eq(PropertyCache.java:193)
> [2012-11-07 14:06:25] [info] at
> org.apache.fop.fo.properties.PropertyCache.fetch(PropertyCache.java:134)
> [2012-11-07 14:06:26] [info] at
> org.apache.fop.fo.properties.FontFamilyProperty$Maker.make(FontFamilyProperty.java:94)
> [2012-11-07 14:06:26] [info] at
> org.apache.fop.fo.PropertyList.convertAttributeToProperty(PropertyList.java:413)
> [2012-11-07 14:06:26] [info] at
> org.apache.fop.fo.PropertyList.addAttributesToList(PropertyList.java:321)
> [2012-11-07 14:06:26] [info] at
> org.apache.fop.fo.FObj.processNode(FObj.java:122)
> [2012-11-07 14:06:26] [info] at
> org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:280)
> [2012-11-07 14:06:26] [info] at
> org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:175)
> [2012-11-07 14:06:26] [info] at
> org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1073)
> [2012-11-07 14:06:26] [info] at
> org.apache.xml.serializer.TreeWalker.startNode(TreeWalker.java:359)
> [2012-11-07 14:06:26] [info] at
> org.apache.xml.serializer.TreeWalker.traverse(TreeWalker.java:145)
> [2012-11-
[jira] [Commented] (FOP-2157) Deadlock in CompareUtil class
[ https://issues.apache.org/jira/browse/FOP-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14747064#comment-14747064 ] Luis Bernardo commented on FOP-2157: I think you are right. The typo is present in the original patch and since the fix had been discussed and agreed here and the unit test passed I just applied the patch. I will correct it since the unit test still passes after the correction. > Deadlock in CompareUtil class > - > > Key: FOP-2157 > URL: https://issues.apache.org/jira/browse/FOP-2157 > Project: FOP > Issue Type: Bug > Components: unqualified >Affects Versions: trunk > Environment: Operating System: All > Platform: PC >Reporter: Matthias Reischenbacher >Assignee: Alexios Giotis > Fix For: trunk > > Attachments: FOP DEADLOCK jakarta_service_20121107.log, > FOP-2157-test.patch, FOP-2157.patch, report-dump.txt, thread-dump.txt > > > I'm getting a dead lock in the CompareUtil class, see the attached thread > dump. > Here small fragment of the thread dump > [2012-11-07 14:06:25] [info] Found one Java-level deadlock: > [2012-11-07 14:06:25] [info] = > [2012-11-07 14:06:25] [info] > [2012-11-07 14:06:25] [info] "http-80-exec-58": > [2012-11-07 14:06:25] [info] waiting to lock monitor 0x06ca9480 > [2012-11-07 14:06:25] [info] (object 0x00071fe9bd00, a java.util.Vector) > [2012-11-07 14:06:25] [info] , > which is held by "http-80-exec-5" > [2012-11-07 14:06:25] [info] > [2012-11-07 14:06:25] [info] "http-80-exec-5": > [2012-11-07 14:06:25] [info] waiting to lock monitor 0x116ecfc8 > [2012-11-07 14:06:25] [info] (object 0x00071fe9a000, a java.util.Vector) > [2012-11-07 14:06:25] [info] , > which is held by "http-80-exec-18" > [2012-11-07 14:06:25] [info] > [2012-11-07 14:06:25] [info] "http-80-exec-18": > [2012-11-07 14:06:25] [info] waiting to lock monitor 0x06ca9480 > [2012-11-07 14:06:25] [info] (object 0x00071fe9bd00, a java.util.Vector) > [2012-11-07 14:06:25] [info] , > which is held by "http-80-exec-5" > [2012-11-07 14:06:25] [info] > [2012-11-07 14:06:25] [info] > [2012-11-07 14:06:25] [info] Java stack information for the threads listed > above: > [2012-11-07 14:06:25] [info] > === > [2012-11-07 14:06:25] [info] "http-80-exec-58": > [2012-11-07 14:06:25] [info] at java.util.Vector.equals(Vector.java:925) > [2012-11-07 14:06:25] [info] - waiting to lock <0x00071fe9bd00> > [2012-11-07 14:06:25] [info] (a java.util.Vector) > [2012-11-07 14:06:25] [info] at > org.apache.fop.util.CompareUtil.equal(CompareUtil.java:38) > [2012-11-07 14:06:25] [info] at > org.apache.fop.fo.properties.ListProperty.equals(ListProperty.java:123) > [2012-11-07 14:06:25] [info] at > org.apache.fop.fo.properties.PropertyCache.eq(PropertyCache.java:193) > [2012-11-07 14:06:25] [info] at > org.apache.fop.fo.properties.PropertyCache.fetch(PropertyCache.java:134) > [2012-11-07 14:06:26] [info] at > org.apache.fop.fo.properties.FontFamilyProperty$Maker.make(FontFamilyProperty.java:94) > [2012-11-07 14:06:26] [info] at > org.apache.fop.fo.PropertyList.convertAttributeToProperty(PropertyList.java:413) > [2012-11-07 14:06:26] [info] at > org.apache.fop.fo.PropertyList.addAttributesToList(PropertyList.java:321) > [2012-11-07 14:06:26] [info] at > org.apache.fop.fo.FObj.processNode(FObj.java:122) > [2012-11-07 14:06:26] [info] at > org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:280) > [2012-11-07 14:06:26] [info] at > org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:175) > [2012-11-07 14:06:26] [info] at > org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1073) > [2012-11-07 14:06:26] [info] at > org.apache.xml.serializer.TreeWalker.startNode(TreeWalker.java:359) > [2012-11-07 14:06:26] [info] at > org.apache.xml.serializer.TreeWalker.traverse(TreeWalker.java:145) > [2012-11-07 14:06:26] [info] at > org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:390) > [2012-11-07 14:06:26] [info] at > smc.fop.FopWrapper.transform(FopWrapper.java:150) > [2012-11-07 14:06:26] [info] at > smc.fop.FopWrapper.transform(FopWrapper.java:125) > [2012-11-07 14:06:26] [info] at smc.plugin.Dom2PDF.process(Dom2PDF.java:179) > [2012-11-07 14:06:26] [info] at > sun.reflect.GeneratedMethodAccessor9
[jira] [Commented] (FOP-2157) Deadlock in CompareUtil class
[ https://issues.apache.org/jira/browse/FOP-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14790579#comment-14790579 ] Luis Bernardo commented on FOP-2157: fixed in http://svn.apache.org/viewvc?view=revision=1703427. > Deadlock in CompareUtil class > - > > Key: FOP-2157 > URL: https://issues.apache.org/jira/browse/FOP-2157 > Project: FOP > Issue Type: Bug > Components: unqualified >Affects Versions: trunk > Environment: Operating System: All > Platform: PC >Reporter: Matthias Reischenbacher >Assignee: Alexios Giotis > Fix For: trunk > > Attachments: FOP DEADLOCK jakarta_service_20121107.log, > FOP-2157-test.patch, FOP-2157.patch, report-dump.txt, thread-dump.txt > > > I'm getting a dead lock in the CompareUtil class, see the attached thread > dump. > Here small fragment of the thread dump > [2012-11-07 14:06:25] [info] Found one Java-level deadlock: > [2012-11-07 14:06:25] [info] = > [2012-11-07 14:06:25] [info] > [2012-11-07 14:06:25] [info] "http-80-exec-58": > [2012-11-07 14:06:25] [info] waiting to lock monitor 0x06ca9480 > [2012-11-07 14:06:25] [info] (object 0x00071fe9bd00, a java.util.Vector) > [2012-11-07 14:06:25] [info] , > which is held by "http-80-exec-5" > [2012-11-07 14:06:25] [info] > [2012-11-07 14:06:25] [info] "http-80-exec-5": > [2012-11-07 14:06:25] [info] waiting to lock monitor 0x116ecfc8 > [2012-11-07 14:06:25] [info] (object 0x00071fe9a000, a java.util.Vector) > [2012-11-07 14:06:25] [info] , > which is held by "http-80-exec-18" > [2012-11-07 14:06:25] [info] > [2012-11-07 14:06:25] [info] "http-80-exec-18": > [2012-11-07 14:06:25] [info] waiting to lock monitor 0x06ca9480 > [2012-11-07 14:06:25] [info] (object 0x00071fe9bd00, a java.util.Vector) > [2012-11-07 14:06:25] [info] , > which is held by "http-80-exec-5" > [2012-11-07 14:06:25] [info] > [2012-11-07 14:06:25] [info] > [2012-11-07 14:06:25] [info] Java stack information for the threads listed > above: > [2012-11-07 14:06:25] [info] > === > [2012-11-07 14:06:25] [info] "http-80-exec-58": > [2012-11-07 14:06:25] [info] at java.util.Vector.equals(Vector.java:925) > [2012-11-07 14:06:25] [info] - waiting to lock <0x00071fe9bd00> > [2012-11-07 14:06:25] [info] (a java.util.Vector) > [2012-11-07 14:06:25] [info] at > org.apache.fop.util.CompareUtil.equal(CompareUtil.java:38) > [2012-11-07 14:06:25] [info] at > org.apache.fop.fo.properties.ListProperty.equals(ListProperty.java:123) > [2012-11-07 14:06:25] [info] at > org.apache.fop.fo.properties.PropertyCache.eq(PropertyCache.java:193) > [2012-11-07 14:06:25] [info] at > org.apache.fop.fo.properties.PropertyCache.fetch(PropertyCache.java:134) > [2012-11-07 14:06:26] [info] at > org.apache.fop.fo.properties.FontFamilyProperty$Maker.make(FontFamilyProperty.java:94) > [2012-11-07 14:06:26] [info] at > org.apache.fop.fo.PropertyList.convertAttributeToProperty(PropertyList.java:413) > [2012-11-07 14:06:26] [info] at > org.apache.fop.fo.PropertyList.addAttributesToList(PropertyList.java:321) > [2012-11-07 14:06:26] [info] at > org.apache.fop.fo.FObj.processNode(FObj.java:122) > [2012-11-07 14:06:26] [info] at > org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:280) > [2012-11-07 14:06:26] [info] at > org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:175) > [2012-11-07 14:06:26] [info] at > org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1073) > [2012-11-07 14:06:26] [info] at > org.apache.xml.serializer.TreeWalker.startNode(TreeWalker.java:359) > [2012-11-07 14:06:26] [info] at > org.apache.xml.serializer.TreeWalker.traverse(TreeWalker.java:145) > [2012-11-07 14:06:26] [info] at > org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:390) > [2012-11-07 14:06:26] [info] at > smc.fop.FopWrapper.transform(FopWrapper.java:150) > [2012-11-07 14:06:26] [info] at > smc.fop.FopWrapper.transform(FopWrapper.java:125) > [2012-11-07 14:06:26] [info] at smc.plugin.Dom2PDF.process(Dom2PDF.java:179) > [2012-11-07 14:06:26] [info] at > sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source) > [2012-11-07 14:06:26] [info] at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > [2012-11-07 14:0
[jira] [Commented] (FOP-2157) Deadlock in CompareUtil class
[ https://issues.apache.org/jira/browse/FOP-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14790578#comment-14790578 ] Luis Bernardo commented on FOP-2157: fixed in http://svn.apache.org/viewvc?view=revision=1703427. > Deadlock in CompareUtil class > - > > Key: FOP-2157 > URL: https://issues.apache.org/jira/browse/FOP-2157 > Project: FOP > Issue Type: Bug > Components: unqualified >Affects Versions: trunk > Environment: Operating System: All > Platform: PC >Reporter: Matthias Reischenbacher >Assignee: Alexios Giotis > Fix For: trunk > > Attachments: FOP DEADLOCK jakarta_service_20121107.log, > FOP-2157-test.patch, FOP-2157.patch, report-dump.txt, thread-dump.txt > > > I'm getting a dead lock in the CompareUtil class, see the attached thread > dump. > Here small fragment of the thread dump > [2012-11-07 14:06:25] [info] Found one Java-level deadlock: > [2012-11-07 14:06:25] [info] = > [2012-11-07 14:06:25] [info] > [2012-11-07 14:06:25] [info] "http-80-exec-58": > [2012-11-07 14:06:25] [info] waiting to lock monitor 0x06ca9480 > [2012-11-07 14:06:25] [info] (object 0x00071fe9bd00, a java.util.Vector) > [2012-11-07 14:06:25] [info] , > which is held by "http-80-exec-5" > [2012-11-07 14:06:25] [info] > [2012-11-07 14:06:25] [info] "http-80-exec-5": > [2012-11-07 14:06:25] [info] waiting to lock monitor 0x116ecfc8 > [2012-11-07 14:06:25] [info] (object 0x00071fe9a000, a java.util.Vector) > [2012-11-07 14:06:25] [info] , > which is held by "http-80-exec-18" > [2012-11-07 14:06:25] [info] > [2012-11-07 14:06:25] [info] "http-80-exec-18": > [2012-11-07 14:06:25] [info] waiting to lock monitor 0x06ca9480 > [2012-11-07 14:06:25] [info] (object 0x00071fe9bd00, a java.util.Vector) > [2012-11-07 14:06:25] [info] , > which is held by "http-80-exec-5" > [2012-11-07 14:06:25] [info] > [2012-11-07 14:06:25] [info] > [2012-11-07 14:06:25] [info] Java stack information for the threads listed > above: > [2012-11-07 14:06:25] [info] > === > [2012-11-07 14:06:25] [info] "http-80-exec-58": > [2012-11-07 14:06:25] [info] at java.util.Vector.equals(Vector.java:925) > [2012-11-07 14:06:25] [info] - waiting to lock <0x00071fe9bd00> > [2012-11-07 14:06:25] [info] (a java.util.Vector) > [2012-11-07 14:06:25] [info] at > org.apache.fop.util.CompareUtil.equal(CompareUtil.java:38) > [2012-11-07 14:06:25] [info] at > org.apache.fop.fo.properties.ListProperty.equals(ListProperty.java:123) > [2012-11-07 14:06:25] [info] at > org.apache.fop.fo.properties.PropertyCache.eq(PropertyCache.java:193) > [2012-11-07 14:06:25] [info] at > org.apache.fop.fo.properties.PropertyCache.fetch(PropertyCache.java:134) > [2012-11-07 14:06:26] [info] at > org.apache.fop.fo.properties.FontFamilyProperty$Maker.make(FontFamilyProperty.java:94) > [2012-11-07 14:06:26] [info] at > org.apache.fop.fo.PropertyList.convertAttributeToProperty(PropertyList.java:413) > [2012-11-07 14:06:26] [info] at > org.apache.fop.fo.PropertyList.addAttributesToList(PropertyList.java:321) > [2012-11-07 14:06:26] [info] at > org.apache.fop.fo.FObj.processNode(FObj.java:122) > [2012-11-07 14:06:26] [info] at > org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:280) > [2012-11-07 14:06:26] [info] at > org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:175) > [2012-11-07 14:06:26] [info] at > org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1073) > [2012-11-07 14:06:26] [info] at > org.apache.xml.serializer.TreeWalker.startNode(TreeWalker.java:359) > [2012-11-07 14:06:26] [info] at > org.apache.xml.serializer.TreeWalker.traverse(TreeWalker.java:145) > [2012-11-07 14:06:26] [info] at > org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:390) > [2012-11-07 14:06:26] [info] at > smc.fop.FopWrapper.transform(FopWrapper.java:150) > [2012-11-07 14:06:26] [info] at > smc.fop.FopWrapper.transform(FopWrapper.java:125) > [2012-11-07 14:06:26] [info] at smc.plugin.Dom2PDF.process(Dom2PDF.java:179) > [2012-11-07 14:06:26] [info] at > sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source) > [2012-11-07 14:06:26] [info] at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > [2012-11-07 14:0
[jira] [Resolved] (FOP-2489) An SVG file using markers is not rendered by FOP 2.0
[
https://issues.apache.org/jira/browse/FOP-2489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luis Bernardo resolved FOP-2489.
Resolution: Fixed
Fix Version/s: trunk
Fixed on the Batik side instead:
http://svn.apache.org/viewvc?view=revisionrevision=1687506 and
http://svn.apache.org/viewvc?view=revisionrevision=1687510.
An SVG file using markers is not rendered by FOP 2.0
Key: FOP-2489
URL: https://issues.apache.org/jira/browse/FOP-2489
Project: FOP
Issue Type: Bug
Affects Versions: 2.0
Environment: Linux; Java 1.6 64-bit (not relevant).
Reporter: Hussein Shafie
Fix For: trunk
Attachments: EXPECTED__doc.pdf, __doc.fo, __doc.pdf, header_layout.svg
h4. An SVG file using markers is not rendered by FOP 2.0
How to reproduce the problem (see attached files)
fop -fo __doc.fo -pdf __doc.pdf
Running this command reports:
{noformat}
SEVERE: SVG graphic could not be built. Reason:
org.apache.batik.bridge.BridgeException:
resources/resources/header_layout.svg (No such file or directory)
org.apache.batik.bridge.BridgeException:
resources/resources/header_layout.svg (No such file or directory)
at org.apache.batik.bridge.BridgeContext.getReferencedNode(Unknown
Source)
at org.apache.batik.bridge.BridgeContext.getReferencedElement(Unknown
Source)
at org.apache.batik.bridge.PaintServer.convertMarker(Unknown Source)
at org.apache.batik.bridge.PaintServer.convertMarkers(Unknown Source)
at
org.apache.batik.bridge.SVGDecoratedShapeElementBridge.createMarkerPainter(Unknown
Source)
at
org.apache.batik.bridge.SVGDecoratedShapeElementBridge.createShapePainter(Unknown
Source)
at
org.apache.batik.bridge.SVGShapeElementBridge.buildGraphicsNode(Unknown
Source)
at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown
Source)
at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source)
at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown
Source)
at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source)
at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown
Source)
at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source)
at org.apache.batik.bridge.GVTBuilder.build(Unknown Source)
at
org.apache.fop.render.pdf.PDFImageHandlerSVG.handleImage(PDFImageHandlerSVG.java:103)
at
org.apache.fop.render.intermediate.AbstractIFPainter.drawImage(AbstractIFPainter.java:249)
at
org.apache.fop.render.intermediate.AbstractIFPainter.drawImage(AbstractIFPainter.java:205)
at
org.apache.fop.render.intermediate.AbstractIFPainter.drawImageUsingImageHandler(AbstractIFPainter.java:170)
at
org.apache.fop.render.intermediate.AbstractIFPainter.drawImageUsingURI(AbstractIFPainter.java:292)
at org.apache.fop.render.pdf.PDFPainter.drawImage(PDFPainter.java:173)
at
org.apache.fop.render.intermediate.IFRenderer.drawImage(IFRenderer.java:1295)
at
org.apache.fop.render.intermediate.IFRenderer.renderImage(IFRenderer.java:1282)
at
org.apache.fop.render.AbstractRenderer.renderInlineViewport(AbstractRenderer.java:858)
{noformat}
The expected result is EXPECTED__doc.pdf
My workaround:
To resolve URLs such as marker-start:url(#TriangleInM), Batik 1.8 needs
to know the URL of the SVG document it processes.
Therefore in org/apache/fop/apps/FOUserAgent.java, I've replaced:
{noformat}
public StreamSource resolveURI(String uri) {
// TODO: What do we want to do when resources aren't found??? We also
need to remove this
// method entirely
try {
// Have to do this so we can resolve data URIs
StreamSource src = new
StreamSource(resourceResolver.getResource(uri));
src.setSystemId(uri);
return src;
} catch (URISyntaxException use) {
return null;
} catch (IOException ioe) {
return null;
}
}
{noformat}
by:
{noformat}
public StreamSource resolveURI(String uri) {
// TODO: What do we want to do when resources aren't found??? We also
need to remove this
// method entirely
try {
// Have to do this so we can resolve data URIs
StreamSource src = new
StreamSource(resourceResolver.getResource(uri));
// A systemId is always expected to be absolute.
// Anyway, without this, SVG files using markers
// (e.g. marker-start:url(#TriangleInM)) cannot be rendered.
if (!uri.startsWith(data:)) {
uri =
resourceResolver.getBaseURI().resolve(uri).toASCIIString
[jira] [Commented] (FOP-2485) Xalan dependency should be updated
[
https://issues.apache.org/jira/browse/FOP-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601233#comment-14601233
]
Luis Bernardo commented on FOP-2485:
It seems xalan 2.7.2 needs xercesImpl 2.9.1 (which then pulls xml-apis 1.3.04).
So we need to update xercesImpl to 2.9.1 too. Do you agree?
Xalan dependency should be updated
--
Key: FOP-2485
URL: https://issues.apache.org/jira/browse/FOP-2485
Project: FOP
Issue Type: Wish
Affects Versions: 2.0
Reporter: Jochen Kemnade
Fop 2.0 depends on Xalan 2.7.0 via {{batik-dom}}. Xalan 2.7.0 pulls in
{{xml-apis:2.0.2}}. That one overrides {{xml-apis:1.3.04}}, which is actually
*newer*. (see
http://swordsystems.com/2011/06/29/xerces-and-xml-api-dependency-hell/).
Updating Xalan to 2.7.2 fixes the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
xercesImpl dependency
Does anyone know why we have the xercesImpl jar in the lib directory? Apparently we don't need it to compile and run the unit tests. This is unlike xalan which we need for the unit tests. Can this jar be removed?
[jira] [Resolved] (FOP-2490) Embedded SVG 1.2 not supported by FOP 2.0
[
https://issues.apache.org/jira/browse/FOP-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luis Bernardo resolved FOP-2490.
Resolution: Fixed
Fix Version/s: trunk
Fix applied in http://svn.apache.org/viewvc?view=revisionrevision=1687458.
Embedded SVG 1.2 not supported by FOP 2.0
-
Key: FOP-2490
URL: https://issues.apache.org/jira/browse/FOP-2490
Project: FOP
Issue Type: Bug
Affects Versions: 2.0
Environment: Linux, Java 1.6 64-bit (not relevant)
Reporter: Hussein Shafie
Fix For: trunk
Attachments: EXPECTED__doc.pdf, __doc.fo
h4. Embedded SVG 1.2 not supported by FOP 2.0
How to reproduce the problem (see attached files)
fop -fo __doc.fo -pdf __doc.pdf
Running this command fails with:
{noformat}
org.w3c.dom.DOMException: The current document is unable to create an element
of the requested type (namespace: http://www.w3.org/2000/svg, name:
svg:flowRoot).
at org.apache.batik.dom.AbstractNode.createDOMException(Unknown
Source)
at
org.apache.batik.anim.dom.SVGDOMImplementation.createElementNS(Unknown Source)
at org.apache.batik.anim.dom.SVGOMDocument.createElementNS(Unknown
Source)
at org.apache.xml.utils.DOMBuilder.startElement(DOMBuilder.java:324)
at
org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072)
at
org.apache.fop.util.DelegatingContentHandler.startElement(DelegatingContentHandler.java:185)
at
org.apache.fop.fo.extensions.svg.SVGDOMContentHandlerFactory$Handler.startElement(SVGDOMContentHandlerFactory.java:137)
at
org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:179)
at
org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072)
{noformat}
The expected result is EXPECTED__doc.pdf
My workaround:
In org/apache/fop/fo/extensions/svg/SVGDOMContentHandlerFactory.java,
I've replaced:
{noformat}
private DOMImplementation getDOMImplementation(String ver) {
//TODO It would be great if Batik provided this method as static
helper method.
if (ver == null || ver.length() == 0
|| ver.equals(1.0) || ver.equals(1.1)) {
return SVGDOMImplementation.getDOMImplementation();
} else if (ver.equals(1.2)) {
try {
Class clazz = Class.forName(
org.apache.batik.dom.svg12.SVG12DOMImplementation);
return (DOMImplementation)clazz.getMethod(
getDOMImplementation,
(Class[])null).invoke(null, (Object[])null);
} catch (Exception e) {
return SVGDOMImplementation.getDOMImplementation();
}
}
throw new RuntimeException(Unsupport SVG version ' + ver + ');
}
{noformat}
by:
{noformat}
import org.apache.batik.anim.dom.SVG12DOMImplementation;
private DOMImplementation getDOMImplementation(String ver) {
//TODO It would be great if Batik provided this method as static
helper method.
if (ver == null || ver.length() == 0
|| ver.equals(1.0) || ver.equals(1.1)) {
return SVGDOMImplementation.getDOMImplementation();
} else if (ver.equals(1.2)) {
return SVG12DOMImplementation.getDOMImplementation();
}
throw new RuntimeException(Unsupport SVG version ' + ver + ');
}
{noformat}
org.apache.batik.anim.dom.SVG12DOMImplementation is always
included in Batik-1.8-all.jar. Even if you prefer to keep Class.forName(),
please note that org.apache.batik.dom.svg12.SVG12DOMImplementation
no longer exists in Batik 1.8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FOP-2060) adjoining blocks with break-before=page break-after=page cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14576471#comment-14576471 ] Luis Bernardo commented on FOP-2060: OK, you are correct. It should be 3 pages. adjoining blocks with break-before=page break-after=page cause extra empty page --- Key: FOP-2060 URL: https://issues.apache.org/jira/browse/FOP-2060 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Luis Bernardo Fix For: trunk Attachments: 2060-empty-block-issue.xml, test.fo, test.pdf This causes five pages instead of four: fo:block fo:blockpage 1/fo:block fo:block break-before=page break-after=pagepage 2/fo:block fo:block break-before=page break-after=pagepage 3/fo:block fo:blockpage 4/fo:block /fo:block The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2060) adjoining blocks with break-before=page break-after=page cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14575276#comment-14575276 ] Luis Bernardo commented on FOP-2060: Not adding the empty box in the first place is a good thing. I didn't do it because removing it later seemed simpler to implement. But I am confused about the relevance of the 2060-empty-block-issue.xml example... The correct output should be 2 pages, not 3, so I think the fix stands. Comments? adjoining blocks with break-before=page break-after=page cause extra empty page --- Key: FOP-2060 URL: https://issues.apache.org/jira/browse/FOP-2060 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Luis Bernardo Fix For: trunk Attachments: 2060-empty-block-issue.xml, test.fo, test.pdf This causes five pages instead of four: fo:block fo:blockpage 1/fo:block fo:block break-before=page break-after=pagepage 2/fo:block fo:block break-before=page break-after=pagepage 3/fo:block fo:blockpage 4/fo:block /fo:block The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2060) adjoining blocks with break-before=page break-after=page cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14575384#comment-14575384 ] Luis Bernardo commented on FOP-2060: I still stand by my comment. The statement from the page I provided is the following: There is nothing in the XSL 1.1 Recommendation that has an fo:block generating an empty area before jumping to the next page. It doesn't say anything about nested blocks. I think it is more general than that. For me it makes sense because in general, for the situations where you want an empty page, you can use the blank-or-not-blank property. Similarly, you cannot start a document with an empty page by starting the document with a: fo:block break-before=page/fo:block Also, the following should not add an empty page: fo:block break-before=page break-after=page/fo:block adjoining blocks with break-before=page break-after=page cause extra empty page --- Key: FOP-2060 URL: https://issues.apache.org/jira/browse/FOP-2060 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Luis Bernardo Fix For: trunk Attachments: 2060-empty-block-issue.xml, test.fo, test.pdf This causes five pages instead of four: fo:block fo:blockpage 1/fo:block fo:block break-before=page break-after=pagepage 2/fo:block fo:block break-before=page break-after=pagepage 3/fo:block fo:blockpage 4/fo:block /fo:block The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: FOP Committer
Matthias, it is also expected that you will update your entry in the http://xmlgraphics.apache.org/fop/team.html page. For that you can use the CMS bookmarklet (see http://www.apache.org/dev/cms.html). On 5/20/15 12:35 PM, Matthias Reischenbacher wrote: Hi Chris, thanks! As Andreas suggested I'll test the SVN access in a few days with https://issues.apache.org/jira/browse/FOP-2465. Best, Matthias On 18.05.2015 12:06, Chris Bowditch wrote: Hi Matthias, Apologies for the delay in coming back you but I was struck with the bug for a few days :-( I've updated the SVN Auth file, so you should be able to commit now. Welcome to the team Thanks, Chris On 13/05/2015 20:58, Matthias Reischenbacher wrote: Hi Chris, thanks! The account has been created in the meanwhile and is already functional. Matthias On 13.05.2015 09:58, Chris Bowditch wrote: Hi Matthias, I've submitted the new account request to infra. As soon as infra respond I'll grant SVN access and let you know. In the meantime here is some background reading for new committers: http://www.apache.org/dev/new-committers-guide.html http://www.apache.org/dev/committers.html Thanks, Chris On 12/05/2015 14:26, Matthias Reischenbacher wrote: Hi Chris, wow, I didn't expect that, but of course I'm happy to accept committership. My preferred userid would be: matthias I checked on http://people.apache.org/committer-index.html#M and it should be still available. Thanks, Matthias On 12.05.2015 08:43, Chris Bowditch wrote: Hi Matthias, The XMLGraphics PMC has voted to grant you the rights of committership on the FOP project. If you accept can you let me know your preferred userid so I can create your account? Thanks, Chris
[jira] [Resolved] (FOP-2477) Non uniform cell borders in complex table
[ https://issues.apache.org/jira/browse/FOP-2477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2477. Resolution: Duplicate Non uniform cell borders in complex table - Key: FOP-2477 URL: https://issues.apache.org/jira/browse/FOP-2477 Project: FOP Issue Type: Bug Affects Versions: 1.1, trunk Reporter: Jan Tošovský Priority: Minor Attachments: table-border-expected.png, table-border.fo, table-border.png In complex tables with spanned cells the border is not rendered by the same thickness, which is apparent mainly when borders are anti-aliased if page is scaled down. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: JIRA access
You need to be added to one of the roles that is able to resolve issues before you can do that. For FOP and XGC only Glenn has admin rights. For BATIK both Glenn and I have. On 5/24/15 12:47 PM, Andreas Delmelle wrote: Hi Just wondering: Should I be able to set JIRA issues to 'Resolved' or assign them to myself, or does this require someone else (Glenn?) to provide me with the appropriate permissions first? If the latter, can you take care of this? Thanks! KR Andreas
Re: [jira] [Commented] (FOP-2469) [PATCH] auto table layout
Try now (it should work if your account is AndreasDelmelle). We had to put some ACLs in place due to spam. Should work for Gregor too. On 5/19/15 8:47 PM, Andreas Delmelle wrote: On 19 May 2015, at 19:45, Andreas Delmelle andreas.delme...@telenet.be wrote: snip / If anyone on with the appropriate karma is reading this: Can you please assist Gregor? If I should be able to help him out myself, please let me know what I can/should do, so that I can take care of it myself. Thanks! Hmm... Seems I may have some more catching up to do. I restored my old account, and cannot even seem to update any pages myself. It just shows 'Immutable Page' everywhere. Should this still be working? KR Andreas
[jira] [Commented] (FOP-2469) [PATCH] auto table layout
[ https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14551176#comment-14551176 ] Luis Bernardo commented on FOP-2469: We know the implementation is suboptimal if performance is your yardstick. But the end result is almost optimal, as far as the algorithm goes (except that the algorithm assumes constant width). An approach like the one suggested would lead to better performance, but potentially could result in suboptimal end result (although most if the time it would be OK). [PATCH] auto table layout - Key: FOP-2469 URL: https://issues.apache.org/jira/browse/FOP-2469 Project: Fop Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Windows 7, JDK 7 Reporter: Gregor Berg Fix For: trunk Attachments: 2015-05-13-auto-table-layout.patch, FOP2469-auto-table-layout.xml Hi, this is a patch which enables table-layout=auto. It is quite robust, it can not only handle linebreaks and pagebreaks, but it also copes with auto tables in fixed tables in auto tables. Essentially, it is the patch of issue FOP-2450 adapted to the trunk version of FOP. Best regards, Gregor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FOP-2347) insufficient data for an image on generated pdf file
[ https://issues.apache.org/jira/browse/FOP-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2347. Resolution: Duplicate insufficient data for an image on generated pdf file -- Key: FOP-2347 URL: https://issues.apache.org/jira/browse/FOP-2347 Project: Fop Issue Type: Bug Components: image/unqualified Affects Versions: trunk Environment: Windows, Command line Reporter: lee liao Labels: patch Fix For: trunk Attachments: chart.tif, graphicinlistblock.fo, madebyfop-20130221.pdf, madebyfop-20140221.pdf Hi There, Acrobat reader XI shows insufficient data for an image on image page for generated pdf. The issue happens on recent nightly snapshot(fop-20140221) and not in nightly snapshot one year ago(fop-20130221). Some bugs got in the source on someday in last year. Please found the attachments of fo file, image file and generated pdf files made by the two nightly snapshot version. The way to reproduce the issue is easy. After setup correct PATH in Windows Dos console, submit the command fop.bat -fo graphicinlistblock.fo -pdf madebyfop-2014.pdf Best regards, Lee -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (FOP-2347) insufficient data for an image on generated pdf file
[ https://issues.apache.org/jira/browse/FOP-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo reopened FOP-2347: need to change resolution... insufficient data for an image on generated pdf file -- Key: FOP-2347 URL: https://issues.apache.org/jira/browse/FOP-2347 Project: Fop Issue Type: Bug Components: image/unqualified Affects Versions: trunk Environment: Windows, Command line Reporter: lee liao Labels: patch Fix For: trunk Attachments: chart.tif, graphicinlistblock.fo, madebyfop-20130221.pdf, madebyfop-20140221.pdf Hi There, Acrobat reader XI shows insufficient data for an image on image page for generated pdf. The issue happens on recent nightly snapshot(fop-20140221) and not in nightly snapshot one year ago(fop-20130221). Some bugs got in the source on someday in last year. Please found the attachments of fo file, image file and generated pdf files made by the two nightly snapshot version. The way to reproduce the issue is easy. After setup correct PATH in Windows Dos console, submit the command fop.bat -fo graphicinlistblock.fo -pdf madebyfop-2014.pdf Best regards, Lee -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FOP-2470) [PDF] TIFF image encoding error
[ https://issues.apache.org/jira/browse/FOP-2470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2470. Resolution: Duplicate [PDF] TIFF image encoding error --- Key: FOP-2470 URL: https://issues.apache.org/jira/browse/FOP-2470 Project: Fop Issue Type: Bug Components: image/tiff, renderer/pdf Affects Versions: trunk Reporter: Seifeddine Dridi Attachments: Vinfdy2pi2012_b.TIF, tiff_encoding_error.fo, tiff_encoding_error.pdf With certain TIFF images (like the one attached below), FOP does not correctly transcode image data to the output PDF document. Adobe Reader prints Unsufficient data for an image whenever the document is opened. After a quick investigation, the issue appears to be related to the changes made here https://issues.apache.org/jira/browse/FOP-2259. P.S. Sorry for the large image size but I couldn't find a smaller image that can reproduce the issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: FOP Committer
We are pleased to have you on board. Welcome! On 5/12/15 3:26 PM, Matthias Reischenbacher wrote: Hi Chris, wow, I didn't expect that, but of course I'm happy to accept committership. My preferred userid would be: matthias I checked on http://people.apache.org/committer-index.html#M and it should be still available. Thanks, Matthias On 12.05.2015 08:43, Chris Bowditch wrote: Hi Matthias, The XMLGraphics PMC has voted to grant you the rights of committership on the FOP project. If you accept can you let me know your preferred userid so I can create your account? Thanks, Chris
Re: [jira] [Updated] (FOP-1488) [PATCH] orphans/widows not respected in some cases
Andreas, you should still have commit rights, and you are welcome to commit the patches. On 5/2/15 10:56 PM, Andreas L. Delmelle (JIRA) wrote: [ https://issues.apache.org/jira/browse/FOP-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-1488: - Attachment: (was: FOP-1488-code.patch) [PATCH] orphans/widows not respected in some cases -- Key: FOP-1488 URL: https://issues.apache.org/jira/browse/FOP-1488 Project: Fop Issue Type: Bug Components: unqualified Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Andrew McFarland Attachments: FOP-1488-code.patch, FOP-1488-test.patch, b44328.patch, b44328.patch, b44328.patch, b44328.patch, b44328.patch, b44328.patch, b44328.patch, b44328_test.patch, block_orphans_widows.fo, block_orphans_widows.fo, block_orphans_widows.fo, block_orphans_widows.fo, block_orphans_widows.fo, widow.fo When I process the following fo, I get a PDF with a one-line widow at the start of the second page, even though widows for that fo:block is set to 4. ?xml version=1.0 encoding=ISO-8859-1? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=A4 fo:region-body / /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=A4 fo:flow flow-name=xsl-region-body fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:block widows=4 linefeed-treatment=preserve line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line /fo:block /fo:flow /fo:page-sequence /fo:root -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: FOP Release
I think that maven will be embraced as soon as there is a volunteer to do the transition. On 4/22/15 6:13 PM, Glenn Adams wrote: On Wed, Apr 22, 2015 at 9:40 AM, Chris Bowditch bowditch_ch...@hotmail.com mailto:bowditch_ch...@hotmail.com wrote: I agree, but as Simon pointed out PDFBox is not a dependency of FOP, but of PDF plug-in, which is a separate project with a separate release cycle. The PDF plug-in project is an optional dependency of FOP, not required for core functionality. So the proposal is just to release the FOP project, not PDF plug-in. This means anyone wishing to use PDF-plugin with the new release of FOP would need to build it from source code using a PDFBox snaphot. Not ideal, but we are long overdue a FOP release, and only a small number of users are using the PDF plug-in. So I'm +1 to this proposal. ok; that works for me... on another point, when can we transition to maven? our ant configurations are difficult to maintain and understand; we should modernize Thanks, Chris On 22/04/2015 14:28, Glenn Adams wrote: I'm not comfortable requiring use of a snapshot dependency. For example, that would prevent deployment to maven central. On Wed, Apr 22, 2015 at 1:18 AM, Chris Bowditch bowditch_ch...@hotmail.com mailto:bowditch_ch...@hotmail.com mailto:bowditch_ch...@hotmail.com mailto:bowditch_ch...@hotmail.com wrote: Hi Glen, Its expected that a -1 vote includes a justification. You may well be right, but we are not mind readers and have no idea what you are thinking... Thanks, Chris On 21/04/2015 16:32, Glenn Adams wrote: -1 On Tue, Apr 21, 2015 at 9:21 AM, Simon Steiner simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com wrote: Hi, Since Batik and XGC have been released, are we ready to release FOP? It has been said we can’t release PDF plugin using a snapshot release of PDFBox 2.0. PDFBox 1.8 is missing font parsing libraries we need for font merging. We could make release a PDF plugin beta release using snapshot of PDFBox or ask user to use PDF plugin snapshot version with FOP 2.0. Thanks
Re: Maven
Maybe I only spoke for myself, but I am in: +1 From what I understand publishing the source jars to maven central would be automatic then, since there is some plugin for that. Given the fact that I have spent many hours adapting the Batik ant file to produce the source jars for maven central (I am still in the process of checking the result is correct) any steps that help with that in the future (be either for FOP or Batik) are welcome. On 4/22/15 6:35 PM, Glenn Adams wrote: On Wed, Apr 22, 2015 at 10:31 AM, Luis Bernardo lmpmberna...@gmail.com mailto:lmpmberna...@gmail.com wrote: I think that maven will be embraced as soon as there is a volunteer to do the transition. A few years ago I went through the process of creating a full maven configuration for FOP; however, the group was not ready to make the transition at that time. I have recently converted another multiple-module internal project to maven from ant, and would be able to repeat the process on fop. However, I don't want to do it unless there is support to switch over. On 4/22/15 6:13 PM, Glenn Adams wrote: on another point, when can we transition to maven? our ant configurations are difficult to maintain and understand; we should modernize
Re: FOP Release
When I suggested releasing Batik back in December, Glenn mentioned that he wanted to fix some issues (namely https://issues.apache.org/jira/browse/FOP-2391) before releasing FOP 2.0. I assume this is the reason for -1, but I agree that a justification would help since not everyone may remember what was discussed in December. On 4/22/15 9:18 AM, Chris Bowditch wrote: Hi Glen, Its expected that a -1 vote includes a justification. You may well be right, but we are not mind readers and have no idea what you are thinking... Thanks, Chris On 21/04/2015 16:32, Glenn Adams wrote: -1 On Tue, Apr 21, 2015 at 9:21 AM, Simon Steiner simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com wrote: Hi, Since Batik and XGC have been released, are we ready to release FOP? It has been said we can’t release PDF plugin using a snapshot release of PDFBox 2.0. PDFBox 1.8 is missing font parsing libraries we need for font merging. We could make release a PDF plugin beta release using snapshot of PDFBox or ask user to use PDF plugin snapshot version with FOP 2.0. Thanks
[jira] [Updated] (FOP-2250) Arabic characters are not connected on PCL
[ https://issues.apache.org/jira/browse/FOP-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo updated FOP-2250: --- Attachment: fop-courier.xconf arabic-trunk.pdf arabic-trunk.pcl The output from trunk (arabic-trunk.pcl) is attached, together with its conversion to pdf. Is the out put wrong? The fop.xconf attached to the issue has no fonts configured so you should not expect much if you use it... Attached is fop-courier.xconf which has the font configured. Arabic characters are not connected on PCL -- Key: FOP-2250 URL: https://issues.apache.org/jira/browse/FOP-2250 Project: Fop Issue Type: Bug Affects Versions: 1.1 Environment: Windows 7, x64 Reporter: Konrad Gajewski Attachments: PCL_issue.jpg, arabic-trunk.pcl, arabic-trunk.pdf, arabic.fo, arabic.pcl, arabic.pcl.pdf, fop-courier.xconf, fop.xconf, test2.pdf Hi, When I try to print document on HP printer, Arabic characters are not printed correctly. They should be connected. regards, Konrad Gajewski -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Merge Temp_PDFLinearization to trunk
Thanks. Looks very good. +1 On 2/16/15 12:23 PM, Simon Steiner wrote: Hi, I updated the branch to fix issue. Thanks *From:*Luis Bernardo [mailto:lmpmberna...@gmail.com] *Sent:* 15 February 2015 14:46 *To:* fop-dev@xmlgraphics.apache.org *Subject:* Re: [VOTE] Merge Temp_PDFLinearization to trunk Good work Simon. It seems to work in general but I got an NPE: java.lang.NullPointerException at java.util.LinkedList.addAll(LinkedList.java:406) at java.util.LinkedList.addAll(LinkedList.java:385) at org.apache.fop.pdf.PDFLinearization.outputPages(PDFLinearization.java:246) at org.apache.fop.render.pdf.PDFContentGenerator.flushPDFDoc(PDFContentGenerator.java:153) at org.apache.fop.render.pdf.PDFPainter.flushPDFDoc(PDFPainter.java:237) at org.apache.fop.render.pdf.PDFPainter.drawImage(PDFPainter.java:231) at org.apache.fop.render.intermediate.IFRenderer.renderForeignObject(IFRenderer.java:1308) at org.apache.fop.render.AbstractRenderer.renderInlineViewport(AbstractRenderer.java:861) at org.apache.fop.render.AbstractPathOrientedRenderer.renderInlineViewport(AbstractPathOrientedRenderer.java:832) at org.apache.fop.render.intermediate.IFRenderer.renderInlineViewport(IFRenderer.java:862) at org.apache.fop.render.AbstractRenderer.renderInlineArea(AbstractRenderer.java:714) .. with: examples/fo/advanced/giro.fo I suggest we get this working with all fo files in the examples directory before we merge this to trunk. On 2/10/15 11:54 AM, Simon Steiner wrote: Hi, Vote to merge PDF Linearization branch to trunk. Linearization is helpful to allow viewing of a pdf over a slow connection. Feature will be disabled by default, can be enabled with fop version=1.0 renderers renderer mime=application/pdf linearizationtrue/linearization /renderer /renderers /fop The vote will last 5 working days, ending next Tuesday. https://issues.apache.org/jira/browse/FOP-2445 https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_PDFLinearization Here is my vote: +1 Thanks
Re: [VOTE] Merge Temp_PDFLinearization to trunk
Good work Simon. It seems to work in general but I got an NPE: java.lang.NullPointerException at java.util.LinkedList.addAll(LinkedList.java:406) at java.util.LinkedList.addAll(LinkedList.java:385) at org.apache.fop.pdf.PDFLinearization.outputPages(PDFLinearization.java:246) at org.apache.fop.render.pdf.PDFContentGenerator.flushPDFDoc(PDFContentGenerator.java:153) at org.apache.fop.render.pdf.PDFPainter.flushPDFDoc(PDFPainter.java:237) at org.apache.fop.render.pdf.PDFPainter.drawImage(PDFPainter.java:231) at org.apache.fop.render.intermediate.IFRenderer.renderForeignObject(IFRenderer.java:1308) at org.apache.fop.render.AbstractRenderer.renderInlineViewport(AbstractRenderer.java:861) at org.apache.fop.render.AbstractPathOrientedRenderer.renderInlineViewport(AbstractPathOrientedRenderer.java:832) at org.apache.fop.render.intermediate.IFRenderer.renderInlineViewport(IFRenderer.java:862) at org.apache.fop.render.AbstractRenderer.renderInlineArea(AbstractRenderer.java:714) .. with: examples/fo/advanced/giro.fo I suggest we get this working with all fo files in the examples directory before we merge this to trunk. On 2/10/15 11:54 AM, Simon Steiner wrote: Hi, Vote to merge PDF Linearization branch to trunk. Linearization is helpful to allow viewing of a pdf over a slow connection. Feature will be disabled by default, can be enabled with fop version=1.0 renderers renderer mime=application/pdf linearizationtrue/linearization /renderer /renderers /fop The vote will last 5 working days, ending next Tuesday. https://issues.apache.org/jira/browse/FOP-2445 https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_PDFLinearization Here is my vote: +1 Thanks
Re: [VOTE] Merge Temp_MergeTaggedPDF to trunk
Given the fact that fop-pdf-images (including this branch) uses pdfbox 2.0 snapshots while fop trunk uses 1.8.5 (the fontbox jar) I think we need some information on how to test this. I thought that using the recent pdfbox 1.8.8 jars would work but it doesn't seem to be the case. What version of pdfbox jars should we use with fop? Also, I would like to suggest that if we run two votes in parallel then 5 working days for both votes may not be enough... On 2/10/15 11:04 AM, Simon Steiner wrote: Hi, Thanasis Giannimaras provided patch to merge Tagged PDF for pdf plugin and small patch for fop. Known Limitations : - Only PDF with marked-content sequences in the page content stream are supported. Marked-content sequences in content stream other than the content stream of the page are not supported. - Repeated headers and footers are not completely supported. Example: 2-page pdf including table that spans both pages with repeated header. If you merge the second page, the table header will be visible in the pdf but the reader will ignore it (same principle applies for repeated footers). In order to use this feature, accessibility must be enabled in the configuration file and the source pdf must be accessible (tagged). The vote will last 5 working days, ending next Tuesday. https://issues.apache.org/jira/browse/FOP-2436 https://svn.apache.org/repos/asf/xmlgraphics/fop-pdf-images/branches/Temp_MergeTaggedPDF Here is my vote: +1 Thanks
[jira] [Resolved] (FOP-2367) [Patch] Support for color space OCA
[ https://issues.apache.org/jira/browse/FOP-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2367. Resolution: Implemented patch applied: http://svn.apache.org/viewvc?view=revisionrevision=1658659 (with fixes for checkstyle, and brown color values) note: I have no AFP printer to check this but I assume the patch author checked it... [Patch] Support for color space OCA --- Key: FOP-2367 URL: https://issues.apache.org/jira/browse/FOP-2367 Project: Fop Issue Type: Improvement Affects Versions: trunk Reporter: Seifeddine Dridi Priority: Minor Labels: patch Fix For: trunk Attachments: oca-test.fo, ocacolor.patch Hello, I added support for color space OCA. OCA is used in AFP to set text foreground color and it is still useful in old AFP printers that have a limited support for color or don't support other color spaces (RGB, CMYK, etc...). Seifeddine -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jira] [Updated] (FOP-2441) pdf:embedded-file extension is broken, gives NullPointerException
It is not linked. Anyone can create a Jira account. Glenn has admin rights for the FOP project in Jira and he needs to add you as a developer so that you can resolve issues. On 1/26/15 10:28 PM, Luca Furini wrote: One last question (please be patient :-) ): how is my newly created Jira account linked to the apache one? Will I have to configure something (once my commit access is in order)?
Re: [jira] [Updated] (FOP-2441) pdf:embedded-file extension is broken, gives NullPointerException
I see. Chris is the PMC chair and may be able to explain/fix it. On 1/24/15 8:42 PM, Luca Furini wrote: Luis Bernardo wrote: I am under the impression that committership rights are never revoked but I could be wrong. Are you sure that you can log in to your Apache account? Maybe a year ago or so Apache forced a change in passwords. Did you change your password when that happened? Yes, I remember changing the password when requested. When I try to commit I get a 403 forbidden error message after being requested username and password (by comparison, if I enter a wrong username / password I keep being asked to enter them correctly). I think my apache account still exists as I can log in to https://id.apache.org, and I'm in the commiters list at http://people.apache.org/committer-index.html#lfurini (although I'm not assigned to any svn projects). On the other hand I have been inactive for several years, so I wouldn't be surprised or offended if someone / an authomatic procedure revoked my powers ... So ... does anyone has any ideas? :-) Bye Luca
Re: [jira] [Updated] (FOP-2441) pdf:embedded-file extension is broken, gives NullPointerException
Welcome back Luca! I am under the impression that committership rights are never revoked but I could be wrong. Are you sure that you can log in to your Apache account? Maybe a year ago or so Apache forced a change in passwords. Did you change your password when that happened? On 1/23/15 11:33 PM, Luca Furini (JIRA) wrote: [ https://issues.apache.org/jira/browse/FOP-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Furini updated FOP-2441: - Attachment: change.diff Proposed patch pdf:embedded-file extension is broken, gives NullPointerException - Key: FOP-2441 URL: https://issues.apache.org/jira/browse/FOP-2441 Project: Fop Issue Type: Bug Components: renderer/pdf Affects Versions: trunk Reporter: Luca Furini Priority: Minor Attachments: change.diff, test_attachment.fo The extension property pdf:embedded-file (to attach files to the pdf) is not working, and generates a NullPointerException. I noticed the problem while trying to write an answer to this StackOverflow question: http://stackoverflow.com/questions/28110607/unable-to-add-an-attachment-to-a-pdf-while-using-fop (the question is about a different problem, but while testing on fop-trunk I noticed this bug I'm reporting). Looking at the revision history, I think the implementation of this extension has been broken since revision [1522934]. I'm going to attach a simple fo file showing the problem, together with a proposed patch. I have been a fop committer for some time, followed by a looong period of just lurking the mailing list; I tried to commit the changes myself, but I guess my long inactivity period has caused the revocation of my commit privileges. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: fop-pdf-images question regarding pdfbox Version/Patch
The patches to pdfbox 1.8.4 were deemed not necessary after changes were made to fop to not need them. So they were removed with the upgrade to 1.8.5. We could create a branch but right now it would be the same as the commit Simon mentions. If you have problems replacing 1.8.5 by 1.8.8 please ask in fop-users for a new branch and if there is interest from other users we will create one. On 1/22/15 10:05 AM, Simon Steiner wrote: Hi, For now you can check out revision 1593155 in svn to get the older version. You should use mailing list or jira to report any issues. Thanks *From:*Kai Hofmann [mailto:powers...@web.de] *Sent:* 22 January 2015 08:14 *To:* sstei...@apache.org; lberna...@apache.org *Subject:* fop-pdf-images question regarding pdfbox Version/Patch Hello you two main commiters on the famous fop-pdf-images project, ich hope it is ok to bother you directly with very special questions: On 08 Mai 2014 the commit removed pdfbox 1.8.4 and installed pdfbox 1.8.5 - during this the patches for the pdfbox have vanished - are they no longer required? I ask, because I will try to use the pdfbox 1.8.8 version (because of some problems I have with 1.8.5. Later in 2014 on 16 July you moved forward to pdfbox 2.0 - this version I can't bring to live yet - so I would like to make the suggestion that it would be helpful if you use branches - i.e. a branch for a fop-pdf-images version based on pdfbox 1.8.x would be very helpful, while you are wprking on the pdfbox 2.0 version in trunk. Thanks and Greetings Kai Hofmann -- Kai Hofmann EMail: powers...@web.de mailto:powers...@web.de Bremen/Germany
[jira] [Updated] (FOP-2440) fo:page-number display and spacing issues in Arabic
[ https://issues.apache.org/jira/browse/FOP-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo updated FOP-2440: --- Attachment: fop-2440-trunk.pdf please try trunk. fo:page-number display and spacing issues in Arabic --- Key: FOP-2440 URL: https://issues.apache.org/jira/browse/FOP-2440 Project: Fop Issue Type: Bug Reporter: Kumar Thangavel Attachments: BorderMovementSearch_20012015_sup.pdf-12.htm.pdf, fop-2440-trunk.pdf, fop-page-number-issue.xml Hi , I am trying to render a Arabic PDF with multiple pages where Current page number and total page numbers are defined by fo:page-number and fo:page-number-citation-last elements respectively. The PDF will display the page number like Page x of y. But there are couple of issues with that. 1) From page 10, the page number is reversed and shows as 01. Page 12 shows as 21 2) There is no spacing between page number and the Arabic letters. I am attaching the fop.xml and PDF for your reference. I am using FOP 1.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FOP-2440) fo:page-number display and spacing issues in Arabic
[ https://issues.apache.org/jira/browse/FOP-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2440. Resolution: Duplicate Fix Version/s: trunk fo:page-number display and spacing issues in Arabic --- Key: FOP-2440 URL: https://issues.apache.org/jira/browse/FOP-2440 Project: Fop Issue Type: Bug Reporter: Kumar Thangavel Fix For: trunk Attachments: BorderMovementSearch_20012015_sup.pdf-12.htm.pdf, fop-2440-trunk.pdf, fop-page-number-issue.xml Hi , I am trying to render a Arabic PDF with multiple pages where Current page number and total page numbers are defined by fo:page-number and fo:page-number-citation-last elements respectively. The PDF will display the page number like Page x of y. But there are couple of issues with that. 1) From page 10, the page number is reversed and shows as 01. Page 12 shows as 21 2) There is no spacing between page number and the Arabic letters. I am attaching the fop.xml and PDF for your reference. I am using FOP 1.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FOP-1842) integration of barcode in fop 1.0
[ https://issues.apache.org/jira/browse/FOP-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-1842. Resolution: Fixed Fix Version/s: 1.1 trunk I don't get the problem running from the command line, using either FOP 1.1 or trunk. The barcode jars used: barcode4j-fop-ext.jar, barcode4j-xgc.jar and barcode4j.jar (from the version 2.1). integration of barcode in fop 1.0 - Key: FOP-1842 URL: https://issues.apache.org/jira/browse/FOP-1842 Project: Fop Issue Type: Bug Components: foreign/barcode Affects Versions: 1.0 Environment: Operating System: Linux Platform: PC Reporter: marc-andre.marion Fix For: trunk, 1.1 Attachments: test.fo Hi, I tried to generate a pdf including a barcode with fop 1.0 and barcode4j 2.0. The following error was generated during the integration of bar code in the pdf : [ERROR] FOUserAgent - Image not available. URI: (instream-object). Reason: org.apache.xmlgraphics.image.loader.ImageException: The file format is not supported. No ImagePreloader found for null (No context info available) This works very well with fop 0.95 and with the same configuration. If I replace the fop.jar by that of fop 0.95 it works. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2434) Varying table border thickness in PDF output
[ https://issues.apache.org/jira/browse/FOP-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14243319#comment-14243319 ] Luis Bernardo commented on FOP-2434: The current implementation of borders in FOP is correct. By that I mean that it is mathematically correct and that one should not use Adobe to check the correctness. Instead we need to open the document with a text editor and look at the coordinate values that are written there and confirm that they are indeed correct. But since we cannot wait for Adobe to fix their Reader we can try to implement a different approach to borders that is more friendly to Adobe. The approach is not not draw borders as a sequence of short segments (the sides of each cell) as we do now and instead merge segments into a single segment (so draw the side of a table as a single segment). This new approach should work with the current Adobe Reader version. Varying table border thickness in PDF output Key: FOP-2434 URL: https://issues.apache.org/jira/browse/FOP-2434 Project: Fop Issue Type: Bug Components: documentation Reporter: Anthony Tables in my documentation vary in border thickness throughout my PDF output. I have determined that it occurs when cells are spanned (across rows and columns). I have attempted to fix stylesheets and Adobe settings, and nothing has helped. I use Oxygen XML Editor 16.1 with an Apache FOP processor. I am unable to attach any sample images or topic.fo file. By request, I will send both. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2330) Example shown on FOP homepage is not achievable using FOP
[ https://issues.apache.org/jira/browse/FOP-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo updated FOP-2330: --- Attachment: flag.pdf flag.fo Example shown on FOP homepage is not achievable using FOP - Key: FOP-2330 URL: https://issues.apache.org/jira/browse/FOP-2330 Project: Fop Issue Type: Bug Affects Versions: trunk Reporter: Chris Bowditch Attachments: flag.fo, flag.pdf Example shown on home page http://xmlgraphics.apache.org/fop/, under Demonstration section uses side floats, which aren't supported by FOP. You can tell side floats are used by the text flowing round the image. We should revise this to have XSL-FO that can be rendered by FOP. This was pointed out by qbd...@vt.edu -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FOP-2330) Example shown on FOP homepage is not achievable using FOP
[ https://issues.apache.org/jira/browse/FOP-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2330. Resolution: Implemented Fix Version/s: trunk See attached example. Example shown on FOP homepage is not achievable using FOP - Key: FOP-2330 URL: https://issues.apache.org/jira/browse/FOP-2330 Project: Fop Issue Type: Bug Affects Versions: trunk Reporter: Chris Bowditch Fix For: trunk Attachments: flag.fo, flag.pdf Example shown on home page http://xmlgraphics.apache.org/fop/, under Demonstration section uses side floats, which aren't supported by FOP. You can tell side floats are used by the text flowing round the image. We should revise this to have XSL-FO that can be rendered by FOP. This was pointed out by qbd...@vt.edu -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2434) Varying table border thickness in PDF output
[ https://issues.apache.org/jira/browse/FOP-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241269#comment-14241269 ] Luis Bernardo commented on FOP-2434: This is an issue with Adobe Reader. Submitting a bug report to Adobe may help. See above duplicate issues for more info. Varying table border thickness in PDF output Key: FOP-2434 URL: https://issues.apache.org/jira/browse/FOP-2434 Project: Fop Issue Type: Bug Components: documentation Reporter: Anthony Tables in my documentation vary in border thickness throughout my PDF output. I have determined that it occurs when cells are spanned (across rows and columns). I have attempted to fix stylesheets and Adobe settings, and nothing has helped. I use Oxygen XML Editor 16.1 with an Apache FOP processor. I am unable to attach any sample images or topic.fo file. By request, I will send both. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FOP-2433) Support CMYK TIFFs in AFP through IOCA FS45
[ https://issues.apache.org/jira/browse/FOP-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2433. Resolution: Fixed Fix Version/s: trunk Thank you for attaching the example. Support CMYK TIFFs in AFP through IOCA FS45 --- Key: FOP-2433 URL: https://issues.apache.org/jira/browse/FOP-2433 Project: Fop Issue Type: New Feature Reporter: Luis Bernardo Priority: Minor Fix For: trunk Attachments: Image_CMYK_32bits_LZW.tif, TEST.fo.xml, TEST.fo.xml.AFP, jai_imageio-1.1.0.jar Implement support for IOCA FS45 as described in the Image Object Content Architecture Reference (Release 6.1) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FOP-2433) Support CMYK TIFFs in AFP through IOCA FS45
Luis Bernardo created FOP-2433: -- Summary: Support CMYK TIFFs in AFP through IOCA FS45 Key: FOP-2433 URL: https://issues.apache.org/jira/browse/FOP-2433 Project: Fop Issue Type: New Feature Reporter: Luis Bernardo Priority: Minor Implement support for IOCA FS45 as described in the Image Object Content Architecture Reference (Release 6.1) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2433) Support CMYK TIFFs in AFP through IOCA FS45
[ https://issues.apache.org/jira/browse/FOP-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231571#comment-14231571 ] Luis Bernardo commented on FOP-2433: Implemented in http://svn.apache.org/viewvc?view=revisionrevision=1642893. Support CMYK TIFFs in AFP through IOCA FS45 --- Key: FOP-2433 URL: https://issues.apache.org/jira/browse/FOP-2433 Project: Fop Issue Type: New Feature Reporter: Luis Bernardo Priority: Minor Implement support for IOCA FS45 as described in the Image Object Content Architecture Reference (Release 6.1) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] merge branches/Temp_BasicSideFloats to trunk
Thank you to all that voted. Since there are no objections or bugs reported I will proceed with the merge. On 11/25/14, 2:41 PM, Luis Bernardo wrote: I would like to merge the branch branches/Temp_BasicSideFloats to trunk. The branch has a implementation of side floats that uses the same approach used when handling change in IPD across pages. These are the known limitations: -- the clear fo:float attribute is ignored; only the float attribute (left or right) is used -- overlapping of floats in the Y is not handled (even in the case there would not be overlap in the X direction) -- floats that extend beyond the body region are not properly handled and will overflow past the edge of the region -- if a float extends to bottom of the body region and there are footnotes in the page the float may overlap with the footnote region -- floats next to a table are not supported unless the start and end of the table happens in between the start and end of the float Examples can be found in the thread with subject RFC: basic side floats in this mailing list. To follow due process and since this will be a new major feature I am launching a vote. Please vote or report a bug before the end of Monday UTC, December 1st.
[jira] [Commented] (FOP-2330) Example shown on FOP homepage is not achievable using FOP
[ https://issues.apache.org/jira/browse/FOP-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230757#comment-14230757 ] Luis Bernardo commented on FOP-2330: Revision http://svn.apache.org/viewvc?view=revisionrevision=1642793 allows this now. Example shown on FOP homepage is not achievable using FOP - Key: FOP-2330 URL: https://issues.apache.org/jira/browse/FOP-2330 Project: Fop Issue Type: Bug Affects Versions: trunk Reporter: Chris Bowditch Example shown on home page http://xmlgraphics.apache.org/fop/, under Demonstration section uses side floats, which aren't supported by FOP. You can tell side floats are used by the text flowing round the image. We should revise this to have XSL-FO that can be rendered by FOP. This was pointed out by qbd...@vt.edu -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: RFC: basic side floats
As a result of the work on lists and floats we can improve current support for lists when there is a change in IPD across pages. I have committed a small change to do that to this branch even though it is not really float related. An example is attached. On Tue, Nov 25, 2014 at 1:53 PM, Luis Bernardo lmpmberna...@gmail.com wrote: A new example that shows floats and footnotes in the same page. On Fri, Nov 14, 2014 at 9:34 AM, Luis Bernardo lmpmberna...@gmail.com wrote: A more complex example that has a float inside a list. On Fri, Nov 7, 2014 at 4:41 PM, Luis Bernardo lmpmberna...@gmail.com wrote: A new example that involves a list that starts after a float starts (and before it ends). On Mon, Oct 20, 2014 at 10:33 AM, Luis Bernardo lmpmberna...@gmail.com wrote: FYI, I have created a new branch where I placed a new approach to side floats. The idea behind the approach is that if we can handle a change in IPD from one page to the next we can also do the same in the middle of a page (where a float causes the change in IPD). This also means that the implementation suffers, right now, from the same limitations that the handling of an IPD change across pages has. So, in summary: Left and right floats are supported in the most simple cases, including in multi-column layouts. Below are listed the known limitations: -- the clear fo:float attribute is ignored; only the float attribute (left or right) is used -- overlapping of floats in the Y is not handled (even in the case there would not be overlap in the X direction) -- floats that extend beyond the body region are not properly handled and will overflow past the edge of the region -- floats next to a table or a list are not supported unless the start and end of the table or list happen in between the start and end of the float -- a list can extend past the end of a float but only in situations where the list item at the end of the (bottom of the) float does not need to be wrapped; but wrapping before or after the bottom edge of the float is supported Attached is an example and the output (a similar two column example is in the layout tests). Comments, suggestion and bugs are welcome. I would like to commit this to trunk in a few weeks but meanwhile I will investigate alternative approaches to some of the current limitations. list-change-ipd-across-pages.pdf Description: Adobe PDF document ?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 master-name=narrow page-height=200pt page-width=400pt margin=50pt fo:region-body background-color=#F0F0F0/ /fo:simple-page-master fo:simple-page-master master-name=wide page-height=200pt page-width=600pt margin=50pt fo:region-body background-color=#F0F0F0/ /fo:simple-page-master fo:page-sequence-master master-name=pages fo:single-page-master-reference master-reference=narrow/ fo:repeatable-page-master-reference master-reference=wide/ /fo:page-sequence-master fo:page-sequence-master master-name=alternate fo:repeatable-page-master-alternatives fo:conditional-page-master-reference odd-or-even=odd master-reference=wide/ fo:conditional-page-master-reference odd-or-even=even master-reference=narrow/ /fo:repeatable-page-master-alternatives /fo:page-sequence-master /fo:layout-master-set fo:page-sequence master-reference=alternate fo:flow flow-name=xsl-region-body fo:block widows=1 orphans=1 fo:list-block fo:list-item fo:list-item-label end-indent=label-end() fo:block(a)/fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:block In olden times when wishing still helped one, there lived a king whose daughters were all beautiful, but the youngest was so beautiful that the sun itself, which has seen so much, was astonished whenever it shone in her face. /fo:block /fo:list-item-body /fo:list-item fo:list-item fo:list-item-label end-indent=label-end() fo:block(a)/fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:block In olden times when wishing still helped one, there lived a king whose daughters were all beautiful, but the youngest was so beautiful that the sun itself, which has seen so much, was astonished whenever it shone in her face. /fo:block /fo:list-item-body /fo:list-item fo:list-item fo:list-item-label end-indent=label-end() fo:block(a)/fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:block In olden times when wishing still helped one, there lived
Re: RFC: basic side floats
A new example that shows floats and footnotes in the same page. On Fri, Nov 14, 2014 at 9:34 AM, Luis Bernardo lmpmberna...@gmail.com wrote: A more complex example that has a float inside a list. On Fri, Nov 7, 2014 at 4:41 PM, Luis Bernardo lmpmberna...@gmail.com wrote: A new example that involves a list that starts after a float starts (and before it ends). On Mon, Oct 20, 2014 at 10:33 AM, Luis Bernardo lmpmberna...@gmail.com wrote: FYI, I have created a new branch where I placed a new approach to side floats. The idea behind the approach is that if we can handle a change in IPD from one page to the next we can also do the same in the middle of a page (where a float causes the change in IPD). This also means that the implementation suffers, right now, from the same limitations that the handling of an IPD change across pages has. So, in summary: Left and right floats are supported in the most simple cases, including in multi-column layouts. Below are listed the known limitations: -- the clear fo:float attribute is ignored; only the float attribute (left or right) is used -- overlapping of floats in the Y is not handled (even in the case there would not be overlap in the X direction) -- floats that extend beyond the body region are not properly handled and will overflow past the edge of the region -- floats next to a table or a list are not supported unless the start and end of the table or list happen in between the start and end of the float -- a list can extend past the end of a float but only in situations where the list item at the end of the (bottom of the) float does not need to be wrapped; but wrapping before or after the bottom edge of the float is supported Attached is an example and the output (a similar two column example is in the layout tests). Comments, suggestion and bugs are welcome. I would like to commit this to trunk in a few weeks but meanwhile I will investigate alternative approaches to some of the current limitations. ?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 master-name=simple page-height=5in page-width=5in margin=0.2in fo:region-body / /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=simple fo:flow flow-name=xsl-region-body fo:block font-size=12pt space-before=3pt text-indent=0.75cm text-align=justify Footnote in normal block before a float.fo:footnote fo:inline font-size=60% baseline-shift=super1)/fo:inline fo:footnote-body fo:block start-indent=0.5cm text-indent=-0.5cm fo:inline font-size=60% baseline-shift=super1)/fo:inline The footnote from the normal block before the float./fo:block /fo:footnote-body /fo:footnote. /fo:block fo:list-block provisional-distance-between-starts=30pt provisional-label-separation=10pt fo:list-item fo:list-item-label end-indent=label-end() fo:block(a)/fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:block Test for float and footnote inside a list. Test for float and footnote inside a list. Test for float and footnote inside a list. (see box) fo:float float=end fo:block border=1pt solid red padding=5pt end-indent=0pt start-indent=0pt fo:block-container inline-progression-dimension=120pt fo:block background-color=yellow The former dean's house at the University of Wisconsin (this is the alt text of the image in the Wikipedia page) /fo:block /fo:block-container /fo:block /fo:float Test for float and footnote inside a list. Test for float and footnote inside a list. /fo:block /fo:list-item-body /fo:list-item fo:list-item fo:list-item-label end-indent=label-end() fo:block(b)/fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:block Footnote in list that is being wrapped around a float.fo:footnote fo:inline font-size=60% baseline-shift=super2)/fo:inline fo:footnote-body fo:block start-indent=0.5cm text-indent=-0.5cm fo:inline font-size=60% baseline-shift=super2)/fo:inline The footnote from the list that is being wrapped around a float./fo:block /fo:footnote-body /fo:footnote. Test for float and footnote inside a list. Test for float and footnote inside a list. Test for float and footnote inside a list. Test for float and footnote inside a list. Test for float and footnote
[VOTE] merge branches/Temp_BasicSideFloats to trunk
I would like to merge the branch branches/Temp_BasicSideFloats to trunk. The branch has a implementation of side floats that uses the same approach used when handling change in IPD across pages. These are the known limitations: -- the clear fo:float attribute is ignored; only the float attribute (left or right) is used -- overlapping of floats in the Y is not handled (even in the case there would not be overlap in the X direction) -- floats that extend beyond the body region are not properly handled and will overflow past the edge of the region -- if a float extends to bottom of the body region and there are footnotes in the page the float may overlap with the footnote region -- floats next to a table are not supported unless the start and end of the table happens in between the start and end of the float Examples can be found in the thread with subject RFC: basic side floats in this mailing list. To follow due process and since this will be a new major feature I am launching a vote. Please vote or report a bug before the end of Monday UTC, December 1st.
Re: RFC: basic side floats
A more complex example that has a float inside a list. On Fri, Nov 7, 2014 at 4:41 PM, Luis Bernardo lmpmberna...@gmail.com wrote: A new example that involves a list that starts after a float starts (and before it ends). On Mon, Oct 20, 2014 at 10:33 AM, Luis Bernardo lmpmberna...@gmail.com wrote: FYI, I have created a new branch where I placed a new approach to side floats. The idea behind the approach is that if we can handle a change in IPD from one page to the next we can also do the same in the middle of a page (where a float causes the change in IPD). This also means that the implementation suffers, right now, from the same limitations that the handling of an IPD change across pages has. So, in summary: Left and right floats are supported in the most simple cases, including in multi-column layouts. Below are listed the known limitations: -- the clear fo:float attribute is ignored; only the float attribute (left or right) is used -- overlapping of floats in the Y is not handled (even in the case there would not be overlap in the X direction) -- floats that extend beyond the body region are not properly handled and will overflow past the edge of the region -- floats next to a table or a list are not supported unless the start and end of the table or list happen in between the start and end of the float -- a list can extend past the end of a float but only in situations where the list item at the end of the (bottom of the) float does not need to be wrapped; but wrapping before or after the bottom edge of the float is supported Attached is an example and the output (a similar two column example is in the layout tests). Comments, suggestion and bugs are welcome. I would like to commit this to trunk in a few weeks but meanwhile I will investigate alternative approaches to some of the current limitations. basic-floats-inside-list.pdf Description: Adobe PDF document ?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 margin=0.25in master-name=page page-height=11in page-width=8.5in fo:region-body / /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=page fo:flow flow-name=xsl-region-body fo:block Did you know... (taken from Wikipedia main page on November 6th, 2014, with the order slightly changed to better show the wrapping around the float) /fo:block fo:block From Wikipedia's new and recently improved content: /fo:block fo:block fo:list-block fo:list-item fo:list-item-label end-indent=label-end() fo:block#x2022;/fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:block ... that while testifying in a 2004 lawsuit involving the meaning of the word steakburger, a corporate CEO was grilled on the witness stand? /fo:block /fo:list-item-body /fo:list-item fo:list-item fo:list-item-label end-indent=label-end() fo:block#x2022;/fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:block ... that the Queen Anne house (pictured) fo:float float=end fo:block border=1pt solid red padding=5pt end-indent=0pt start-indent=0pt fo:block-container inline-progression-dimension=120pt fo:block background-color=yellow The former dean's house at the University of Wisconsin (this is the alt text of the image in the Wikipedia page) /fo:block /fo:block-container /fo:block /fo:float at the Allen Centennial Gardens was home to four deans of the University of Wisconsin–Madison College of Agricultural and Life Sciences? /fo:block /fo:list-item-body /fo:list-item fo:list-item fo:list-item-label end-indent=label-end() fo:block#x2022;/fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:block ... that rhapsodomancy was so vague, Virgil wrote against it in The Aeneid? /fo:block /fo:list-item-body /fo:list-item fo:list-item fo:list-item-label end-indent=label-end() fo:block#x2022;/fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:block ... that Australian physician Claudia Burton Bradley was one of the first diabetics to be treated with insulin? /fo:block /fo:list-item-body /fo:list-item fo:list-item fo:list-item-label end-indent=label-end() fo:block#x2022;/fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:block
Re: xml-fop
Hi Stefan, We decided this back in August (see below). The trigger was in fact checkstyle which was updated in gump and we couldn't figure out how to force gump to use the version we were using. So in a sense we felt we needed more control over the build process. Luis http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/201408.mbox/browser On 11/13/14, 9:19 AM, Stefan Bodewig wrote: Hi Simon On 2014-11-12, Simon Steiner wrote: Fop project moved to Jenkins so can you remove fop from gump. we can do so easily (as well as any other Apache committer could), but a bit of history first. About one-and-half year ago I asked whether you still wanted to have Gump builds for XMLGraphics[1] and back then Vincent Hennebert responded you wanted to keep the builds[2]. I assume it is a FOP project decsion to remove the Gump build now and will change Gump's configuration to that effect (initially I'll really only remove the email notification) - please yell if you still want to keep the different kind of CI Gump provides. Cheers Stefan [1] http://mail-archives.apache.org/mod_mbox/xmlgraphics-general/201306.mbox/browser [2] http://mail-archives.apache.org/mod_mbox/gump-general/201307.mbox/browser
Re: svn commit: r1637817 - in /xmlgraphics/fop/trunk: src/foschema/ src/java/org/apache/fop/fonts/ src/java/org/apache/fop/fonts/autodetect/ src/java/org/apache/fop/fonts/type1/ src/java/org/apache/fo
You need to remove the cache (the .fop directory under your home).
On 11/11/14, 8:23 AM, Glenn Adams wrote:
I fixed the problem below, but still getting other NPEs, so it looks
pretty broken. I'm reverting your commit. I guess you didn't run junit
before doing the commit.
On Tue, Nov 11, 2014 at 2:59 PM, Glenn Adams gl...@skynav.com
mailto:gl...@skynav.com wrote:
Your commit broke the build (junit). Getting an NPE at highlight
diff below when fontUris is null when running
Testsuite: org.apache.fop.BasicTranscoderTestSuite
Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
2.131 sec
Testcase: testGenericPDFTranscoder took 1.578 sec
Caused an ERROR
Error while setting up PDFDocumentGraphics2D
Enclosed Exception:
null
org.apache.batik.transcoder.TranscoderException: Error while
setting up PDFDocumentGraphics2D
Enclosed Exception:
null
at org.apache.fop.svg.PDFTranscoder.transcode(PDFTranscoder.java:137)
at
org.apache.batik.transcoder.XMLAbstractTranscoder.transcode(Unknown Source)
at
org.apache.batik.transcoder.SVGAbstractTranscoder.transcode(Unknown Source)
at
org.apache.fop.AbstractBasicTranscoderTest.testGenericPDFTranscoder(AbstractBasicTranscoderTest.java:71)
@@ -150,7 +166,7 @@ public class EmbedFontInfo implements Se
* @return true if the font is embedded, false if it is referenced.
*/
public boolean isEmbedded() {
- if (embedURI == null) {
+ if (fontUris.getEmbed() == null) {
return false;
} else {
return this.embedded;
On Mon, Nov 10, 2014 at 6:18 PM, lberna...@apache.org
mailto:lberna...@apache.org wrote:
Author: lbernardo
Date: Mon Nov 10 11:18:43 2014
New Revision: 1637817
URL: http://svn.apache.org/r1637817
Log:
FOP-2424: Allow for type1 afm/pfm files to be in a different
path than the pfb file
Added:
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontUris.java
(with props)
Modified:
xmlgraphics/fop/trunk/src/foschema/fop-configuration.xsd
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/DefaultFontConfig.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/DefaultFontConfigurator.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/EmbedFontInfo.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontLoader.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/LazyFont.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/autodetect/FontInfoFinder.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/type1/Type1FontLoader.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/java2d/ConfiguredFontCollection.java
xmlgraphics/fop/trunk/test/java/org/apache/fop/fonts/DejaVuLGCSerifTestCase.java
xmlgraphics/fop/trunk/test/java/org/apache/fop/fonts/EmbedFontInfoTestCase.java
Modified: xmlgraphics/fop/trunk/src/foschema/fop-configuration.xsd
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/foschema/fop-configuration.xsd?rev=1637817r1=1637816r2=1637817view=diff
==
--- xmlgraphics/fop/trunk/src/foschema/fop-configuration.xsd
(original)
+++ xmlgraphics/fop/trunk/src/foschema/fop-configuration.xsd
Mon Nov 10 11:18:43 2014
@@ -283,6 +283,8 @@
/xsd:sequence
xsd:attribute name=metrics-url type=xsd:anyURI
use=optional/
xsd:attribute name=embed-url type=xsd:anyURI
use=optional/
+xsd:attribute name=embed-url-afm type=xsd:anyURI
use=optional/
+xsd:attribute name=embed-url-pfm type=xsd:anyURI
use=optional/
xsd:attribute name=sub-font type=xsd:string
use=optional/
xsd:attribute name=embedding-mode use=optional
xsd:simpleType
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/DefaultFontConfig.java
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/DefaultFontConfig.java?rev=1637817r1=1637816r2=1637817view=diff
==
---
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/DefaultFontConfig.java
(original)
+++
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/DefaultFontConfig.java
Mon Nov 10 11:18:43 2014
@@ -108,11 +108,13 @@ public final class DefaultFontConfig imp
strict);
continue;
}
-Font font = new
Font(fontCfg.getAttribute(metrics-url,
[jira] [Created] (FOP-2424) Allow for type1 afm/pfm files to be in a different path than the pfb file
Luis Bernardo created FOP-2424: -- Summary: Allow for type1 afm/pfm files to be in a different path than the pfb file Key: FOP-2424 URL: https://issues.apache.org/jira/browse/FOP-2424 Project: Fop Issue Type: Improvement Reporter: Luis Bernardo Priority: Minor Although not common when using font files in the local file system, when using a custom resolver to load remote located font files the placement of the pfb and afm/pfm files may not be the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2424) Allow for type1 afm/pfm files to be in a different path than the pfb file
[ https://issues.apache.org/jira/browse/FOP-2424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14204663#comment-14204663 ] Luis Bernardo commented on FOP-2424: implemented in: http://svn.apache.org/viewvc?view=revisionrevision=1637817 Allow for type1 afm/pfm files to be in a different path than the pfb file - Key: FOP-2424 URL: https://issues.apache.org/jira/browse/FOP-2424 Project: Fop Issue Type: Improvement Reporter: Luis Bernardo Priority: Minor Although not common when using font files in the local file system, when using a custom resolver to load remote located font files the placement of the pfb and afm/pfm files may not be the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FOP-2424) Allow for type1 afm/pfm files to be in a different path than the pfb file
[ https://issues.apache.org/jira/browse/FOP-2424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2424. Resolution: Implemented Fix Version/s: trunk font documentation updated (under http://xmlgraphics.apache.org/fop/trunk/fonts.html#register) Allow for type1 afm/pfm files to be in a different path than the pfb file - Key: FOP-2424 URL: https://issues.apache.org/jira/browse/FOP-2424 Project: Fop Issue Type: Improvement Reporter: Luis Bernardo Priority: Minor Fix For: trunk Although not common when using font files in the local file system, when using a custom resolver to load remote located font files the placement of the pfb and afm/pfm files may not be the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Build failed in Jenkins: xmlgraphics-fop #47
I think this is caused by a stale FOP cache. I do not seem to have admin rights to configure the Jenkins job... I believe that adding a step to remove the .fop cache will fix problems like these. Simon, how did you get admin rights? On Mon, Nov 10, 2014 at 11:28 AM, Apache Jenkins Server jenk...@builds.apache.org wrote: See https://builds.apache.org/job/xmlgraphics-fop/47/changes Changes: [lbernardo] updated type1 info regarding pfm and afm file locations -- Started by an SCM change Building remotely on ubuntu-1 (docker Ubuntu ubuntu) in workspace https://builds.apache.org/job/xmlgraphics-fop/ws/ Updating http://svn.eu.apache.org/repos/asf/xmlgraphics/fop/trunk at revision '2014-11-10T11:28:18.543 +' Fetching ' http://svn.apache.org/repos/asf/xmlgraphics/site/trunk/content/fop' at -1 into 'https://builds.apache.org/job/xmlgraphics-fop/ws/docs' U docs/trunk/fonts.mdtext At revision 1637819 At revision 1637819 no change for http://svn.eu.apache.org/repos/asf/xmlgraphics/fop/trunk since the previous build [xmlgraphics-fop] $ /bin/bash -xe /tmp/hudson4815371603271106704.sh + '[' '!' -f junit-4.10.jar ']' + '[' '!' -f lib/build/checkstyle-5.5-all.jar ']' + '[' '!' -f lib/fop-hyph.jar ']' + ant clean package junit checkstyle findbugs -Dfindbugs.home.dir /home/hudson/tools/findbugs/findbugs-2.0.3 Buildfile: https://builds.apache.org/job/xmlgraphics-fop/ws/build.xml Trying to override old definition of task javac Trying to override old definition of task junit clean: [delete] Deleting directory https://builds.apache.org/job/xmlgraphics-fop/ws/build init-avail: [echo] --- Apache FOP svn-trunk [1999-2012] [echo] See build.properties and build-local.properties for additional build settings [echo] Apache Ant(TM) version 1.9.3 compiled on April 8 2014 [echo] VM: 16.3-b01, Sun Microsystems Inc. [echo] JAVA_HOME: /home/jenkins/tools/java/jdk1.6.0_20-32-unlimited-security [echo] JAI Support NOT Present [echo] JCE Support PRESENT [echo] JUnit Support PRESENT [echo] XMLUnit Support PRESENT init: codegen: [echo] Generating the java files from xml resources [mkdir] Created dir: https://builds.apache.org/job/xmlgraphics-fop/ws/build/gensrc [mkdir] Created dir: https://builds.apache.org/job/xmlgraphics-fop/ws/build/gensrc/org/apache/fop/fonts/base14 [xslt] Processing https://builds.apache.org/job/xmlgraphics-fop/ws/src/codegen/fonts/encodings.xml to https://builds.apache.org/job/xmlgraphics-fop/ws/build/gensrc/org/apache/fop/fonts/CodePointMapping.java [xslt] Loading stylesheet https://builds.apache.org/job/xmlgraphics-fop/ws/src/codegen/fonts/code-point-mapping.xsl [xslt] Transforming into https://builds.apache.org/job/xmlgraphics-fop/ws/build/gensrc/org/apache/fop/fonts/base14 [xslt] Processing https://builds.apache.org/job/xmlgraphics-fop/ws/src/codegen/fonts/Courier.xml to https://builds.apache.org/job/xmlgraphics-fop/ws/build/gensrc/org/apache/fop/fonts/base14/Courier.java [xslt] Loading stylesheet https://builds.apache.org/job/xmlgraphics-fop/ws/src/codegen/fonts/font-file.xsl [xslt] Processing https://builds.apache.org/job/xmlgraphics-fop/ws/src/codegen/fonts/CourierBold.xml to https://builds.apache.org/job/xmlgraphics-fop/ws/build/gensrc/org/apache/fop/fonts/base14/CourierBold.java [xslt] Processing https://builds.apache.org/job/xmlgraphics-fop/ws/src/codegen/fonts/CourierBoldOblique.xml to https://builds.apache.org/job/xmlgraphics-fop/ws/build/gensrc/org/apache/fop/fonts/base14/CourierBoldOblique.java [xslt] Processing https://builds.apache.org/job/xmlgraphics-fop/ws/src/codegen/fonts/CourierOblique.xml to https://builds.apache.org/job/xmlgraphics-fop/ws/build/gensrc/org/apache/fop/fonts/base14/CourierOblique.java [xslt] Processing https://builds.apache.org/job/xmlgraphics-fop/ws/src/codegen/fonts/Helvetica.xml to https://builds.apache.org/job/xmlgraphics-fop/ws/build/gensrc/org/apache/fop/fonts/base14/Helvetica.java [xslt] Processing https://builds.apache.org/job/xmlgraphics-fop/ws/src/codegen/fonts/HelveticaBold.xml to https://builds.apache.org/job/xmlgraphics-fop/ws/build/gensrc/org/apache/fop/fonts/base14/HelveticaBold.java [xslt] Processing https://builds.apache.org/job/xmlgraphics-fop/ws/src/codegen/fonts/HelveticaBoldOblique.xml to https://builds.apache.org/job/xmlgraphics-fop/ws/build/gensrc/org/apache/fop/fonts/base14/HelveticaBoldOblique.java [xslt] Processing https://builds.apache.org/job/xmlgraphics-fop/ws/src/codegen/fonts/HelveticaOblique.xml to https://builds.apache.org/job/xmlgraphics-fop/ws/build/gensrc/org/apache/fop/fonts/base14/HelveticaOblique.java [xslt] Processing
[jira] [Resolved] (FOP-2426) Apache FOP- Arabic Letters are not Joined
[ https://issues.apache.org/jira/browse/FOP-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2426. Resolution: Invalid This is known to work so you are not using the right version (1.1 or trunk) or you have the wrong font configuration. See attached output generated with trunk. You can get more help from fop-users mailing list. Apache FOP- Arabic Letters are not Joined - Key: FOP-2426 URL: https://issues.apache.org/jira/browse/FOP-2426 Project: Fop Issue Type: Bug Reporter: Kumar Thangavel Attachments: Streams3383988751952726569.xml, pdfExport.pdf Hi All , I am trying to generate a PDF report using Apache FOP in Arabic Language . The report generation is working fine but the Character Glyphs are not properly formed and the arabic words are not properly joined. I have tried with Arial font many other fonts which is Suitable for Arabic. eg . Traditional Arabic, Simplified Arabic etc but none of it worked. I am attaching the sample PDF and fo.xml for your reference. Could you please help me sort this issue out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2426) Apache FOP- Arabic Letters are not Joined
[ https://issues.apache.org/jira/browse/FOP-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo updated FOP-2426: --- Attachment: out.pdf Apache FOP- Arabic Letters are not Joined - Key: FOP-2426 URL: https://issues.apache.org/jira/browse/FOP-2426 Project: Fop Issue Type: Bug Reporter: Kumar Thangavel Attachments: Streams3383988751952726569.xml, out.pdf, pdfExport.pdf Hi All , I am trying to generate a PDF report using Apache FOP in Arabic Language . The report generation is working fine but the Character Glyphs are not properly formed and the arabic words are not properly joined. I have tried with Arial font many other fonts which is Suitable for Arabic. eg . Traditional Arabic, Simplified Arabic etc but none of it worked. I am attaching the sample PDF and fo.xml for your reference. Could you please help me sort this issue out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: RFC: basic side floats
A new example that involves a list that starts after a float starts (and before it ends). On Mon, Oct 20, 2014 at 10:33 AM, Luis Bernardo lmpmberna...@gmail.com wrote: FYI, I have created a new branch where I placed a new approach to side floats. The idea behind the approach is that if we can handle a change in IPD from one page to the next we can also do the same in the middle of a page (where a float causes the change in IPD). This also means that the implementation suffers, right now, from the same limitations that the handling of an IPD change across pages has. So, in summary: Left and right floats are supported in the most simple cases, including in multi-column layouts. Below are listed the known limitations: -- the clear fo:float attribute is ignored; only the float attribute (left or right) is used -- overlapping of floats in the Y is not handled (even in the case there would not be overlap in the X direction) -- floats that extend beyond the body region are not properly handled and will overflow past the edge of the region -- floats next to a table or a list are not supported unless the start and end of the table or list happen in between the start and end of the float -- a list can extend past the end of a float but only in situations where the list item at the end of the (bottom of the) float does not need to be wrapped; but wrapping before or after the bottom edge of the float is supported Attached is an example and the output (a similar two column example is in the layout tests). Comments, suggestion and bugs are welcome. I would like to commit this to trunk in a few weeks but meanwhile I will investigate alternative approaches to some of the current limitations. ?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 margin=0.25in master-name=page page-height=11in page-width=8.5in fo:region-body / /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=page fo:flow flow-name=xsl-region-body fo:block Did you know... (taken from Wikipedia main page on November 6th, 2014, with the order slightly changed to better show the wrapping around the float) /fo:block fo:block From Wikipedia's new and recently improved content: /fo:block fo:block fo:float float=end fo:block border=1pt solid red padding=5pt end-indent=0pt start-indent=0pt fo:block-container inline-progression-dimension=120pt fo:block background-color=yellow The former dean's house at the University of Wisconsin (this is the alt text of the image in the Wikipedia page) /fo:block /fo:block-container /fo:block /fo:float /fo:block fo:block fo:list-block fo:list-item fo:list-item-label end-indent=label-end() fo:block#x2022;/fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:block ... that the Queen Anne house (pictured) at the Allen Centennial Gardens was home to four deans of the University of Wisconsin–Madison College of Agricultural and Life Sciences? /fo:block /fo:list-item-body /fo:list-item fo:list-item fo:list-item-label end-indent=label-end() fo:block#x2022;/fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:block ... that rhapsodomancy was so vague, Virgil wrote against it in The Aeneid? /fo:block /fo:list-item-body /fo:list-item fo:list-item fo:list-item-label end-indent=label-end() fo:block#x2022;/fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:block ... that Australian physician Claudia Burton Bradley was one of the first diabetics to be treated with insulin? /fo:block /fo:list-item-body /fo:list-item fo:list-item fo:list-item-label end-indent=label-end() fo:block#x2022;/fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:block ... that Green Bay Packers offensive lineman David Bakhtiari was the first rookie in Packers history to start every game at left tackle in a season since the start of the 16-game season? /fo:block /fo:list-item-body /fo:list-item fo:list-item fo:list-item-label end-indent=label-end() fo:block#x2022;/fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:block ... that in the Byzantine Empire, the office of orphanotrophos, head of the imperial orphanage, ranked among the higher offices of state
[jira] [Resolved] (FOP-2281) factory is not initialized when -cache is used in org.apache.fop.cli.Main
[ https://issues.apache.org/jira/browse/FOP-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2281. Resolution: Fixed Patch applied: http://svn.apache.org/viewvc?view=revisionrevision=1636469. factory is not initialized when -cache is used in org.apache.fop.cli.Main - Key: FOP-2281 URL: https://issues.apache.org/jira/browse/FOP-2281 Project: Fop Issue Type: Bug Environment: Fedora 19 64 bit Reporter: Leo Fix For: trunk Attachments: fop2281.patch 1.I set all jar files in the classpath. 2. I run this command java org.apache.fop.cli.Main -cache cacheFile NullPointerException occurs. The variable factory in CommandLineOptions is not initialized -- This message was sent by Atlassian JIRA (v6.3.4#6332)
RFC: basic side floats
FYI, I have created a new branch where I placed a new approach to side floats. The idea behind the approach is that if we can handle a change in IPD from one page to the next we can also do the same in the middle of a page (where a float causes the change in IPD). This also means that the implementation suffers, right now, from the same limitations that the handling of an IPD change across pages has. So, in summary: Left and right floats are supported in the most simple cases, including in multi-column layouts. Below are listed the known limitations: -- the clear fo:float attribute is ignored; only the float attribute (left or right) is used -- overlapping of floats in the Y is not handled (even in the case there would not be overlap in the X direction) -- floats that extend beyond the body region are not properly handled and will overflow past the edge of the region -- floats next to a table or a list are not supported unless the start and end of the table or list happen in between the start and end of the float -- a list can extend past the end of a float but only in situations where the list item at the end of the (bottom of the) float does not need to be wrapped; but wrapping before or after the bottom edge of the float is supported Attached is an example and the output (a similar two column example is in the layout tests). Comments, suggestion and bugs are welcome. I would like to commit this to trunk in a few weeks but meanwhile I will investigate alternative approaches to some of the current limitations. ?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 margin=50pt master-name=page page-height=800pt page-width=600pt fo:region-body background-color=yellow / /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=page fo:flow flow-name=xsl-region-body fo:block Elstree Reservoir[edit] The dam was built in 1795 by French prisoners of war.[34] English watercolour landscape painter John Hassell writes: At the top of Stanmore Hill we enter on Bushy Heath, and at some distance on the right in the valley catch a view of the celebrated reservoir, the property of the Grand Junction Company, on Aidenham Common, at the foot of the village of Elstree. This noble sheet of water occupies a space of considerable extent on the verge of Aidenham Common, which thirty years ago was a barren waste; here the improvements in agriculture are indeed conspicuous, for at this place a poor, sandy, meagre, wretched soil has now by good husbandry been converted into rich pasturage. The reservoir has all the appearance of a lake; and when the timber that surrounds it shall have arrived at maturity, it will be a most delightful spot. From this immense sheet of water, in event of drought or a deficiency of upland waters, the lower parts of the Grand Junction and the Paddington Canals can have an immediate supply. The feeder from this reservoir enters the main stream near Rickmansworth, above Batchworth Mills, and supplies the millers' below with 300 locks of water, to whose interest the Duke of Northumberland is a perpetual trustee.[35] In 1886, the Photographic Society of Great Britain featured an exhibition of photos of Elstree Reservoir by Edgar Clifton.[36] During World War I, then Major Keith Caldwell with No. 74 Squadron RAF, used Elstree Reservoir for target practice.[37] In 1918, one of the pilots accidentally killed a local resident when his machine gun misfired.[38] /fo:block fo:block Elstree Reservoir[edit] The dam was built in 1795 by French prisoners of war.[34] English watercolour landscape painter John Hassell writes: At the top of Stanmore Hill we enter on Bushy Heath, and at some distance on the right in the valley catch a view of the celebrated reservoir, the property of the Grand Junction Company, on Aidenham Common, at the foot of the village of Elstree. This noble sheet of water occupies a space of considerable extent on the verge of Aidenham Common, which thirty years ago was a barren waste; here the improvements in agriculture are indeed conspicuous, for at this place a poor, sandy, meagre, wretched soil has now by good husbandry been converted into rich pasturage. The reservoir has all the appearance of a lake; and when the timber that surrounds it shall have arrived at maturity, it will be a most delightful spot. From this immense sheet of water, in event of drought or a deficiency of upland waters, the lower parts of the Grand Junction and the Paddington Canals can have an immediate supply. The feeder from this reservoir enters the main stream near Rickmansworth, above Batchworth Mills, and supplies the millers' below with 300 locks of water, to whose interest the Duke of Northumberland is a perpetual trustee.[35] In 1886, the Photographic Society of Great Britain featured an exhibition of photos of Elstree Reservoir by Edgar Clifton.[36] During World War I,
[jira] [Created] (FOP-2417) Exception caused by letter space handling in Chinese sentence
Luis Bernardo created FOP-2417: -- Summary: Exception caused by letter space handling in Chinese sentence Key: FOP-2417 URL: https://issues.apache.org/jira/browse/FOP-2417 Project: Fop Issue Type: Bug Reporter: Luis Bernardo java.lang.IllegalArgumentException: factor 0; was: -1 at org.apache.fop.traits.MinOptMax.mult(MinOptMax.java:253) at org.apache.fop.layoutmgr.inline.TextLayoutManager.addElementsForAWordFragment(TextLayoutManager.java:1323) at org.apache.fop.layoutmgr.inline.TextLayoutManager.processWord(TextLayoutManager.java:944) at org.apache.fop.layoutmgr.inline.TextLayoutManager.getNextKnuthElements(TextLayoutManager.java:802) at org.apache.fop.layoutmgr.inline.InlineLayoutManager.getNextKnuthElements(InlineLayoutManager.java:330) at org.apache.fop.layoutmgr.inline.LineLayoutManager.collectInlineKnuthElements(LineLayoutManager.java:698) at org.apache.fop.layoutmgr.inline.LineLayoutManager.getNextKnuthElements(LineLayoutManager.java:627) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextChildElements(BlockLayoutManager.java:141) example attached -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2417) Exception caused by letter space handling in Chinese sentence
[ https://issues.apache.org/jira/browse/FOP-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo updated FOP-2417: --- Attachment: test.fo Exception caused by letter space handling in Chinese sentence - Key: FOP-2417 URL: https://issues.apache.org/jira/browse/FOP-2417 Project: Fop Issue Type: Bug Reporter: Luis Bernardo Attachments: test.fo java.lang.IllegalArgumentException: factor 0; was: -1 at org.apache.fop.traits.MinOptMax.mult(MinOptMax.java:253) at org.apache.fop.layoutmgr.inline.TextLayoutManager.addElementsForAWordFragment(TextLayoutManager.java:1323) at org.apache.fop.layoutmgr.inline.TextLayoutManager.processWord(TextLayoutManager.java:944) at org.apache.fop.layoutmgr.inline.TextLayoutManager.getNextKnuthElements(TextLayoutManager.java:802) at org.apache.fop.layoutmgr.inline.InlineLayoutManager.getNextKnuthElements(InlineLayoutManager.java:330) at org.apache.fop.layoutmgr.inline.LineLayoutManager.collectInlineKnuthElements(LineLayoutManager.java:698) at org.apache.fop.layoutmgr.inline.LineLayoutManager.getNextKnuthElements(LineLayoutManager.java:627) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextChildElements(BlockLayoutManager.java:141) example attached -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FOP-2417) Exception caused by letter space handling in Chinese sentence
[ https://issues.apache.org/jira/browse/FOP-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2417. Resolution: Fixed Fix Version/s: trunk Applied a fix in http://svn.apache.org/viewvc?view=revisionrevision=1632522. I think the way the break opportunity after was being checked was not consistent with line GlyphMapping.java:273. Exception caused by letter space handling in Chinese sentence - Key: FOP-2417 URL: https://issues.apache.org/jira/browse/FOP-2417 Project: Fop Issue Type: Bug Reporter: Luis Bernardo Fix For: trunk Attachments: test.fo java.lang.IllegalArgumentException: factor 0; was: -1 at org.apache.fop.traits.MinOptMax.mult(MinOptMax.java:253) at org.apache.fop.layoutmgr.inline.TextLayoutManager.addElementsForAWordFragment(TextLayoutManager.java:1323) at org.apache.fop.layoutmgr.inline.TextLayoutManager.processWord(TextLayoutManager.java:944) at org.apache.fop.layoutmgr.inline.TextLayoutManager.getNextKnuthElements(TextLayoutManager.java:802) at org.apache.fop.layoutmgr.inline.InlineLayoutManager.getNextKnuthElements(InlineLayoutManager.java:330) at org.apache.fop.layoutmgr.inline.LineLayoutManager.collectInlineKnuthElements(LineLayoutManager.java:698) at org.apache.fop.layoutmgr.inline.LineLayoutManager.getNextKnuthElements(LineLayoutManager.java:627) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextChildElements(BlockLayoutManager.java:141) example attached -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FOP-2060) adjoining blocks with break-before=page break-after=page cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2060. Resolution: Fixed Fix Version/s: trunk Fixed in http://svn.apache.org/viewvc?view=revisionrevision=1632007. The reasoning behind the fix is discussed here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=6276 (i.e., a block should not generate an empty area and jump to the next page). adjoining blocks with break-before=page break-after=page cause extra empty page --- Key: FOP-2060 URL: https://issues.apache.org/jira/browse/FOP-2060 Project: Fop Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Luis Bernardo Fix For: trunk Attachments: test.fo, test.pdf This causes five pages instead of four: fo:block fo:blockpage 1/fo:block fo:block break-before=page break-after=pagepage 2/fo:block fo:block break-before=page break-after=pagepage 3/fo:block fo:blockpage 4/fo:block /fo:block The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: nightly snapshots page broken?
Yes, I saw that but I was not able to figure out how to fix it. This probably happened when we changed our site and it seems we need to provide the CI folks with a new header file. Clay, can you please follow up with INFRA-8443 and provide a new header file? On Wed, Oct 8, 2014 at 9:06 PM, Glenn Adams gl...@skynav.com wrote: Thanks! Now we need to fix the HTML on that page [1], which links appear to all be broken, missing style sheet, etc. [1] http://ci.apache.org/projects/xmlgraphics/fop/snapshots/ On Wed, Oct 8, 2014 at 11:51 AM, Luis Bernardo lmpmberna...@gmail.com wrote: This has been addressed by INFRA and the nightly builds link are working again. On 10/8/14, 12:17 AM, Luis Bernardo wrote: FYI, I submitted a request to INFRA (INFRA-8443) since I don't think we can fix this ourselves. The buildbot logs are here: http://ci.apache.org/builders/fop-trunk On 10/1/14, 4:14 PM, Glenn Adams wrote: thanks! i had an inquiry from someone looking for the nighly snapshots; i think it was working a few months ago, as i recall checking that page then and it showed recent builds On Wed, Oct 1, 2014 at 2:11 AM, Luis Bernardo lmpmberna...@gmail.com wrote: I think this was set up by Simon Pepping years ago and I don't know how this is configured but I will investigate. On Wed, Oct 1, 2014 at 3:30 AM, Glenn Adams gl...@skynav.com wrote: http://ci.apache.org/projects/xmlgraphics/fop/snapshots/ appears to be broken, with no links to builds, other broken links, etc clay? luis?
[jira] [Resolved] (FOP-2157) Deadlock in CompareUtil class
[ https://issues.apache.org/jira/browse/FOP-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2157. Resolution: Fixed Fix Version/s: trunk Patch by Jacopo applied:http://svn.apache.org/viewvc?view=revisionrevision=1630586. Nice test! Deadlock in CompareUtil class - Key: FOP-2157 URL: https://issues.apache.org/jira/browse/FOP-2157 Project: Fop Issue Type: Bug Components: unqualified Affects Versions: trunk Environment: Operating System: All Platform: PC Reporter: Matthias Reischenbacher Assignee: Alexios Giotis Fix For: trunk Attachments: FOP DEADLOCK jakarta_service_20121107.log, FOP-2157-test.patch, FOP-2157.patch, report-dump.txt, thread-dump.txt I'm getting a dead lock in the CompareUtil class, see the attached thread dump. Here small fragment of the thread dump [2012-11-07 14:06:25] [info] Found one Java-level deadlock: [2012-11-07 14:06:25] [info] = [2012-11-07 14:06:25] [info] [2012-11-07 14:06:25] [info] http-80-exec-58: [2012-11-07 14:06:25] [info] waiting to lock monitor 0x06ca9480 [2012-11-07 14:06:25] [info] (object 0x00071fe9bd00, a java.util.Vector) [2012-11-07 14:06:25] [info] , which is held by http-80-exec-5 [2012-11-07 14:06:25] [info] [2012-11-07 14:06:25] [info] http-80-exec-5: [2012-11-07 14:06:25] [info] waiting to lock monitor 0x116ecfc8 [2012-11-07 14:06:25] [info] (object 0x00071fe9a000, a java.util.Vector) [2012-11-07 14:06:25] [info] , which is held by http-80-exec-18 [2012-11-07 14:06:25] [info] [2012-11-07 14:06:25] [info] http-80-exec-18: [2012-11-07 14:06:25] [info] waiting to lock monitor 0x06ca9480 [2012-11-07 14:06:25] [info] (object 0x00071fe9bd00, a java.util.Vector) [2012-11-07 14:06:25] [info] , which is held by http-80-exec-5 [2012-11-07 14:06:25] [info] [2012-11-07 14:06:25] [info] [2012-11-07 14:06:25] [info] Java stack information for the threads listed above: [2012-11-07 14:06:25] [info] === [2012-11-07 14:06:25] [info] http-80-exec-58: [2012-11-07 14:06:25] [info] at java.util.Vector.equals(Vector.java:925) [2012-11-07 14:06:25] [info] - waiting to lock 0x00071fe9bd00 [2012-11-07 14:06:25] [info] (a java.util.Vector) [2012-11-07 14:06:25] [info] at org.apache.fop.util.CompareUtil.equal(CompareUtil.java:38) [2012-11-07 14:06:25] [info] at org.apache.fop.fo.properties.ListProperty.equals(ListProperty.java:123) [2012-11-07 14:06:25] [info] at org.apache.fop.fo.properties.PropertyCache.eq(PropertyCache.java:193) [2012-11-07 14:06:25] [info] at org.apache.fop.fo.properties.PropertyCache.fetch(PropertyCache.java:134) [2012-11-07 14:06:26] [info] at org.apache.fop.fo.properties.FontFamilyProperty$Maker.make(FontFamilyProperty.java:94) [2012-11-07 14:06:26] [info] at org.apache.fop.fo.PropertyList.convertAttributeToProperty(PropertyList.java:413) [2012-11-07 14:06:26] [info] at org.apache.fop.fo.PropertyList.addAttributesToList(PropertyList.java:321) [2012-11-07 14:06:26] [info] at org.apache.fop.fo.FObj.processNode(FObj.java:122) [2012-11-07 14:06:26] [info] at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:280) [2012-11-07 14:06:26] [info] at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:175) [2012-11-07 14:06:26] [info] at org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1073) [2012-11-07 14:06:26] [info] at org.apache.xml.serializer.TreeWalker.startNode(TreeWalker.java:359) [2012-11-07 14:06:26] [info] at org.apache.xml.serializer.TreeWalker.traverse(TreeWalker.java:145) [2012-11-07 14:06:26] [info] at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:390) [2012-11-07 14:06:26] [info] at smc.fop.FopWrapper.transform(FopWrapper.java:150) [2012-11-07 14:06:26] [info] at smc.fop.FopWrapper.transform(FopWrapper.java:125) [2012-11-07 14:06:26] [info] at smc.plugin.Dom2PDF.process(Dom2PDF.java:179) [2012-11-07 14:06:26] [info] at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source) [2012-11-07 14:06:26] [info] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [2012-11-07 14:06:26] [info] at java.lang.reflect.Method.invoke(Method.java:597) [2012-11-07 14:06:26] [info] at smc.transform.core.dynacode.DynaCode$MyInvocationHandler.invoke(DynaCode.java:374) [2012-11-07 14:06:26] [info] at $Proxy35.process(Unknown Source) [2012-11-07 14:06:26] [info] at smc.transform.core.TransformerStep.processDocument(TransformerStep.java:211) [2012-11-07 14:06:26] [info
Re: nightly snapshots page broken?
This has been addressed by INFRA and the nightly builds link are working again. On 10/8/14, 12:17 AM, Luis Bernardo wrote: FYI, I submitted a request to INFRA (INFRA-8443) since I don't think we can fix this ourselves. The buildbot logs are here: http://ci.apache.org/builders/fop-trunk On 10/1/14, 4:14 PM, Glenn Adams wrote: thanks! i had an inquiry from someone looking for the nighly snapshots; i think it was working a few months ago, as i recall checking that page then and it showed recent builds On Wed, Oct 1, 2014 at 2:11 AM, Luis Bernardo lmpmberna...@gmail.com mailto:lmpmberna...@gmail.com wrote: I think this was set up by Simon Pepping years ago and I don't know how this is configured but I will investigate. On Wed, Oct 1, 2014 at 3:30 AM, Glenn Adams gl...@skynav.com mailto:gl...@skynav.com wrote: http://ci.apache.org/projects/xmlgraphics/fop/snapshots/ appears to be broken, with no links to builds, other broken links, etc clay? luis?
Re: nightly snapshots page broken?
FYI, I submitted a request to INFRA (INFRA-8443) since I don't think we can fix this ourselves. The buildbot logs are here: http://ci.apache.org/builders/fop-trunk On 10/1/14, 4:14 PM, Glenn Adams wrote: thanks! i had an inquiry from someone looking for the nighly snapshots; i think it was working a few months ago, as i recall checking that page then and it showed recent builds On Wed, Oct 1, 2014 at 2:11 AM, Luis Bernardo lmpmberna...@gmail.com mailto:lmpmberna...@gmail.com wrote: I think this was set up by Simon Pepping years ago and I don't know how this is configured but I will investigate. On Wed, Oct 1, 2014 at 3:30 AM, Glenn Adams gl...@skynav.com mailto:gl...@skynav.com wrote: http://ci.apache.org/projects/xmlgraphics/fop/snapshots/ appears to be broken, with no links to builds, other broken links, etc clay? luis?
Re: Question on FOP release schedule
I can apply your patch although I do not have the environment to test it. Regarding the question about a bug fix for 1.1, the answer is that there is nothing planned but if there is interest from the FOP users I think that can be accommodated. Is there any other bug your would like to see fixed in a 1.1+ release? On 10/2/14, 7:22 PM, Jacopo Cappellato wrote: Hi all, I am a committer for Apache OFBiz, a project that uses FOP 1.1 (thanks for this amazing product). I hope this is the right list to get some information about the release process and planning of Apache FOP. Apart from FOP 2.0, is there a plan to release a bug fix release for 1.1? For example, we may be specifically interested in getting a new release with this issue resolved: https://issues.apache.org/jira/browse/FOP-2157 (in the ticket I have attached a fix for the same). Is there something we could do to support you in the process? Thank you, Jacopo
Re: nightly snapshots page broken?
I think this was set up by Simon Pepping years ago and I don't know how this is configured but I will investigate. On Wed, Oct 1, 2014 at 3:30 AM, Glenn Adams gl...@skynav.com wrote: http://ci.apache.org/projects/xmlgraphics/fop/snapshots/ appears to be broken, with no links to builds, other broken links, etc clay? luis?
[jira] [Commented] (FOP-2408) [complex scripts] page number and text getting too close in the header
[ https://issues.apache.org/jira/browse/FOP-2408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14117520#comment-14117520 ] Luis Bernardo commented on FOP-2408: Confirmed. Replacing fo:page-number / by 1 does not show the problem so the issue is due to the resolution of page number. [complex scripts] page number and text getting too close in the header -- Key: FOP-2408 URL: https://issues.apache.org/jira/browse/FOP-2408 Project: Fop Issue Type: Bug Affects Versions: trunk Environment: DITA-OT 1.8.4 FOP from trunk (07/18/2014) Reporter: Red Shen Attachments: fop.pdf, no_complex_scripts.pdf, topic.fo -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [GUMP@vmgump]: Project xml-fop-test (in module xml-fop) failed
The fact that gump uses a snapshot for checkstyle is not new but the version (of the snapshot) was bumped to 5.8 from 5.7. I think we may have to upgrade too... I believe Vincent tried to force gump to use our own checkstyle version and it was not simple. On Fri, Aug 15, 2014 at 4:29 PM, Simon Steiner simonsteiner1...@gmail.com wrote: Hi, Could be stick to a released version of checkstyle otherwise its hard to run locally. Thanks -Original Message- From: Chris Bowditch [mailto:bowditch_ch...@hotmail.com] Sent: 15 August 2014 16:09 To: fop-dev@xmlgraphics.apache.org Subject: Re: [GUMP@vmgump]: Project xml-fop-test (in module xml-fop) failed Hi Glenn, Luis mentioned to me that Gump had upgraded the Checkstyle version. Thanasis should have some time to look into the failures next week. Thanks Chris On 15/08/2014 02:17, Glenn Adams wrote: Whatever this problem is doesn't seem related to my recent findbugs changes. It looks like the checkstyle rules being run by gump don't correspond to what is in trunk, since I am not seeing any of these warnings (using Checkstyle 5.7). I also wonder why an unreleased (snapshot) of Checkstyle 5.8 is being used by gump. On Thu, Aug 14, 2014 at 7:10 PM, FOP Gump Nightly Build fop-dev@xmlgraphics.apache.org mailto:fop-dev@xmlgraphics.apache.org wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org mailto:gene...@gump.apache.org. Project xml-fop-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 9 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - xml-fop-test : XSL-FO (Formatting Objects) processor Full details are available at: http://vmgump.apache.org/gump/public/xml-fop/xml-fop-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on checkstyle exists, no need to add for property checkstyle.location. -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/xml-fop/build/test-reports The following work was performed: http://vmgump.apache.org/gump/public/xml-fop/xml-fop-test/gump_work/build_xml-fop_xml-fop-test.html Work Name: build_xml-fop_xml-fop-test (Type: Build) Work ended in a state of : Failed Elapsed: 3 mins 50 secs Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only -Dant.build.clonevm=true -Xbootclasspath/p:/srv/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar:/srv/gump/public/workspace/xml-xalan/build/serializer.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dcheckstyle.location=/srv/gump/public/workspace/checkstyle/target/checkstyle-5.8-SNAPSHOT.jar gump-test [Working Directory: /srv/gump/public/workspace/xml-fop] CLASSPATH: /usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/xml-fop/build/classes:/srv/gump/public/workspace/xml-fop/build/codegen-classes:/srv/gump/public/workspace/xml-fop/build/test-classes:/srv/gump/public/workspace/xml-fop/lib/build/asm-3.1.jar:/srv/gump/public/workspace/xml-fop/lib/build/mockito-core-1.8.5.jar:/srv/gump/public/workspace/xml-fop/lib/build/hamcrest.core-1.1.0.jar:/srv/gump/public/workspace/xml-fop/lib/build/objenesis-1.0.0.jar:/srv/gump/public/workspace/xml-fop/lib/build/qdox-1.12.jar:/srv/gump/public/workspace/xml-fop/lib/fontbox-1.8.5.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-5.8-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-20140815.jar:/srv/gump/public/workspace/apache-commons/cli/target/commons-cli-1.3-SNAPSHOT.jar:/srv/gump/public/workspace/commons-collections-3.x/target/commons-collections-3.3-SNAPSHOT.jar:/srv/gump/public/workspace/apach
[jira] [Commented] (FOP-2403) FOP 1.1 throws a Null pointer exception when FOP 1.0 does not
[ https://issues.apache.org/jira/browse/FOP-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14088991#comment-14088991 ] Luis Bernardo commented on FOP-2403: To get the NPE we need to run in relaxed mode (-r). There is a table with an empty table-body and that is the problem. So the relaxed mode needs to gracefully handle this or not handle at all. FOP 1.1 throws a Null pointer exception when FOP 1.0 does not - Key: FOP-2403 URL: https://issues.apache.org/jira/browse/FOP-2403 Project: Fop Issue Type: Bug Components: renderer/pdf Affects Versions: 1.1 Environment: Ubuntu 12.04 Reporter: Mike G Attachments: fo.xml When trying to render a FO file to a PDF, FOP 1.1 will crash with a null pointer exception, while FOP 1.0 does not. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (FOP-2403) FOP 1.1 throws a Null pointer exception when FOP 1.0 does not
[ https://issues.apache.org/jira/browse/FOP-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo reopened FOP-2403: FOP 1.1 throws a Null pointer exception when FOP 1.0 does not - Key: FOP-2403 URL: https://issues.apache.org/jira/browse/FOP-2403 Project: Fop Issue Type: Bug Components: renderer/pdf Affects Versions: 1.1 Environment: Ubuntu 12.04 Reporter: Mike G Attachments: fo.xml When trying to render a FO file to a PDF, FOP 1.1 will crash with a null pointer exception, while FOP 1.0 does not. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Table Border Anti Aliasing Issue
On 8/5/14, 8:44 AM, Vincent Hennebert wrote: On 04/08/14 23:30, Luis Bernardo wrote: I looked at this in the past. I think I understand what you mean by shapes and solid lines but I don't think the issue is that. The problem, as I understood it, is caused by the fact we draw many segments now where before there was only one. So if you have a row with 5 cells the top and bottom sides of the row are drawn as 5 segments (one for each cell) where before (with 0.20.5) there was just one segment spanning the 5 cells. The issue is really with the viewer, not with FOP, but it does make sense to come up with a workaround. So, if I were to tackle this, I think my first approach would be something similar to your suggestion 2. I would do it on the PDF renderer, since this only affects PDF (or we only care about that), and it would go like this: when The challenge will be to pass the information to the PDF renderer that we are dealing with a table. Renderers don’t have that information, all they know is that they are drawing a block with borders all around. Re-constructing that information is likely to be hard, messy and error-prone. Best would probably be to handle that in TableLM where all the information still is available. Yes, I am aware that the renderer does not know about tables. But in fact that knowledge is not even necessary. Just knowing the segments would be enough and this would be done at page level, not table level (which can in any case span more than one page). And the algorithm would be a lot simpler than one might image, specially because the segments are drawn in some natural order which would make the algorithm fast too (something like this: is the next segment horizontal? yes; do we have a segment with the same Y? yes; do the ends touch? yes; is the thickness and color the same? yes; them merge them to make just one segment; next segment...). But if we want to do the same in PostScript then I agree that doing this before we get to the renderer is better. There you could have an object that holds a grid, with cells contributing to it as they are processed. Then you would decide what is the most common pattern (say, 1pt solid black), reset it on cells (so that they only keep border information for non-standard borders), and pass this object to renderers. BTW, the PostScript renderer might well benefit from that too, as I remember complaints in the past that the file size was growing too big due to all the drawing commands generated solely for borders. you get the commands to draw the sides of the cells do not draw them and instead collect them. Once you you are done with the table, use an algorithm that analyzes the segments and outputs a set of lines (and their positions) that correspond to the sides of the rows and columns. Then draw those lines, that form a grid, in one go. The fact that you use shapes or lines for that should not make a difference. On 8/4/14, 4:38 PM, Matthias Reischenbacher wrote: Hi, I've gotten the request from multiple of my clients to look into the border display issues caused by anti aliasing in PDF viewers. I'm aware that printing the PDF documents generated by FOP is never the issue, but when viewing, there definitely is (I know that anti aliasing can be disabled in Adobe Acrobat, but I can't control my users environment). Since viewing PDF files on electric devices is getting more and more important, I think it's worth to have a new look on this issue. Digging around in the FOP mailing lists, I've discovered that PDF viewers don't like that table borders are rendered with shapes instead of lines. I'm aware that shapes are used for supporting all border styles of the xsl-fo spec. The thing is that 99% of my clients use only solid lines, so it is important to improve the display quality here. AFAIK there are two possible ways to achieve this: 1. Fallback to the old (0.20.5) table border rendering code, if only solid lines are used inside a table. 2. Algorithm for merging shapes if width, color and style match. Are you aware of any other ways to improve this? I'll start to investigate both approaches in the next view days, so I can't say much about the viability and expected dev time yet. Perhaps some of you has already started to do some work or research on this issue and wants to share his experience. Personally I'm more inclined towards approach #2, but I have a limited time budget to achieve this, so if #2 involves a lot of work I'd go for #1. Best regards, Matthias Vincent
Re: Table Border Anti Aliasing Issue
I looked at this in the past. I think I understand what you mean by shapes and solid lines but I don't think the issue is that. The problem, as I understood it, is caused by the fact we draw many segments now where before there was only one. So if you have a row with 5 cells the top and bottom sides of the row are drawn as 5 segments (one for each cell) where before (with 0.20.5) there was just one segment spanning the 5 cells. The issue is really with the viewer, not with FOP, but it does make sense to come up with a workaround. So, if I were to tackle this, I think my first approach would be something similar to your suggestion 2. I would do it on the PDF renderer, since this only affects PDF (or we only care about that), and it would go like this: when you get the commands to draw the sides of the cells do not draw them and instead collect them. Once you you are done with the table, use an algorithm that analyzes the segments and outputs a set of lines (and their positions) that correspond to the sides of the rows and columns. Then draw those lines, that form a grid, in one go. The fact that you use shapes or lines for that should not make a difference. On 8/4/14, 4:38 PM, Matthias Reischenbacher wrote: Hi, I've gotten the request from multiple of my clients to look into the border display issues caused by anti aliasing in PDF viewers. I'm aware that printing the PDF documents generated by FOP is never the issue, but when viewing, there definitely is (I know that anti aliasing can be disabled in Adobe Acrobat, but I can't control my users environment). Since viewing PDF files on electric devices is getting more and more important, I think it's worth to have a new look on this issue. Digging around in the FOP mailing lists, I've discovered that PDF viewers don't like that table borders are rendered with shapes instead of lines. I'm aware that shapes are used for supporting all border styles of the xsl-fo spec. The thing is that 99% of my clients use only solid lines, so it is important to improve the display quality here. AFAIK there are two possible ways to achieve this: 1. Fallback to the old (0.20.5) table border rendering code, if only solid lines are used inside a table. 2. Algorithm for merging shapes if width, color and style match. Are you aware of any other ways to improve this? I'll start to investigate both approaches in the next view days, so I can't say much about the viability and expected dev time yet. Perhaps some of you has already started to do some work or research on this issue and wants to share his experience. Personally I'm more inclined towards approach #2, but I have a limited time budget to achieve this, so if #2 involves a lot of work I'd go for #1. Best regards, Matthias
Re: Summary of findbugs exclusions
I suggest also to make running findbugs part of the default ant task so that we don't forget to do it! On 8/4/14, 5:43 PM, Glenn Adams wrote: I have performed a brief study of the current findbugs exclusions file. At present there are 1094 exclusions covering 101 distinct exclusions types. Of these types, half (~50) have 3 or fewer exclusions. I plan to start cleaning up these exclusions by first fixing all types having 10 or fewer exclusions. This will leave approximately 25 types of exclusions to handle in a second fix pass. Eventually, I will identify in the exclusions file all exclusion types that should not be permitted to be added, i.e., that must be fixed. I expect that some exclusion types will remain, such as: * BC_UNCONFIRMED_CAST * EI_EXPOSE_REP * EI_EXPOSE_REP2 * PZLA_PREFER_ZERO_LENGTH_ARRAYS * UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR Those that remain (and added in the future) should be subject to an explicit design choice, and not merely to silence a warning. Once I sort this out, I will ask for a vote on enabling findbugs in nightly builds.
[jira] [Resolved] (FOP-2307) [PATCH] Weird border color inheritance (hashCode collisions)
[ https://issues.apache.org/jira/browse/FOP-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2307. Resolution: Fixed good catch! fix applied: http://svn.apache.org/viewvc?view=revisionrevision=1613805. [PATCH] Weird border color inheritance (hashCode collisions) Key: FOP-2307 URL: https://issues.apache.org/jira/browse/FOP-2307 Project: Fop Issue Type: Bug Components: renderer/pdf Affects Versions: 1.1 Environment: Windows 7/64-bit, Oracle JDK 7.0.45 64-bit Reporter: Jan Tošovský Labels: border, cmyk, color Fix For: trunk Attachments: FOP-2307-NOT_FOR_COMMIT.patch, fop-2307.patch When I define an object with a specific border and the thickness of this border matches with the one defined in the static-content, the latter color is used instead. But it appears only if my object color is specified using the pseudo #CMYK profile. It can be tested with this simplified test case: http://drifted.in/other/_border.fo http://drifted.in/other/_border.pdf The first object border uses the standard color so it is unaffected. The second is affected. The third uses a different thickness (3.5pt instead of 2.5) so it is also unaffected. In the generating log there are lot of following hashCode collisions so I suppose it relates together: X 23, 2013 5:09:34 ODP. org.apache.fop.fo.properties.PropertyCache fetch INFO: 60 hashCode() collisions for org.apache.fop.fo.properties.ColorProperty X 23, 2013 5:09:34 ODP. org.apache.fop.fo.properties.PropertyCache fetch INFO: 70 hashCode() collisions for org.apache.fop.fo.properties.ColorProperty -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FOP-2107) org.apache.batik.bridge.BridgeException: Unable to make sense of URL for connection
[ https://issues.apache.org/jira/browse/FOP-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14075643#comment-14075643 ] Luis Bernardo commented on FOP-2107: revised the fix to handle the issue on the batik side instead: http://svn.apache.org/viewvc?view=revisionrevision=1613810 and http://svn.apache.org/viewvc?view=revisionrevision=1613811. org.apache.batik.bridge.BridgeException: Unable to make sense of URL for connection --- Key: FOP-2107 URL: https://issues.apache.org/jira/browse/FOP-2107 Project: Fop Issue Type: Bug Components: renderer/svg Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Luis Bernardo Fix For: trunk The example provided by XGC-45 cannot be run with the current trunk. The console error is this when generating PDF: SVG graphic could not be built. Reason: org.apache.batik.bridge.BridgeException: Unable to make sense of URL for connection org.apache.batik.bridge.BridgeException: Unable to make sense of URL for connection The resulting PDF document does not include the SVG. This was not the case in FOP-1.0, where the generated PDF would include the SVG. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FOP-2398) [AFP] Image written as having 72 DPI instead of its intrinstic resolution
[ https://issues.apache.org/jira/browse/FOP-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070229#comment-14070229 ] Luis Bernardo commented on FOP-2398: Yes, the image has an EXIF entry but apparently is missing many of the expected tags (see http://www.media.mit.edu/pia/Research/deepview/exif.html) and that is the source of the problem. This needs to be investigated. Meanwhile set your source-resolution to 96 in the config file and you should get the same behavior as before. [AFP] Image written as having 72 DPI instead of its intrinstic resolution - Key: FOP-2398 URL: https://issues.apache.org/jira/browse/FOP-2398 Project: Fop Issue Type: Bug Components: renderer/afp Affects Versions: trunk Reporter: Seifeddine Dridi Priority: Minor Attachments: afp-config.xml, bug-image-dpi.afp, bug-image-dpi.fo, image.jpg Prior to a change made in XMLGraphicsCommons (https://issues.apache.org/jira/browse/XGC-87), rendering the attached FO to AFP always results in an image with its original resolution. Now the image is written with the default resolution of 72 DPI. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FOP-2398) [AFP] Image written as having 72 DPI instead of its intrinstic resolution
[ https://issues.apache.org/jira/browse/FOP-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070260#comment-14070260 ] Luis Bernardo commented on FOP-2398: Fixed in http://svn.apache.org/viewvc?view=revisionrevision=1612567 and http://svn.apache.org/viewvc?view=revisionrevision=1612568. Default source resolution is only used if not set yet (in the APP0 segment). [AFP] Image written as having 72 DPI instead of its intrinstic resolution - Key: FOP-2398 URL: https://issues.apache.org/jira/browse/FOP-2398 Project: Fop Issue Type: Bug Components: renderer/afp Affects Versions: trunk Reporter: Seifeddine Dridi Priority: Minor Fix For: trunk Attachments: afp-config.xml, bug-image-dpi.afp, bug-image-dpi.fo, image.jpg Prior to a change made in XMLGraphicsCommons (https://issues.apache.org/jira/browse/XGC-87), rendering the attached FO to AFP always results in an image with its original resolution. Now the image is written with the default resolution of 72 DPI. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (FOP-2398) [AFP] Image written as having 72 DPI instead of its intrinstic resolution
[ https://issues.apache.org/jira/browse/FOP-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2398. Resolution: Fixed Fix Version/s: trunk [AFP] Image written as having 72 DPI instead of its intrinstic resolution - Key: FOP-2398 URL: https://issues.apache.org/jira/browse/FOP-2398 Project: Fop Issue Type: Bug Components: renderer/afp Affects Versions: trunk Reporter: Seifeddine Dridi Priority: Minor Fix For: trunk Attachments: afp-config.xml, bug-image-dpi.afp, bug-image-dpi.fo, image.jpg Prior to a change made in XMLGraphicsCommons (https://issues.apache.org/jira/browse/XGC-87), rendering the attached FO to AFP always results in an image with its original resolution. Now the image is written with the default resolution of 72 DPI. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FOP-2396) font tag attribute embed-url is expecting absoulte-URL
[ https://issues.apache.org/jira/browse/FOP-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070600#comment-14070600 ] Luis Bernardo commented on FOP-2396: please provide information regarding the version you are using, whether you are running from the command line, and whether the current directory is the same where the FO file, the config file, and the fonts directory are. font tag attribute embed-url is expecting absoulte-URL -- Key: FOP-2396 URL: https://issues.apache.org/jira/browse/FOP-2396 Project: Fop Issue Type: Bug Reporter: ramakanthreddy Hi, I have specified the font tag as below: font kerning=yes embed-url=fonts/arial.ttf font-triplet name=Arial style=normal weight=normal/ font-triplet name=ArialMT style=normal weight=normal/ /font but the code is expecting absoulte-URL.throws error as below when specify the relative path org.apache.fop.apps.FOPException: Failed to resolve font with embed-url 'fonts/arial.ttf' at org.apache.fop.util.LogUtil.handleError(LogUtil.java:42) at org.apache.fop.fonts.FontInfoConfigurator.getFontInfo(FontInfoConfigurator.java:210) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FOP-2307) Weird border color inheritance (hashCode collisions)
[ https://issues.apache.org/jira/browse/FOP-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14068590#comment-14068590 ] Luis Bernardo commented on FOP-2307: I am able to reproduce with FOP 1.1 but not with trunk. The fix, which I think was accidental, is traced to this commit: http://svn.apache.org/viewvc?view=revisionrevision=1401607. I think Alexios analysis is correct and the hashCode needs to take into account the alternativeColors. Weird border color inheritance (hashCode collisions) Key: FOP-2307 URL: https://issues.apache.org/jira/browse/FOP-2307 Project: Fop Issue Type: Bug Components: renderer/pdf Affects Versions: 1.1 Environment: Windows 7/64-bit, Oracle JDK 7.0.45 64-bit Reporter: Jan Tošovský Labels: border, cmyk, color When I define an object with a specific border and the thickness of this border matches with the one defined in the static-content, the latter color is used instead. But it appears only if my object color is specified using the pseudo #CMYK profile. It can be tested with this simplified test case: http://drifted.in/other/_border.fo http://drifted.in/other/_border.pdf The first object border uses the standard color so it is unaffected. The second is affected. The third uses a different thickness (3.5pt instead of 2.5) so it is also unaffected. In the generating log there are lot of following hashCode collisions so I suppose it relates together: X 23, 2013 5:09:34 ODP. org.apache.fop.fo.properties.PropertyCache fetch INFO: 60 hashCode() collisions for org.apache.fop.fo.properties.ColorProperty X 23, 2013 5:09:34 ODP. org.apache.fop.fo.properties.PropertyCache fetch INFO: 70 hashCode() collisions for org.apache.fop.fo.properties.ColorProperty -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FOP-2395) PDF encryption does not work when PDF version is set in FOP config
[ https://issues.apache.org/jira/browse/FOP-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14066185#comment-14066185 ] Luis Bernardo commented on FOP-2395: apparently some of the checks are not consistent. but you should not need to set the version to 1.4 since it is the default, and encryption length of 128 is now the default either. remove the version from the configuration file for now. if you were to set the encryption length to 256 then that would bump the version to 1.7, unless you had explicitly set it to a different version, in which case changing the version would not be allowed and you would get a message similar to what you got. so something is not right in the code since you are not using 256. PDF encryption does not work when PDF version is set in FOP config -- Key: FOP-2395 URL: https://issues.apache.org/jira/browse/FOP-2395 Project: Fop Issue Type: Bug Components: renderer/pdf Affects Versions: trunk Reporter: Seifeddine Dridi Priority: Blocker Attachments: fop-pdf-encryption.xconf, test.xml After setting PDF version to 1.4 or any other version in FOP configuration, an exception is thrown Cannot change the version of this PDF document. A warning is also printed which I find confusing Configured encryption requires PDF version 1.4 but version has been set to 1.4. Does this mean that encryption does not work when I explicitly set my PDF version? It used to work before applying this commit (https://issues.apache.org/jira/browse/FOP-2248). Anyone can explain what has changed exactly in the encryption algorithm? Thank you -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (FOP-2395) PDF encryption does not work when PDF version is set in FOP config
[ https://issues.apache.org/jira/browse/FOP-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2395. Resolution: Fixed Fix Version/s: trunk Indeed. Fixed in http://svn.apache.org/viewvc?view=revisionrevision=1611834. PDF encryption does not work when PDF version is set in FOP config -- Key: FOP-2395 URL: https://issues.apache.org/jira/browse/FOP-2395 Project: Fop Issue Type: Bug Components: renderer/pdf Affects Versions: trunk Reporter: Seifeddine Dridi Priority: Blocker Fix For: trunk Attachments: fop-pdf-encryption.xconf, test.xml After setting PDF version to 1.4 or any other version in FOP configuration, an exception is thrown Cannot change the version of this PDF document. A warning is also printed which I find confusing Configured encryption requires PDF version 1.4 but version has been set to 1.4. Does this mean that encryption does not work when I explicitly set my PDF version? It used to work before applying this commit (https://issues.apache.org/jira/browse/FOP-2248). Anyone can explain what has changed exactly in the encryption algorithm? Thank you -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2352) Unable to render Arabic Text using Apache FOP
[ https://issues.apache.org/jira/browse/FOP-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo updated FOP-2352: --- Attachment: out.pdf Try to use just Arial.ttf, not Arialuni.ttf. Attached output using Arial.ttf and version 1.1 in Windows. Unable to render Arabic Text using Apache FOP - Key: FOP-2352 URL: https://issues.apache.org/jira/browse/FOP-2352 Project: Fop Issue Type: Bug Components: renderer/pdf Affects Versions: 0.95, 1.0, 1.1 Environment: Operating System:Windows Java version : 1.6 Reporter: ramakanthreddy Priority: Critical Attachments: out.pdf, readArabicText.txt, src.zip, test.pdf, userconfig.xml When trying to render arabic text using Apache FOP # is displayed in pdf file instead of arabic text. Working fine for french and english but fails for arabic Characterset used is : UTF-8 and StreamSource type is StringReader -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FOP-2352) Unable to render Arabic Text using Apache FOP
[ https://issues.apache.org/jira/browse/FOP-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14064720#comment-14064720 ] Luis Bernardo commented on FOP-2352: Change the embed-url value to point to Arial.ttf, not Arialuni.ttf. Does the attached out.pdf look OK? Unable to render Arabic Text using Apache FOP - Key: FOP-2352 URL: https://issues.apache.org/jira/browse/FOP-2352 Project: Fop Issue Type: Bug Components: renderer/pdf Affects Versions: 0.95, 1.0, 1.1 Environment: Operating System:Windows Java version : 1.6 Reporter: ramakanthreddy Priority: Critical Attachments: out.pdf, readArabicText.txt, src.zip, test.pdf, userconfig.xml When trying to render arabic text using Apache FOP # is displayed in pdf file instead of arabic text. Working fine for french and english but fails for arabic Characterset used is : UTF-8 and StreamSource type is StringReader -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (FOP-2352) Unable to render Arabic Text using Apache FOP
[ https://issues.apache.org/jira/browse/FOP-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2352. Resolution: Not a Problem Since the document I generated with FOP 1.1 in Windows with the Arial font is correct then the issue is in your environment/configuration/code. Probably your configuration file is not being used by your code. Try to configure a font that does not exist and see if you get an exception. We can help you sort this out in the mailing list. But you should try to run from the command line before you try anything else. Unable to render Arabic Text using Apache FOP - Key: FOP-2352 URL: https://issues.apache.org/jira/browse/FOP-2352 Project: Fop Issue Type: Bug Components: renderer/pdf Affects Versions: 0.95, 1.0, 1.1 Environment: Operating System:Windows Java version : 1.6 Reporter: ramakanthreddy Priority: Critical Attachments: out.pdf, readArabicText.txt, src.zip, test.pdf, userconfig.xml When trying to render arabic text using Apache FOP # is displayed in pdf file instead of arabic text. Working fine for french and english but fails for arabic Characterset used is : UTF-8 and StreamSource type is StringReader -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [VOTE] Merge Temp_FontMerging to trunk
I tested the code with some examples from a weekly newsletter that I receive -- this is a good example because the newsletter is always created using the same template and the same set of fonts (with a few exceptions). The code worked mostly well but the output was not perfect with some of the fonts, where some glyphs were missing of misplaced (causing overlap). So there is still work to be done. Nevertheless, and since the feature is disabled by default, I think there is value in merging this to trunk because it does work in many situations. Besides I don't know if the problem is due to this patch or to PDFBox. Hence +1. Note: I will send the examples directly to Simon. On 6/20/14, 12:23 PM, Simon Steiner wrote: Hi, I have been working on merging fonts inside pdf external graphic using the pdf-plugin. The feature is disabled by default and can be enabled using fop.xconf: fop version=1.0 renderers renderer mime=application/pdf merge-fontstrue/merge-fonts /renderer /renderers /fop It is using pdfbox 2.0 snapshot which requires Java 6 or later so you vote needs to agree to end support for Java 5 on trunk. It is supporting fonts of type CFF, Truetype, CID and Type1. The vote will last 5 working days, ending next Friday. https://issues.apache.org/jira/browse/FOP-2302 https://svn.apache.org/repos/asf/xmlgraphics/fop-pdf-images/branches/Temp_FontMerging https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_FontMerging Here is my vote: +1 Thanks
[jira] [Updated] (FOP-2384) TTF and PS renderer
[ https://issues.apache.org/jira/browse/FOP-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo updated FOP-2384: --- Attachment: example.ps fop.xconf example.fo See attached example (output generated with trunk). TTF and PS renderer --- Key: FOP-2384 URL: https://issues.apache.org/jira/browse/FOP-2384 Project: Fop Issue Type: Bug Components: font/postscript Affects Versions: 1.1 Environment: Operating system - windows and Linux, RAM - 2 GB or more Reporter: Shishir Fix For: 1.1 Attachments: example.fo, example.ps, fontTripletTTF.xml, fop.xconf, fopOutLineFonts240.xconf, scenario 1.zip, scenario 2.zip Hi, I wish to understand whether we can use TTF fonts for PS output generation or not? (using FOP1.1) I tried few combinations and below are the findings:- 1)There was no issue with single page PS output if we use TTF font. 2)Multipage output works well in a specific scenario. It worked fine for “scenario 1” whereas failed for “scenario 2” Scenario 1 - All the English characters used on page 2 were already used/rendered on page 1. (Please see attached scenario1.zip – this includes .fo and .ps output file) Scenario 2 - page 2 has some english characters those are not present on page1. (Please see attached scenario2.zip – this includes .fo and .ps output file) I have also attached .xconf and ttf fonts that we are using. Please let us know if you need any more details. Thanks, Shishir -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FOP-2384) TTF and PS renderer
[ https://issues.apache.org/jira/browse/FOP-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016441#comment-14016441 ] Luis Bernardo commented on FOP-2384: This works if you use trunk and set optimize-resources to true (under the postscript renderer section in the fop.xconf file). TTF and PS renderer --- Key: FOP-2384 URL: https://issues.apache.org/jira/browse/FOP-2384 Project: Fop Issue Type: Bug Components: font/postscript Affects Versions: 1.1 Environment: Operating system - windows and Linux, RAM - 2 GB or more Reporter: Shishir Fix For: 1.1 Attachments: fontTripletTTF.xml, fopOutLineFonts240.xconf, scenario 1.zip, scenario 2.zip Hi, I wish to understand whether we can use TTF fonts for PS output generation or not? (using FOP1.1) I tried few combinations and below are the findings:- 1)There was no issue with single page PS output if we use TTF font. 2)Multipage output works well in a specific scenario. It worked fine for “scenario 1” whereas failed for “scenario 2” Scenario 1 - All the English characters used on page 2 were already used/rendered on page 1. (Please see attached scenario1.zip – this includes .fo and .ps output file) Scenario 2 - page 2 has some english characters those are not present on page1. (Please see attached scenario2.zip – this includes .fo and .ps output file) I have also attached .xconf and ttf fonts that we are using. Please let us know if you need any more details. Thanks, Shishir -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (FOP-2376) PS rendering does not support complex scripts
[ https://issues.apache.org/jira/browse/FOP-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2376. Resolution: Duplicate I think this has been addressed in FOP-2206. PS rendering does not support complex scripts - Key: FOP-2376 URL: https://issues.apache.org/jira/browse/FOP-2376 Project: Fop Issue Type: New Feature Components: renderer/ps Affects Versions: 1.1, trunk Reporter: Glenn Adams The PS renderer does not support complex scripts. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (FOP-2378) PCL rendering doesn't support complex scripts
[ https://issues.apache.org/jira/browse/FOP-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2378. Resolution: Duplicate FOP-2250 addresses this but it has only been partially tested. PCL rendering doesn't support complex scripts - Key: FOP-2378 URL: https://issues.apache.org/jira/browse/FOP-2378 Project: Fop Issue Type: New Feature Components: renderer/pcl Affects Versions: 1.1, trunk Reporter: Glenn Adams The PCL renderer does not support complex scripts. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Why integrating DITA into XMLGraphics makes sense.
I think this only shows that the person is not going to the source (i.e., the FOP user mailing list) to request help. The example shown can be greatly improved by using fo:leader width=100% leader-pattern=use-content./fo:leader instead of fo:leader leader-pattern=dots / The FOP implementation repeats 3 dots (...) when using the leader-pattern=dots which is not very intelligent since it can lead to misalignment many times. But by specifying the leader content as just one dot the result can be greatly improved, although I agree that there is room for improvement in this feature. On 5/23/14, 4:14 PM, Ron Wheeler wrote: The conversation below shows one of the reasons why I would like to see DITA become part of the XMLGraphics family. One of the most experienced and influential DITA practitioners is giving advice about the suitability of FOP for producing correct PDFs. Ron - This is an issue with the FOP XSL-FO engine (one of many). For top-qualify PDF output you really need to license Antenna House XSL Formatter or RenderX XEP, both of which produce excellent results. FOP simply has too many bugs and limitations to be generally useful for production PDF generation using XSL-FO, unfortunately. Cheers, XXX On 5/23/14, 9:54 AM, yyy [dita-users] dita-us...@yahoogroups.com wrote: [Attachment(s) #TopText from Mark Peters included below] Hi, Using DITA-OT 1.7 and the default org.dita.pdf2 plugin, I notice that some TOC entries are randomly misaligned slightly. The leader extends one or two extra dots. For example (not sure if the formatting will come through correctly. An image is also attached): Chapter 1: RTI4T System Overview...11 RTI System Diagram.12 System Components...12 RTI Network Diagram...15 Summary of RTI Setup Tasks...15 Like I said, the misalignment is random. It's not all H1s or H2s, for example, which would probably be relatively easy to fix. Even more puzzling, the XSL-FO attributes in the temp files are identical for nodes at the same level that have different alignments. For example, here are two H1-level nodes. The first node is slightly misaligned. But the indent values are identical for both nodes. fo:block start-indent=25pt + (1 * 30pt) + 14pt fo:block end-indent=22pt font-size=10pt font-weight=normal last-line-end-indent=-22pt text-align=justify text-align-last=justify text-indent=-14pt fo:basic-link internal-destination=_OPENTOPIC_TOC_PROCESSING_d70e1310 line-height=150% fo:inline end-indent=14ptRTI System Diagram/fo:inline fo:inline keep-together.within-line=always start-indent=-14pt fo:leader leader-pattern=dots/ fo:page-number-citation ref-id=_OPENTOPIC_TOC_PROCESSING_d70e1310/ /fo:inline /fo:basic-link /fo:block /fo:block fo:block start-indent=25pt + (1 * 30pt) + 14pt fo:block end-indent=22pt font-size=10pt font-weight=normal last-line-end-indent=-22pt text-align=justify text-align-last=justify text-indent=-14pt fo:basic-link internal-destination=_OPENTOPIC_TOC_PROCESSING_d70e1334 line-height=150% fo:inline end-indent=14pt System Components /fo:inline fo:inline keep-together.within-line=always start-indent=-14pt fo:leader leader-pattern=dots/ fo:page-number-citation ref-id=_OPENTOPIC_TOC_PROCESSING_d70e1334/ /fo:inline /fo:basic-link /fo:block /fo:block I'm viewing the PDFs in Abobe Reader, but that hasn't made a difference in the past. Any idea what's going on? Thanks for any insights. yyy -- Ron Wheeler President Artifact Software Inc email:rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: [VOTE] Add Type 1 subset support
+1 It would be desirable to add the six letter prefix to the font name so that Adobe Reader (and other viewers) flag the font as being subset. But I tested with new fonts and worked well. On 5/14/14, 10:22 AM, Robert Meyer wrote: Hi All, Following on from the last failed vote for adding Type 1 subset support, I have now put forward a modified patch and am ready to try this again. The patch went up on Monday to address the issues and comments made by Vincent and Luis. This vote will last 5 working days and will finish next Wednesday at the same time. As always if you have any concerns or find anything please let me know. If they are small I will try and address the issue before the vote is finalized in order to avoid repeating this again. Please note that all type 1 fonts will default to full embedding unless you use the embedding-mode=subset as per one of the recommendations from the last vote. Here is my vote: +1 Best Regards, Robert Meyer
