[jira] [Commented] (FOP-1969) Surrogate pairs not treated as single unicode codepoint for display purposes

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Luis Bernardo]

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

[Luis Bernardo]

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)

[Luis Bernardo]

+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

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[jira] [Commented] (FOP-2157) Deadlock in CompareUtil class

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14790578#comment-14790578
 ] 

Luis Bernardo commented on FOP-2157:


fixed in http://svn.apache.org/viewvc?view=revision&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

[jira] [Commented] (FOP-2157) Deadlock in CompareUtil class

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14790579#comment-14790579
 ] 

Luis Bernardo commented on FOP-2157:


fixed in http://svn.apache.org/viewvc?view=revision&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

[jira] [Commented] (FOP-2157) Deadlock in CompareUtil class

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 
> 

xercesImpl dependency

[Luis Bernardo]

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] [Commented] (FOP-2485) Xalan dependency should be updated

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)

[jira] [Resolved] (FOP-2489) An SVG file using markers is not rendered by FOP 2.0

[Luis Bernardo (JIRA)]

 [ 
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=revision&revision=1687506 and 
http://svn.apache.org/viewvc?view=revision&revision=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

[jira] [Resolved] (FOP-2490) Embedded SVG 1.2 not supported by FOP 2.0

[Luis Bernardo (JIRA)]

 [ 
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=revision&revision=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

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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:
>   
> page 1
> page 2
> page 3
> page 4
>   
> 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

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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:



Also, the following should not add an empty 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: 2060-empty-block-issue.xml, test.fo, test.pdf
>
>
> This causes five pages instead of four:
>   
> page 1
> page 2
> page 3
> page 4
>   
> 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

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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:
>   
> page 1
> page 2
> page 3
> page 4
>   
> The empty extra page happens between page 2 and page 3.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FOP-2477) Non uniform cell borders in complex table

[Luis Bernardo (JIRA)]

 [ 
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: FOP Committer

[Luis Bernardo]

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

Re: Q - Internal API preference? (It started with a 'simple' TODO...)

[Luis Bernardo]

In my view any code that does more becomes more complex, not less 
comprehensible. The same happens with FOP.


If you want to rewrite the layout engine and do it with less code then 
go for it. You will get a +1 from me.


On 5/26/15 8:23 PM, Andreas Delmelle wrote:

Hi FOP devs and other interested parties,

Apologies in advance for the rather long post...

Note - If code structure and style is not your thing, feel free to ignore the 
whole post, otherwise, you may just want to go get a drink and some snacks, and 
bear with me. ;)

A few weeks ago, as I started browsing the codebase to re-familiarize myself, I 
noticed a TODO in a comment in the layoutmgr.KnuthSequence class, decided to 
have a crack at resolving it, and...
Well, after spending some hours reshuffling things, I have already triggered 
and dealt with enough cascading changes that I am seriously thinking about 
committing it all to a branch.

One of the things that got me wondering is the extensive usage of the 
"standard" Java Collections API. Admitted, it's all very convenient to add new 
code for newcomers. It is relatively easy to donate patches if you are familiar with the 
basic Java API and have 'example' code blocks a few lines up or in the superclass...
On the other hand, over time, as more and more new pieces got added, and these 
patterns got basically copy-pasted all over the place, I feel this convenience 
may have actually made the code *less* comprehensible overall.

What I was thinking --and what may have prompted someone[*] else to put that 
TODO there in the first place-- is that the layout engine, internally, could be 
refactored to rely *entirely* upon KnuthSequences, in turn extracted as an 
interface.
Explicitly avoid implementing or extending the List interface there, and 
instead, just create a basic AbstractKnuthSequence implementation that serves 
as a wrapper around a java.util.List, encapsulating all the List interactions 
into proprietary methods, rather than implementing the List interface itself.

That way, the methods defined in the interface and the base class can be 
(re)designed and named such, that FOP's own code in the LayoutManagers may 
eventually become easier to read and follow (?)
If properly implemented, *any* List implementation can be passed to the 
AbstractKnuthSequence constructor, rather than always using an ArrayList, as it 
does now (which currently makes it a not-so-good idea to use KnuthSequence 
across the board).

Where we now have:

List contents = new java.util.$ListType();

This would become:

KnuthSequence contents = new $SequenceType( new java.util.$ListType() );

At the same time, that would also be virtually the only reference to the JCF, 
and the remainder of the method body would be written more in terms of the 
KnuthSequence interface. A Java 'dialect', if you will, that we then have 
complete control over.
If deemed necessary, a KnuthSequence can still provide a List view of itself, 
although I would make it read-only (i.e. Collections.unmodifiableList()). Any 
mutations (writes) would be handled via either a restricted set of API methods, 
or via an Iterator or ListIterator...

So far, the improvements in my sandbox are minimal, but definitely already 
noticeable. Changes are still very localised, though, as I have not yet gotten 
around to trying to change this in high-impact areas (like the main 
LayoutManager interface). I have, in the meantime, adapted all the inline level 
LMs to work exclusively with KnuthSequences, which seems to work pretty well.

OTOH, I have not yet fully ironed out some measures I had to put in, to ease the 
transition, like making it possible for a KnuthSequence to behave like a ListElement, 
to be able to have a generic List backing the sequence.
Not entirely sure how best to tackle that one. Current solution: extracted 
ListElement interface and implemented it in AbstractKnuthSequence. There seemed 
to be only a handful of places in the layoutmgr.inline package where a switch 
from the interface to the class was really necessary to get it all working, so 
perhaps there is a better way. The concept of nested sequence-elements just 
looked kind of cool, for now... Maybe we should keep them, just for that. ;)

Now, before I move further towards the block level LMs, I thought I'd throw it 
out there, and see what comes back.

Thoughts, anyone? Any strong preferences (for or against)? Positive/negative 
experiences with such stuff (encapsulating standard Java API calls in 
proprietary interfaces vs. just sticking to plain ol' standard Java)?

Looking forward to your feedback,

[*] I traced it back to a commit made by Adrian, but cannot be sure if he himself 
added it, or whether the comment was put there by Alexander Kiel who submitted the 
patch. http://svn.apache.org/viewvc?view=revision&revision=825646


KR[**]

Andreas

[**] BTW, Clay pointed out to me off-list that this abbreviation may not be as common as I took it 
to be. For those wondering

Re: JIRA access

[Luis Bernardo]

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

[Luis Bernardo]

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  wrote:


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

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Luis Bernardo (JIRA)]

 [ 
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

[Luis Bernardo (JIRA)]

 [ 
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

[Luis Bernardo (JIRA)]

 [ 
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

[Luis Bernardo]

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

[Luis Bernardo]

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.

http://www.w3.org/1999/XSL/Format";>

   
 
   


   
 Paragraph
 Paragraph
 Paragraph
 Paragraph
 Paragraph
 Paragraph
 Paragraph
 Paragraph
 Paragraph
 Paragraph
 Paragraph
 Paragraph
 Paragraph
 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

   





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Maven

[Luis Bernardo]

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 
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

[Luis Bernardo]

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 
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
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
mailto:simonsteiner1...@gmail.com>
>

Re: FOP Release

[Luis Bernardo]

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 
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

[Luis Bernardo (JIRA)]

 [ 
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

[Luis Bernardo]

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



  



true



  



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

[Luis Bernardo]

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

Re: [VOTE] Merge Temp_PDFLinearization to trunk

[Luis Bernardo]

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



  



true



  



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

[jira] [Resolved] (FOP-2367) [Patch] Support for color space OCA

[Luis Bernardo (JIRA)]

 [ 
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=revision&revision=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

[Luis Bernardo]

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

[Luis Bernardo]

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

[Luis Bernardo]

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

[Luis Bernardo]

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 
Bremen/Germany

[jira] [Resolved] (FOP-2440) fo:page-number display and spacing issues in Arabic

[Luis Bernardo (JIRA)]

 [ 
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] [Updated] (FOP-2440) fo:page-number display and spacing issues in Arabic

[Luis Bernardo (JIRA)]

 [ 
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-1842) integration of barcode in fop 1.0

[Luis Bernardo (JIRA)]

 [ 
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

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (FOP-2434) Varying table border thickness in PDF output

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-2330) Example shown on FOP homepage is not achievable using FOP

[Luis Bernardo (JIRA)]

 [ 
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] [Updated] (FOP-2330) Example shown on FOP homepage is not achievable using FOP

[Luis Bernardo (JIRA)]

 [ 
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-2433) Support CMYK TIFFs in AFP through IOCA FS45

[Luis Bernardo (JIRA)]

 [ 
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] [Commented] (FOP-2433) Support CMYK TIFFs in AFP through IOCA FS45

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14231571#comment-14231571
 ] 

Luis Bernardo commented on FOP-2433:


Implemented in http://svn.apache.org/viewvc?view=revision&revision=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)

[jira] [Created] (FOP-2433) Support CMYK TIFFs in AFP through IOCA FS45

[Luis Bernardo (JIRA)]

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-2330) Example shown on FOP homepage is not achievable using FOP

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14230757#comment-14230757
 ] 

Luis Bernardo commented on FOP-2330:


Revision http://svn.apache.org/viewvc?view=revision&revision=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: [VOTE] merge branches/Temp_BasicSideFloats to trunk

[Luis Bernardo]

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.

Re: RFC: basic side floats

[Luis Bernardo]

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 
wrote:

> A new example that shows floats and footnotes in the same page.
>
> On Fri, Nov 14, 2014 at 9:34 AM, Luis Bernardo 
> wrote:
>
>> A more complex example that has a float inside a list.
>>
>> On Fri, Nov 7, 2014 at 4:41 PM, Luis Bernardo 
>> 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 
>>> 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

http://www.w3.org/1999/XSL/Format";>
  

  


  


  
  


  


  

  
  

  

  

  (a)


  
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.
  

  
  

  (a)


  
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.
  

  
  

  (a)


  
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.
  

  
  

  (a)


  
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.
  

  
  

  (a)


  
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 a

Re: [VOTE] merge branches/Temp_BasicSideFloats to trunk

[Luis Bernardo]

Includes layout tests.

On 11/25/14, 5:14 PM, Glenn Adams wrote:
What are your plans for testing? I haven't looked, but does your 
branch include new unit tests for this feature?


On Tue, Nov 25, 2014 at 7:41 AM, Luis Bernardo <mailto:lmpmberna...@gmail.com>> 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.

[VOTE] merge branches/Temp_BasicSideFloats to trunk

[Luis Bernardo]

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

[Luis Bernardo]

A new example that shows floats and footnotes in the same page.

On Fri, Nov 14, 2014 at 9:34 AM, Luis Bernardo 
wrote:

> A more complex example that has a float inside a list.
>
> On Fri, Nov 7, 2014 at 4:41 PM, Luis Bernardo 
> 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 
>> 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.
>>>
>>>
>>
>

http://www.w3.org/1999/XSL/Format";>
  

  

  
  

  
Footnote in normal block before a float.
  1)
  

  1) The footnote from the normal block before the float.
  
.
  
  

  
(a)
  
  

  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)

  

  
The former dean's house at the University of Wisconsin (this is the alt text of the image in the Wikipedia page)
  

  

  Test for float and footnote inside a list. Test for float and footnote inside a list.

  


  
(b)
  
  

  Footnote in list that is being wrapped around a float.
  2)

  
2) The footnote from the list that is being wrapped around a float.

  .
  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 inside a list.

  

  
  
Footnote in normal block after the float.
  3)
  

  3) The footnote from the normal block after the float.
  
.
  
  
Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.  Some filler text.
  

  



basic-floats-and-footnotes.pdf
Description: Adobe PDF document

Re: RFC: basic side floats

[Luis Bernardo]

A more complex example that has a float inside a list.

On Fri, Nov 7, 2014 at 4:41 PM, Luis Bernardo 
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 
> 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

http://www.w3.org/1999/XSL/Format";>
  

  

  
  

  
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)
  
  
From Wikipedia's new and recently improved content:
  
  

  

  •


  
... that while testifying in a 2004 lawsuit involving the meaning of the word steakburger, a corporate CEO was grilled on the witness stand?
  

  
  

  •


  
... that the Queen Anne house (pictured) 

  

  
The former dean's house at the University of Wisconsin (this is the alt text of the image in the Wikipedia page)
  

  

at the Allen Centennial Gardens was home to four deans of the University of Wisconsin–Madison College of Agricultural and Life Sciences?
  

  
  

  •


  
... that rhapsodomancy was so vague, Virgil wrote against it in The Aeneid?
  

  
  

  •


  
... that Australian physician Claudia Burton Bradley was one of the first diabetics to be treated with insulin?
  

  
  

  •


  
... 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?
  

  
  

  •


  
... that in the Byzantine Empire, the office of orphanotrophos, head of the imperial orphanage, ranked among the higher offices of state?
  

  
  

  •


  
... that the stream Shingle Run is actually named after sawmills?
  

  

  

  

Re: xml-fop

[Luis Bernardo]

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

[Luis Bernardo]

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 > 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, 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=1637817&r1=1637816&r2=1637817&view=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 @@
 
 
 
+
+
 
 
   

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=1637817&r1=1637816&r2=1637817&view=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", null), embed,
- fontCfg.getAttribute("sub-font", null),
fontCfg.getAttributeAsBoolean(
-"kerning", true),
fontCfg.getAttributeAsBoolean("advanced", true),
- fontCfg.getAttribute("encoding-mode",
EncodingMode.AUTO.getName()),
- fontCfg.getAttribute("embedding-mode",
EncodingMode.AUTO.getName()));
+Font font = new
Font

[jira] [Updated] (FOP-2426) Apache FOP- Arabic Letters are not Joined

[Luis Bernardo (JIRA)]

 [ 
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)

[jira] [Resolved] (FOP-2426) Apache FOP- Arabic Letters are not Joined

[Luis Bernardo (JIRA)]

 [ 
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)

Re: Build failed in Jenkins: xmlgraphics-fop #47

[Luis Bernardo]

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 
>
> 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 '
> 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: 
> 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/

[jira] [Resolved] (FOP-2424) Allow for type1 afm/pfm files to be in a different path than the pfb file

[Luis Bernardo (JIRA)]

 [ 
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)

[jira] [Commented] (FOP-2424) Allow for type1 afm/pfm files to be in a different path than the pfb file

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14204663#comment-14204663
 ] 

Luis Bernardo commented on FOP-2424:


implemented in: http://svn.apache.org/viewvc?view=revision&revision=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] [Created] (FOP-2424) Allow for type1 afm/pfm files to be in a different path than the pfb file

[Luis Bernardo (JIRA)]

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)

Re: RFC: basic side floats

[Luis Bernardo]

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 
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.
>
>

http://www.w3.org/1999/XSL/Format";>
  

  

  
  

  
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)
  
  
From Wikipedia's new and recently improved content:
  
  

  

  
The former dean's house at the University of Wisconsin (this is the alt text of the image in the Wikipedia page)
  

  

  
  

  

  •


  
... 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?
  

  
  

  •


  
... that rhapsodomancy was so vague, Virgil wrote against it in The Aeneid?
  

  
  

  •


  
... that Australian physician Claudia Burton Bradley was one of the first diabetics to be treated with insulin?
  

  
  

  •


  
... 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?
  

  
  

  •


  
... that in the Byzantine Empire, the office of orphanotrophos, head of the imperial orphanage, ranked among the higher offices of state?
  

  
  

  •


  
... that the stream Shingle Run is actually named after sawmills?
  

  
  

  •


  
... that while testifying in a 2004 lawsuit involving the meaning of the word steakburger, a corporate CEO was grilled on the witness stand?
  

  

  

  





basic-floats-before-list.pdf
Description: Adobe PDF document

[jira] [Resolved] (FOP-2281) factory is not initialized when -cache is used in org.apache.fop.cli.Main

[Luis Bernardo (JIRA)]

 [ 
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=revision&revision=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

[Luis Bernardo]

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.

http://www.w3.org/1999/XSL/Format";>
  

  

  
  

  
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]
  
  
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]
  
  
Elstree Reservoir[edit]
The dam was built in 1795 by French prisoners of war.[34] English watercolour landscape p

[jira] [Resolved] (FOP-2417) Exception caused by letter space handling in Chinese sentence

[Luis Bernardo (JIRA)]

 [ 
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=revision&revision=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] [Updated] (FOP-2417) Exception caused by letter space handling in Chinese sentence

[Luis Bernardo (JIRA)]

 [ 
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] [Created] (FOP-2417) Exception caused by letter space handling in Chinese sentence

[Luis Bernardo (JIRA)]

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] [Resolved] (FOP-2060) adjoining blocks with break-before="page" break-after="page" cause extra empty page

[Luis Bernardo (JIRA)]

 [ 
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=revision&revision=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:
>   
> page 1
> page 2
> page 3
> page 4
>   
> 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?

[Luis Bernardo]

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  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 
> 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 
>> 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  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

[Luis Bernardo (JIRA)]

 [ 
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=revision&revision=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.inv

Re: nightly snapshots page broken?

[Luis Bernardo]

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 <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 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?

[Luis Bernardo]

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 <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 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

[Luis Bernardo]

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?

[Luis Bernardo]

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  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

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14117520#comment-14117520
 ] 

Luis Bernardo commented on FOP-2408:


Confirmed. Replacing  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

[Luis Bernardo]

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 
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
> >  > > 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
> > .
> >
> > 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
> >
> e-commons/exec/target/commons-exec-1.3-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-20140815.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-20140815.jar:/srv/gump/public/workspace/apache-commons/validator/dist/commons-validator-20140815.jar:/srv/gump/public/workspace/google-guava/guava/target/guava-19.0-SNAPSHOT.j

Re: Table Border Anti Aliasing Issue

[Luis Bernardo]

I wouldn't say there is a recommended way but the way I do it is by 
running FOP in embedded mode (I used the servlet example as basis to 
build a test class) in a loop and by connecting visualvm to the running 
java process. Let it run for a while to get to a steady state and use 
the visualvm graphical report to compare the performance measurements 
with and without the code changes.


On 8/6/14, 3:24 PM, Matthias Reischenbacher wrote:
Thanks for all your suggestions, this is very helpful. I like the 
simplicity of your approach Luis, but I'll try to handle it in the LMs 
so that PostScripts benefits too and we have a greater control over 
which shapes get merged.

I'll report in the next view days as soon as I can start with this job.

One more thing: Is there a recommended way to evaluate the performance 
impact of my changes? I searched in the mailing lists and found only 
Jeremia's "FOP Benchmarks" ( 
http://www.jeremias-maerki.ch/download/fop/FOP%20Benchmarks.zip ). 
I'll give it a try, please let me know, if there is some other way.


Thanks,
Matthias

[jira] [Reopened] (FOP-2403) FOP 1.1 throws a Null pointer exception when FOP 1.0 does not

[Luis Bernardo (JIRA)]

 [ 
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)

[jira] [Commented] (FOP-2403) FOP 1.1 throws a Null pointer exception when FOP 1.0 does not

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)

Re: Table Border Anti Aliasing Issue

[Luis Bernardo]

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: Summary of findbugs exclusions

[Luis Bernardo]

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.

Re: Table Border Anti Aliasing Issue

[Luis Bernardo]

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

[jira] [Commented] (FOP-2107) org.apache.batik.bridge.BridgeException: Unable to make sense of URL for connection

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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=revision&revision=1613810 and 
http://svn.apache.org/viewvc?view=revision&revision=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] [Resolved] (FOP-2307) [PATCH] Weird border color inheritance (hashCode collisions)

[Luis Bernardo (JIRA)]

 [ 
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=revision&revision=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] [Resolved] (FOP-2307) Weird border color inheritance (hashCode collisions)

[Luis Bernardo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FOP-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luis Bernardo resolved FOP-2307.


   Resolution: Fixed
Fix Version/s: trunk

Fixed in http://svn.apache.org/viewvc?view=revision&revision=1612819 and 
http://svn.apache.org/viewvc?view=revision&revision=1612817.

> 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
>
>
> 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-2396) font tag attribute embed-url is expecting absoulte-URL

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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:
>  
> 
> 
>  
> 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] [Resolved] (FOP-2398) [AFP] Image written as having 72 DPI instead of its intrinstic resolution

[Luis Bernardo (JIRA)]

 [ 
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-2398) [AFP] Image written as having 72 DPI instead of its intrinstic resolution

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070260#comment-14070260
 ] 

Luis Bernardo commented on FOP-2398:


Fixed in http://svn.apache.org/viewvc?view=revision&revision=1612567 and 
http://svn.apache.org/viewvc?view=revision&revision=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] [Commented] (FOP-2398) [AFP] Image written as having 72 DPI instead of its intrinstic resolution

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070179#comment-14070179
 ] 

Luis Bernardo commented on FOP-2398:


I need to check the image but the intrinsic resolution can be set in the (old) 
APP0 segment or in the (newer) APP1 (EXIF) segment. The code was ignoring the 
APP1 segment which was causing problems with newer images that do not have the 
APP0 segment. The current code can handle both APP0 and APP1 and the first 
found is the one used. Now, images can have both segments, and can have 
different intrinsic resolutions in the different segments. If your image has 
APP1 before APP0 and the intrinsic resolution there is 72 that would explain 
the issue you see.

> [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-2307) Weird border color inheritance (hashCode collisions)

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070170#comment-14070170
 ] 

Luis Bernardo commented on FOP-2307:


The original issue does not happen in current trunk due to changes to 
CommonBorderPaddingBackground.equals(), which now, incorrectly, compares two 
colors by comparing that they are the same instance. This effectively disables 
caching since a cached color property will be replaced by a new instance of the 
same color (whether that has practical performance implications is another 
question...).

> 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-2396) font tag attribute embed-url is expecting absoulte-URL

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14069971#comment-14069971
 ] 

Luis Bernardo commented on FOP-2396:


please check your font base entry in the configuration file since this is most 
likely a misconfiguration issue than a bug. nowhere in the message above says 
that it expects an absolute URL even though it may (and should) work if you 
provide one. if that doesn't fix the problem please provide the configuration 
file.

> 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:
>  
> 
> 
>  
> 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)

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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=revision&revision=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] [Resolved] (FOP-2395) PDF encryption does not work when PDF version is set in FOP config

[Luis Bernardo (JIRA)]

 [ 
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=revision&revision=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] [Commented] (FOP-2395) PDF encryption does not work when PDF version is set in FOP config

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-2352) Unable to render Arabic Text using Apache FOP

[Luis Bernardo (JIRA)]

 [ 
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)

[jira] [Commented] (FOP-2352) Unable to render Arabic Text using Apache FOP

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Updated] (FOP-2352) Unable to render Arabic Text using Apache FOP

[Luis Bernardo (JIRA)]

 [ 
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)