Re: [jira] [Resolved] (FOP-3016) Thai diacritical mark in wrong location

[Matthias Reischenbacher]

Hi Simon,

does this mean, that FOP has support for Thai again (which would be
great!)? Or are there other issues, that still need to be fixed?

Best regards,
Matthias

On 26/06/2021 08:02, Simon Steiner (Jira) wrote:

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

Simon Steiner resolved FOP-3016.

 Resolution: Fixed

http://svn.apache.org/viewvc?view=revision=1891050


Thai diacritical mark in wrong location
---

 Key: FOP-3016
 URL: https://issues.apache.org/jira/browse/FOP-3016
 Project: FOP
  Issue Type: Bug
Reporter: Simon Steiner
Assignee: Simon Steiner
Priority: Major
 Attachments: myfop.xconf, simple.fo


fop simple.fo -c myfop.xconf out.pdf

First mark should be above first letter



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (FOP-2536) [PATCH] Varying table border thickness in PDF output

[Matthias Reischenbacher (Jira)]

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

Matthias Reischenbacher commented on FOP-2536:
--

Thanks [~ssteiner]!

> [PATCH] Varying table border thickness in PDF output
> 
>
> Key: FOP-2536
> URL: https://issues.apache.org/jira/browse/FOP-2536
> Project: FOP
>  Issue Type: Improvement
>  Components: renderer/pdf
>Reporter: Martin Leitner
>Assignee: Simon Steiner
>Priority: Major
> Fix For: trunk
>
> Attachments: Polygon.java, extended-patch-FOP-2536-new.patch, 
> extended-patch-FOP-2536.patch, fop-2434-alternative.patch, 
> patch-FOP-2434.diff, table-border-overpaint.pdf, table-border-standard.pdf, 
> table-border.fo, tableBorders.fo, tableBorders_fop_2.0.pdf, 
> tableBorders_fop_2.1.pdf, tableBorders_fop_2.1_AdobeReader_11.png, 
> tableBorders_patched.pdf
>
>
> As already pointed out in a comment to the original issue, this is a problem 
> with the PDF viewers. FOP generates the borders correctly. The viewers render 
> border segments correctly when they are rectangles, but they make mistakes 
> when the segments are more general polygons. In my patch, I am splitting the 
> polygons into rectangles, covering as much of the polygon as possible, write 
> the rectangles to the PDF, then write the remaining triangles.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE] Release XML Graphics FOP PDF Images 2.4

[Matthias Reischenbacher]

+1.

Thanks, Simon!

> Hi,
>
> This is a vote to release XML Graphics FOP PDF Images 2.4.
>
> Artifacts can be found there:
> https://people.apache.org/~ssteiner/fop-pdf-images-2.4/
>
> The release is signed with the key:
> https://people.apache.org/~ssteiner/KEYS
>
> The vote will end on 1/11/2019
>
> +1 from me.
>
> Thanks
> > >
- >
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org > For
additional commands, e-mail: general-h...@xmlgraphics.apache.org >

Re: [VOTE] Release XML Graphics FOP 2.4

[Matthias Reischenbacher]

+1.

Thanks, Simon!

> Hi,
>
> This is a vote to release XML Graphics FOP 2.4.
>
> Artifacts can be found there:
> http://people.apache.org/~ssteiner/fop-2.4/
>
> The release is signed with the key:
> https://people.apache.org/~ssteiner/KEYS
>
> The vote will end on 1/11/2019
>
> +1 from me.
>
> Thanks
> > >
- >
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org > For
additional commands, e-mail: general-h...@xmlgraphics.apache.org >

[jira] [Assigned] (FOP-2845) File leak to background-image

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher reassigned FOP-2845:


Assignee: Matthias Reischenbacher

> File leak to background-image
> -
>
> Key: FOP-2845
> URL: https://issues.apache.org/jira/browse/FOP-2845
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Björn Kautler
>    Assignee: Matthias Reischenbacher
>Priority: Major
>
> I use FOP from within my Gradle build to produce documentation PDFs.
> So the VM usually is not closed, but the Gradle Daemon that executes the 
> build stays alive.
> I built some PDF and then tried to delete the folder as it was just a test, 
> but one file was still locked by the Gradle process, so FOP seems to leak 
> that file resource.
> It was the {{draft.png}} that is set as {{background-image}} in this snippet.
> Also interesting, this page master was not even used, so it is even more 
> suspicious why the file was opened for reading at all, but that it stays 
> locked is pretty unnice.
> {code:xml}
>  margin-bottom="0cm" margin-top="0cm" page-height="297mm" page-width="210mm" 
> master-name="my-titlepage-first-draft">
>        column-gap="12pt"
>    margin-top="0cm"
>    margin-bottom="0cm"
>    
> background-image="url(../../common/images/decorative/draft.png)"
>    background-attachment="fixed"
>    background-repeat="no-repeat"
>    background-position-horizontal="center"
>    background-position-vertical="center"/>
>     region-name="xsl-region-before-first"/>
>     region-name="xsl-region-after-first"/>
> 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Resolved] (FOP-2855) [PATCH] When using letter-spacing and white-space=pre inline elements after multiple spaces are sligthly moved to the right

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher resolved FOP-2855.
--
Resolution: Fixed

Thanks, [~juani15151]! Committed in 
http://svn.apache.org/viewvc?view=revision=1863872.

> [PATCH] When using letter-spacing and white-space=pre inline elements after 
> multiple spaces are sligthly moved to the right
> ---
>
> Key: FOP-2855
> URL: https://issues.apache.org/jira/browse/FOP-2855
> Project: FOP
>  Issue Type: Bug
>  Components: layout/inline
>Affects Versions: trunk
>Reporter: Juan
>    Assignee: Matthias Reischenbacher
>Priority: Trivial
> Attachments: issue.png, issue.xml, issue_after_fix1.png, 
> issue_fix.patch, issue_fix_2.patch, issue_fixed.png
>
>
> Inline elements inside code elements, that use white-space=pre and 
> letter-spacing > 0 (e.g. 1pt) are slightly moved to the right.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Resolved] (FOP-2875) [PATCH] basic-link to a file or an embedded file breaks if filename contains a parenthesis

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher resolved FOP-2875.
--
Resolution: Fixed

Thanks for your patch, [~esclim]! I combined it with a fix for attachment name 
collisions. When using two attachment with similar names, that contain 
non-ascii chars e.g. täst, töst, only one of the attachments was added to the 
PDF file.

http://svn.apache.org/viewvc?view=revision=1863870

> [PATCH]  basic-link to a file or an embedded file breaks if filename contains 
> a parenthesis
> ---
>
> Key: FOP-2875
> URL: https://issues.apache.org/jira/browse/FOP-2875
> Project: FOP
>  Issue Type: Bug
>  Components: renderer/pdf
>Reporter: Eric Lim
>Assignee: Matthias Reischenbacher
>Priority: Minor
> Attachments: paren3.patch, test-case.fo
>
>
> The following FO snippet
> {code:java}
> The link 
> to some file{code}
> produces the following PDF snippet
> {code:java}
> <<
> /S /JavaScript
> /JS (this.exportDataObject({cName:"some(paren.pdf", nLaunch:2});)
> >>{code}
> This PDF action is broken because the parenthesis are not escaped.
> The correct output should be
> {code:java}
> <<
> /S /JavaScript
> /JS (this.exportDataObject\({cName:"some\(paren.pdf", nLaunch:2}\);)
> >>{code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Resolved] (FOP-2743) [PATCH] fo:basic-link external-destinations fails when target URIs contains unbalanced parenthesis

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher resolved FOP-2743.
--
Resolution: Fixed

Fixed as part of FOP-2875.

> [PATCH] fo:basic-link external-destinations fails when target URIs contains 
> unbalanced parenthesis
> --
>
> Key: FOP-2743
> URL: https://issues.apache.org/jira/browse/FOP-2743
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Eric Lim
>Assignee: Matthias Reischenbacher
>Priority: Major
> Attachments: FOP-2688-unbalanced-paren.fo, FOP-2743.patch, 
> simple_[report]_(version2.pdf
>
>
> 7 0 obj
> << /URI (simple_%5Breport%5D_(version2.pdf)
> /S /URI >>
> endobj
> It should be,
> 7 0 obj
> << /URI (simple_%5Breport%5D_(version2.pdf)
> /S /URI >>
> endobj



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Assigned] (FOP-2743) [PATCH] fo:basic-link external-destinations fails when target URIs contains unbalanced parenthesis

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher reassigned FOP-2743:


Assignee: Matthias Reischenbacher

> [PATCH] fo:basic-link external-destinations fails when target URIs contains 
> unbalanced parenthesis
> --
>
> Key: FOP-2743
> URL: https://issues.apache.org/jira/browse/FOP-2743
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Eric Lim
>Assignee: Matthias Reischenbacher
>Priority: Major
> Attachments: FOP-2688-unbalanced-paren.fo, FOP-2743.patch, 
> simple_[report]_(version2.pdf
>
>
> 7 0 obj
> << /URI (simple_%5Breport%5D_(version2.pdf)
> /S /URI >>
> endobj
> It should be,
> 7 0 obj
> << /URI (simple_%5Breport%5D_(version2.pdf)
> /S /URI >>
> endobj



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Assigned] (FOP-2875) [PATCH] basic-link to a file or an embedded file breaks if filename contains a parenthesis

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher reassigned FOP-2875:


Assignee: Matthias Reischenbacher

> [PATCH]  basic-link to a file or an embedded file breaks if filename contains 
> a parenthesis
> ---
>
> Key: FOP-2875
> URL: https://issues.apache.org/jira/browse/FOP-2875
> Project: FOP
>  Issue Type: Bug
>  Components: renderer/pdf
>Reporter: Eric Lim
>Assignee: Matthias Reischenbacher
>Priority: Minor
> Attachments: paren3.patch, test-case.fo
>
>
> The following FO snippet
> {code:java}
> The link 
> to some file{code}
> produces the following PDF snippet
> {code:java}
> <<
> /S /JavaScript
> /JS (this.exportDataObject({cName:"some(paren.pdf", nLaunch:2});)
> >>{code}
> This PDF action is broken because the parenthesis are not escaped.
> The correct output should be
> {code:java}
> <<
> /S /JavaScript
> /JS (this.exportDataObject\({cName:"some\(paren.pdf", nLaunch:2}\);)
> >>{code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (FOP-2855) [PATCH] When using letter-spacing and white-space=pre inline elements after multiple spaces are sligthly moved to the right

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2855:
--

[~juani15151]: please sign a CLA, so that I can process your patch. See: 
http://www.apache.org/licenses/#clas

> [PATCH] When using letter-spacing and white-space=pre inline elements after 
> multiple spaces are sligthly moved to the right
> ---
>
> Key: FOP-2855
> URL: https://issues.apache.org/jira/browse/FOP-2855
> Project: FOP
>  Issue Type: Bug
>  Components: layout/inline
>Affects Versions: trunk
>Reporter: Juan
>    Assignee: Matthias Reischenbacher
>Priority: Trivial
> Attachments: issue.png, issue.xml, issue_fix.patch, issue_fixed.png
>
>
> Inline elements inside code elements, that use white-space=pre and 
> letter-spacing > 0 (e.g. 1pt) are slightly moved to the right.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (FOP-2855) [PATCH] When using letter-spacing and white-space=pre inline elements after multiple spaces are sligthly moved to the right

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher reassigned FOP-2855:


Assignee: Matthias Reischenbacher

> [PATCH] When using letter-spacing and white-space=pre inline elements after 
> multiple spaces are sligthly moved to the right
> ---
>
> Key: FOP-2855
> URL: https://issues.apache.org/jira/browse/FOP-2855
> Project: FOP
>  Issue Type: Bug
>  Components: layout/inline
>Affects Versions: trunk
>Reporter: Juan
>    Assignee: Matthias Reischenbacher
>Priority: Trivial
> Attachments: issue.png, issue.xml, issue_fix.patch, issue_fixed.png
>
>
> Inline elements inside code elements, that use white-space=pre and 
> letter-spacing > 0 (e.g. 1pt) are slightly moved to the right.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FOP-2855) [PATCH] When using letter-spacing and white-space=pre inline elements after multiple spaces are sligthly moved to the right

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2855:
-
Summary: [PATCH] When using letter-spacing and white-space=pre inline 
elements after multiple spaces are sligthly moved to the right  (was: When 
using letter-spacing and white-space=pre inline elements after multiple spaces 
are sligthly moved to the right)

> [PATCH] When using letter-spacing and white-space=pre inline elements after 
> multiple spaces are sligthly moved to the right
> ---
>
> Key: FOP-2855
> URL: https://issues.apache.org/jira/browse/FOP-2855
> Project: FOP
>  Issue Type: Bug
>  Components: layout/inline
>Affects Versions: trunk
>Reporter: Juan
>Priority: Trivial
> Attachments: issue.png, issue.xml, issue_fix.patch, issue_fixed.png
>
>
> Inline elements inside code elements, that use white-space=pre and 
> letter-spacing > 0 (e.g. 1pt) are slightly moved to the right.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FOP-2852) relative-align on list-item is ignored

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2852:
--

First you transform to the intermediate tree XML format, here a code sample:
{code:java}
//Create a user agent
FOUserAgent userAgent = this.fopFactory.newFOUserAgent();

this.configureUserAgent(userAgent, targetResolution);

//Create an instance of the target document handler so the IFSerializer
//can use its font setup
String mime = mimeOutput == null ? MimeConstants.MIME_PDF : mimeOutput;

//Create an instance of the target renderer so the XMLRenderer can use its font 
setup
Renderer targetRenderer = userAgent.getRendererFactory().createRenderer(
        userAgent, mime);

//Create the XMLRenderer to create the area tree XML
XMLRenderer xmlRenderer = new XMLRenderer(userAgent);

//Tell the XMLRenderer to mimic the target renderer
xmlRenderer.mimicRenderer(targetRenderer);

//Make sure the prepared XMLRenderer is used
userAgent.setRendererOverride(xmlRenderer);

File tempFile;
// Setup output
OutputStream out;
try
{
    tempFile = File.createTempFile("fop-if", ".xml");
    out = new FileOutputStream(tempFile);
}
catch (IOException e)
{
    throw new RuntimeException(e);
}

out = new BufferedOutputStream(out);
Source src = new DOMSource(xslFoDoc);
try {
    Fop fop = this.fopFactory.newFop(null, userAgent, out);

    // Setup XSLT
    TransformerFactory factory = TransformerFactory.newInstance();
    Transformer transformer = factory.newTransformer();

    // Resulting SAX events (the generated FO) must be piped through to FOP
    Result res = new SAXResult(fop.getDefaultHandler());


    // Start XSLT transformation and FOP processing
    transformer.transform(src, res);
} finally {
    IOUtils.closeQuietly(out);
}
{code}
Then you modify the generated XML, e.g. by applying a XSL transform (make sure, 
to give the list-item-label elements in your FO markup an "id", that matches 
the XPath expression in the template):
{code:java}

    
        
        
        

        
        
        
            
        
        
            
        
        
    

{code}
And then you convert the transformed intermediate XML format to PDF:
{code:java}
//Create a user agent
FOUserAgent userAgent = this.fopFactory.newFOUserAgent();

this.configureUserAgent(userAgent, targetResolution);

//Setup target handler
String mime = mimeOutput == null ? MimeConstants.MIME_PDF : mimeOutput;

try {
    //Setup fonts and user agent
    FontInfo fontInfo = new FontInfo();

    //Construct the AreaTreeModel that will received the individual pages
    AreaTreeModel treeModel = new RenderPagesModel(userAgent,
                                                   mime, fontInfo, out);

    //Iterate over all area tree files
    AreaTreeParser parser = new AreaTreeParser();

    Source src = new DOMSource(xslFoDoc);
    parser.parse(src, treeModel, userAgent);

    //Signal the end of the processing. The renderer can finalize the target 
document.
    treeModel.endDocument();
}
catch (SAXException e)
{
    throw new FOPException(e);
} finally {
    IOUtils.closeQuietly(out);
}
{code}
As I said, all a bit hacky, but it works :).

> relative-align on list-item is ignored
> --
>
> Key: FOP-2852
> URL: https://issues.apache.org/jira/browse/FOP-2852
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Björn Kautler
>Priority: Major
> Attachments: image-2019-03-18-15-51-15-406.png
>
>
> When you have a list-item where in the first line is an inline image, the 
> enumeration is too high as it is top-aligned like this:
> !image-2019-03-18-15-51-15-406.png!
> As far as I have seen this is ok as default behavior.
> But if the `list-item` has the attribute `relative-align` set to `baseline` 
> it should align to the baseline as far as I understood, but it seems Fop 
> totally ignores this.
> The screenshot is made with the attribute set.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FOP-2852) relative-align on list-item is ignored

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2852:
--

Yes, unfortunately relative-align=baseline is not implemented. There are is a 
workaround by modifying the intermediate tree XML format, but this is a bit 
hacky.

> relative-align on list-item is ignored
> --
>
> Key: FOP-2852
> URL: https://issues.apache.org/jira/browse/FOP-2852
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Björn Kautler
>Priority: Major
> Attachments: image-2019-03-18-15-51-15-406.png
>
>
> When you have a list-item where in the first line is an inline image, the 
> enumeration is too high as it is top-aligned like this:
> !image-2019-03-18-15-51-15-406.png!
> As far as I have seen this is ok as default behavior.
> But if the `list-item` has the attribute `relative-align` set to `baseline` 
> it should align to the baseline as far as I understood, but it seems Fop 
> totally ignores this.
> The screenshot is made with the attribute set.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Merge Temp_Avalon to trunk

[Matthias Reischenbacher]

+1

On 15.01.2019 07:48, Simon Steiner wrote:
> Hi,
>
> Chris West and Thomas Pasch submitted a patch to remove Avalon, since this
> dependency is no longer maintained and doesn't compile under Java 9.
> The vote will last 5 working days, ending next Tuesday. 
>
> https://issues.apache.org/jira/browse/FOP-2733
> http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_Avalon/
>
> Here is my vote: +1
>
> Thanks
>
>
>

[jira] [Commented] (FOP-2704) Google fonts Roboto font (updated 2017) UnsupportedOperationException: coverage set class table not yet supported

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2704:
--

Just to clarify: The  configuration or -nocs command line 
option will work, if the fonts are declared in the FOP configuration file. When 
using the font auto detection the Roboto font will not work, because the 
"advanced" font features are turned on by default (see FontInfoFinder.find() 
method and the hardcoded "boolean useAdvanced = true;" variable). We will have 
to change that eventually, because the user agent setting is completely ignored 
here.
{quote}This is a workaround disables too many font features. What would mean to 
support the "coverage set class table" ?
{quote}
Good question, hopefully some of the font experts can answer that. :)

> Google fonts Roboto font (updated 2017) UnsupportedOperationException: 
> coverage set class table not yet supported
> -
>
> Key: FOP-2704
> URL: https://issues.apache.org/jira/browse/FOP-2704
> Project: FOP
>  Issue Type: Bug
>  Components: font/opentype
>Affects Versions: 2.1, 2.2
>Reporter: Dan Caprioara
>Priority: Major
> Attachments: Roboto-Regular.ttf, Roboto-Thin.ttf
>
>
> Steps:
> # Download the Roboto TTF font from Google Fonts. 
> # Create a configuration file with a triplet pointing to the "roboto-regular" 
> or "roboto-thin" TTF file.
> You get:
> {code}
> java.lang.UnsupportedOperationException: coverage set class table not yet 
> supported
>   at 
> org.apache.fop.complexscripts.fonts.GlyphClassTable$CoverageSetClassTable.(GlyphClassTable.java:262)
>   at 
> org.apache.fop.complexscripts.fonts.GlyphClassTable.createClassTable(GlyphClassTable.java:88)
>   at 
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader_Original.readGDEFMarkGlyphsTableFormat1(OTFAdvancedTypographicTableReader_Original.java:3344)
>   at 
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readGDEFMarkGlyphsTableFormat1(OTFAdvancedTypographicTableReader.java:69)
>   at 
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader_Original.readGDEFMarkGlyphsTable(OTFAdvancedTypographicTableReader_Original.java:3357)
>   at 
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader_Original.readGDEF(OTFAdvancedTypographicTableReader_Original.java:3427)
>   at 
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader_Original.readAll(OTFAdvancedTypographicTableReader_Original.java:80)
>   at 
> org.apache.fop.fonts.truetype.OpenFont.handleCharacterSpacing(OpenFont.java:786)
>   at org.apache.fop.fonts.truetype.OpenFont.readFont(OpenFont.java:755)
>   at 
> org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:109)
>   at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:93)
> {code}
> There are two changes that should be done to the 
> {{OTFAdvancedTypographicTableReader}}.
> # The method {{readGDEFMarkGlyphsTableFormat1}} should catch this exception
> # The method {{constructLookupsLanguage}} should check if the {{languages}} 
> parameter is null.
> After these changes, the PDF is produced and it looks good. I am not sure 
> what are the side effects on the font that is embedded into the PDF..



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[Matthias Reischenbacher]

Hi team,

is the "Return code is: 401, ReasonPhrase: Unauthorized." error related
to the fact, that I'm committing and missing some access rights? Or is
this just a temporary repository server issue?

Best regards,

Matthias


On 10.10.2018 17:43, Apache Jenkins Server wrote:
> See 
> 
>
> Changes:
>
> [matthias] FOP-2818: fix failing test
>
> --
> [...truncated 112.41 KB...]
> Downloading: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/xmlgraphics/batik-ttf2svg/1.11.0-SNAPSHOT/maven-metadata.xml
> Downloading: 
> https://repository.jboss.org/nexus/content/repositories/thirdparty-releases/org/apache/xmlgraphics/batik-ttf2svg/1.11.0-SNAPSHOT/maven-metadata.xml
> [WARNING] Could not transfer metadata 
> org.apache.xmlgraphics:batik-ttf2svg:1.11.0-SNAPSHOT/maven-metadata.xml 
> from/to apache.snapshots.https 
> (https://repository.apache.org/content/repositories/snapshots): Not 
> authorized, ReasonPhrase:Unauthorized.
> [INFO] 
> [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ fop-servlet ---
> [INFO] Deleting 
> 
> [INFO] 
> [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
> fop-servlet ---
> [debug] execute contextualize
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory 
> 
> [INFO] 
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ fop-servlet 
> ---
> [INFO] No sources to compile
> [INFO] 
> [INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
> fop-servlet ---
> [debug] execute contextualize
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory 
> 
> [INFO] 
> [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ 
> fop-servlet ---
> [INFO] No sources to compile
> [INFO] 
> [INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ fop-servlet ---
> [INFO] No tests to run.
> [JENKINS] Recording test results
> [INFO] 
> [INFO] --- maven-war-plugin:2.2:war (default-war) @ fop-servlet ---
> [INFO] Packaging webapp
> [INFO] Assembling webapp [fop-servlet] in 
> [
> [INFO] Processing war project
> [INFO] Copying webapp resources 
> [
> [INFO] Webapp assembled in [97 msecs]
> [INFO] Building war: 
> 
> [INFO] 
> [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ fop-servlet 
> ---
> [INFO] Installing 
> 
>  to 
> /home/jenkins/jenkins-slave/maven-repositories/0/org/apache/xmlgraphics/fop-servlet/2.4.0-SNAPSHOT/fop-servlet-2.4.0-SNAPSHOT.war
> [INFO] Installing 
>  to 
> /home/jenkins/jenkins-slave/maven-repositories/0/org/apache/xmlgraphics/fop-servlet/2.4.0-SNAPSHOT/fop-servlet-2.4.0-SNAPSHOT.pom
> [INFO] 
> [INFO] --- maven-checkstyle-plugin:2.14:checkstyle (default-cli) @ 
> fop-servlet ---
> [CHECKSTYLE] No report found for mojo checkstyle[INFO] 
>
> [INFO] --- findbugs-maven-plugin:3.0.5:findbugs (default-cli) @ fop-servlet 
> ---
> [FINDBUGS] No report found for mojo findbugs
> [INFO]
>  
> [INFO] 
> 
> [INFO] Building Apache FOP Transcoder 2.4.0-SNAPSHOT
> [INFO] 
> 
> [INFO] 
> [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ fop-transcoder ---
> [INFO] Deleting 
> 
> [INFO] 
> [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
> fop-transcoder ---
> [debug] execute contextualize
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory 
> 
> [INFO] 
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ 
> fop-transcoder ---
> [INFO] No sources to compile
> [INFO] 
> [INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
> fop-transcoder ---
> [debug] execute contextualize
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory 
> 

[jira] [Resolved] (FOP-2818) PDF color spaces are lost when embedding PDF image

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher resolved FOP-2818.
--
Resolution: Fixed

Added a junit test and fixed an additional bug with missing patterns and 
shadings as part of:

http://svn.apache.org/viewvc?view=revision=1843494

> PDF color spaces are lost when embedding PDF image
> --
>
> Key: FOP-2818
> URL: https://issues.apache.org/jira/browse/FOP-2818
> Project: FOP
>  Issue Type: Bug
>  Components: renderer/pdf
>    Reporter: Matthias Reischenbacher
>Priority: Critical
> Attachments: image.pdf, kun_muutat_suomeenEN.pdf.pdf, 
> output_broken.pdf, output_fixed.pdf, test.fo, test_case.xml
>
>
> When embedding a PDF image (via the fop pdf image plugin) into a page, that 
> also contains a color definition with a custom color space (e.g. a Pantone 
> full tone color), the color space definition is lost and the PDF can't be 
> displayed correctly.
> After analyzing the generated PDF file I detected, that the "ColorSpace" 
> entry for the Pantone color space was missing in the "Resources" dictionary. 
> This bug was caused by FOP-2337, that introduced a "parent" resource 
> directory. I adapted the populateDictionary method of the PDFResources class, 
> so that the color space entries of the "parent" dictionary are not lost. 
> @ssteiner: please check, if this is correct.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Reopened] (FOP-2818) PDF color spaces are lost when embedding PDF image

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher reopened FOP-2818:
--

Ok, I will. I have detected today additional issues with shadings and patterns 
and I will fix that too.

> PDF color spaces are lost when embedding PDF image
> --
>
> Key: FOP-2818
> URL: https://issues.apache.org/jira/browse/FOP-2818
> Project: FOP
>  Issue Type: Bug
>  Components: renderer/pdf
>    Reporter: Matthias Reischenbacher
>Priority: Critical
> Attachments: image.pdf, kun_muutat_suomeenEN.pdf.pdf, 
> output_broken.pdf, output_fixed.pdf, test.fo, test_case.xml
>
>
> When embedding a PDF image (via the fop pdf image plugin) into a page, that 
> also contains a color definition with a custom color space (e.g. a Pantone 
> full tone color), the color space definition is lost and the PDF can't be 
> displayed correctly.
> After analyzing the generated PDF file I detected, that the "ColorSpace" 
> entry for the Pantone color space was missing in the "Resources" dictionary. 
> This bug was caused by FOP-2337, that introduced a "parent" resource 
> directory. I adapted the populateDictionary method of the PDFResources class, 
> so that the color space entries of the "parent" dictionary are not lost. 
> @ssteiner: please check, if this is correct.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FOP-2818) PDF color spaces are lost when embedding PDF image

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher resolved FOP-2818.
--
Resolution: Fixed

> PDF color spaces are lost when embedding PDF image
> --
>
> Key: FOP-2818
> URL: https://issues.apache.org/jira/browse/FOP-2818
> Project: FOP
>  Issue Type: Bug
>  Components: renderer/pdf
>    Reporter: Matthias Reischenbacher
>Priority: Critical
> Attachments: image.pdf, kun_muutat_suomeenEN.pdf.pdf, 
> output_broken.pdf, output_fixed.pdf, test.fo, test_case.xml
>
>
> When embedding a PDF image (via the fop pdf image plugin) into a page, that 
> also contains a color definition with a custom color space (e.g. a Pantone 
> full tone color), the color space definition is lost and the PDF can't be 
> displayed correctly.
> After analyzing the generated PDF file I detected, that the "ColorSpace" 
> entry for the Pantone color space was missing in the "Resources" dictionary. 
> This bug was caused by FOP-2337, that introduced a "parent" resource 
> directory. I adapted the populateDictionary method of the PDFResources class, 
> so that the color space entries of the "parent" dictionary are not lost. 
> @ssteiner: please check, if this is correct.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FOP-2818) PDF color spaces are lost when embedding PDF image

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2818:
--

Fixed as part of http://svn.apache.org/viewvc?view=revision=1843302

> PDF color spaces are lost when embedding PDF image
> --
>
> Key: FOP-2818
> URL: https://issues.apache.org/jira/browse/FOP-2818
> Project: FOP
>  Issue Type: Bug
>  Components: renderer/pdf
>    Reporter: Matthias Reischenbacher
>Priority: Critical
> Attachments: image.pdf, kun_muutat_suomeenEN.pdf.pdf, 
> output_broken.pdf, output_fixed.pdf, test.fo, test_case.xml
>
>
> When embedding a PDF image (via the fop pdf image plugin) into a page, that 
> also contains a color definition with a custom color space (e.g. a Pantone 
> full tone color), the color space definition is lost and the PDF can't be 
> displayed correctly.
> After analyzing the generated PDF file I detected, that the "ColorSpace" 
> entry for the Pantone color space was missing in the "Resources" dictionary. 
> This bug was caused by FOP-2337, that introduced a "parent" resource 
> directory. I adapted the populateDictionary method of the PDFResources class, 
> so that the color space entries of the "parent" dictionary are not lost. 
> @ssteiner: please check, if this is correct.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FOP-2818) PDF color spaces are lost when embedding PDF image

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2818:
-
Attachment: output_fixed.pdf

> PDF color spaces are lost when embedding PDF image
> --
>
> Key: FOP-2818
> URL: https://issues.apache.org/jira/browse/FOP-2818
> Project: FOP
>  Issue Type: Bug
>  Components: renderer/pdf
>    Reporter: Matthias Reischenbacher
>    Assignee: Matthias Reischenbacher
>Priority: Critical
> Attachments: image.pdf, output_broken.pdf, output_fixed.pdf, 
> test_case.xml
>
>
> When embedding a PDF image (via the fop pdf image plugin) into a page, that 
> also contains a color definition with a custom color space (e.g. a Pantone 
> full tone color), the color space definition is lost and the PDF can't be 
> displayed correctly.
> After analyzing the generated PDF file I detected, that the "ColorSpace" 
> entry for the Pantone color space was missing in the "Resources" dictionary. 
> This bug was caused by FOP-2337, that introduced a "parent" resource 
> directory. I adapted the populateDictionary method of the PDFResources class, 
> so that the color space entries of the "parent" dictionary are not lost. 
> @ssteiner: please check, if this is correct.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FOP-2818) PDF color spaces are lost when embedding PDF image

[Matthias Reischenbacher (JIRA)]

Matthias Reischenbacher created FOP-2818:


 Summary: PDF color spaces are lost when embedding PDF image
 Key: FOP-2818
 URL: https://issues.apache.org/jira/browse/FOP-2818
 Project: FOP
  Issue Type: Bug
  Components: renderer/pdf
Reporter: Matthias Reischenbacher
Assignee: Matthias Reischenbacher


When embedding a PDF image (via the fop pdf image plugin) into a page, that 
also contains a color definition with a custom color space (e.g. a Pantone full 
tone color), the color space definition is lost and the PDF can't be displayed 
correctly.

After analyzing the generated PDF file I detected, that the "ColorSpace" entry 
for the Pantone color space was missing in the "Resources" dictionary. This bug 
was caused by FOP-2337, that introduced a "parent" resource directory. I 
adapted the populateDictionary method of the PDFResources class, so that the 
color space entries of the "parent" dictionary are not lost. @ssteiner: please 
check, if this is correct.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FOP-2818) PDF color spaces are lost when embedding PDF image

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher resolved FOP-2818.
--
Resolution: Fixed
  Assignee: simon steiner  (was: Matthias Reischenbacher)

Fixed as part of http://svn.apache.org/viewvc?view=revision=1842844

> PDF color spaces are lost when embedding PDF image
> --
>
> Key: FOP-2818
> URL: https://issues.apache.org/jira/browse/FOP-2818
> Project: FOP
>  Issue Type: Bug
>  Components: renderer/pdf
>    Reporter: Matthias Reischenbacher
>Assignee: simon steiner
>Priority: Critical
> Attachments: image.pdf, output_broken.pdf, output_fixed.pdf, 
> test_case.xml
>
>
> When embedding a PDF image (via the fop pdf image plugin) into a page, that 
> also contains a color definition with a custom color space (e.g. a Pantone 
> full tone color), the color space definition is lost and the PDF can't be 
> displayed correctly.
> After analyzing the generated PDF file I detected, that the "ColorSpace" 
> entry for the Pantone color space was missing in the "Resources" dictionary. 
> This bug was caused by FOP-2337, that introduced a "parent" resource 
> directory. I adapted the populateDictionary method of the PDFResources class, 
> so that the color space entries of the "parent" dictionary are not lost. 
> @ssteiner: please check, if this is correct.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FOP-2818) PDF color spaces are lost when embedding PDF image

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2818:
-
Attachment: output_broken.pdf
image.pdf
test_case.xml

> PDF color spaces are lost when embedding PDF image
> --
>
> Key: FOP-2818
> URL: https://issues.apache.org/jira/browse/FOP-2818
> Project: FOP
>  Issue Type: Bug
>  Components: renderer/pdf
>    Reporter: Matthias Reischenbacher
>    Assignee: Matthias Reischenbacher
>Priority: Critical
> Attachments: image.pdf, output_broken.pdf, test_case.xml
>
>
> When embedding a PDF image (via the fop pdf image plugin) into a page, that 
> also contains a color definition with a custom color space (e.g. a Pantone 
> full tone color), the color space definition is lost and the PDF can't be 
> displayed correctly.
> After analyzing the generated PDF file I detected, that the "ColorSpace" 
> entry for the Pantone color space was missing in the "Resources" dictionary. 
> This bug was caused by FOP-2337, that introduced a "parent" resource 
> directory. I adapted the populateDictionary method of the PDFResources class, 
> so that the color space entries of the "parent" dictionary are not lost. 
> @ssteiner: please check, if this is correct.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Merge Temp_ChangeBars2 to trunk

[Matthias Reischenbacher]

+1


On 05.07.2018 10:09, Simon Steiner wrote:
> Hi,
>
> Stephan Thesing, Jan Tošovský and William Eliot Kimber have made changes to
> support change-bars
> https://www.w3.org/TR/xsl/#fo_change-bar-begin
>
> The vote will last 5 working days, ending next Thursday. 
>
> https://issues.apache.org/jira/browse/FOP-1760
> http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_ChangeBars2/
>
> Here is my vote: +1
>
> Thanks
>
>

Re: Evaluating test cases for different config settings

[Matthias Reischenbacher]

Hi Jan,

I've checked the code a bit and the LayoutEngineTestCase class doesn't
seem to support custom renderer options defined by the test case XML
file. But it shouldn't be too hard to add this functionality. Have a
look at org.apache.fop.layoutengine.LayoutEngineTestCase.runTest.

Thanks for continuing the work on this ticket! I'll commit the changes
as soon as your test cases are ready.

Best regards,

Matthias


On 08.06.2018 17:26, Jan Tosovsky wrote:
> Dear All,
>
> I've tried adding a new test case for 'Varying table border thickness in PDF
> output' patch:
> https://issues.apache.org/jira/browse/FOP-2536
>
> The patch is only effective in conjuction with 'overpaint-table-borders'
> settings enabled:
> userAgent.getRendererOptions().put("overpaint-table-borders", Boolean.TRUE);
>
> (for my testing purposes I hardcoded it directly instead of retrieving it
> dynamically)
>
> But when this settings is enabled, some standard layout cases fail:
> [junit] Layout test (table-header_in_list_bug.xml): Expected XPath
> expression to evaluate to '4', but got '14' (XPath:
> count(//pageViewport[@nr='1']//block[@prod-id='table']/block))
> [junit] Layout test (table-stepper_colspan_border-before.xml): Expected
> XPath expression to evaluate to '3', but got '12' (XPath:
> count(//pageViewport[1]//flow/block[2]/block))
>
> Is there any possibility to run some test cases with the different settings?
>
> Thanks,
>
> Jan
>

[jira] [Resolved] (FOP-2572) [PATCH] Non-breaking space within a Text node causes an Exception.

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher resolved FOP-2572.
--
Resolution: Fixed
  Assignee: Matthias Reischenbacher

> [PATCH] Non-breaking space within a Text node causes an Exception.
> --
>
> Key: FOP-2572
> URL: https://issues.apache.org/jira/browse/FOP-2572
> Project: FOP
>  Issue Type: Bug
>  Components: fo/inline
>Affects Versions: 2.0
> Environment: All
>Reporter: Karl Snyder
>    Assignee: Matthias Reischenbacher
>Priority: Major
> Attachments: fop-2572.patch
>
>
> A non-breaking space (Option+Space on the Mac) in content will cause the 
> following exception.
> {code}java.lang.ArrayIndexOutOfBoundsException: 14
>   at 
> org.apache.fop.fonts.GlyphMapping.addToLetterAdjust(GlyphMapping.java:286) 
> ~[fop-2.0.jar:na]
>   at 
> org.apache.fop.fonts.GlyphMapping.processWordNoMapping(GlyphMapping.java:248) 
> ~[fop-2.0.jar:na]
>   at 
> org.apache.fop.fonts.GlyphMapping.doGlyphMapping(GlyphMapping.java:93) 
> ~[fop-2.0.jar:na]
>   at 
> org.apache.fop.svg.font.FOPGVTGlyphVector.performDefaultLayout(FOPGVTGlyphVector.java:94)
>  ~[fop-2.0.jar:na]
>   at org.apache.batik.bridge.GlyphLayout.doExplicitGlyphLayout(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.GlyphLayout.adjustTextSpacing(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.GlyphLayout.getAdvance2D(Unknown Source) 
> ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.StrokingTextPainter.getTextChunk(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.StrokingTextPainter.computeTextRuns(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at 
> org.apache.fop.svg.NativeTextPainter.computeTextRuns(NativeTextPainter.java:223)
>  ~[fop-2.0.jar:na]
>   at org.apache.batik.bridge.StrokingTextPainter.getTextRuns(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.StrokingTextPainter.getBounds2D(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.TextNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-bridge-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedPrimitiveBounds(Unknown
>  Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedBounds(Unknown 
> Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getTransformedPrimitiveBounds(Unknown
>  Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedBounds(Unknown 
> Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getTransformedPrimitiveBounds(Unknown
>  Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedBounds(Unknown 
> Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getTransformedPrimitiveBounds(Unknown
>  Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedBounds(Unknown 
> Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at org.apache.batik.gvt.AbstractGraphicsNode.getBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at org.apache.batik.gvt.AbstractGraphicsNode.paint(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at org.apache.fop.svg.PDFTranscoder.transcode(PDFTranscoder.java:185) 
> ~[fop-2.0.jar:na]
>   at org.apache.batik.transcoder.XMLAbstractTranscoder.transcode(Unknown 
> Source) ~[batik-transcoder-1.8.jar:1.8]
>   at org.apache.batik.transcoder.SVGAbstractTranscoder.transcode(Unknown 
> Source) ~[batik-transcoder-1.8.jar:1.8]
> ...{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FOP-2572) [PATCH] Non-breaking space within a Text node causes an Exception.

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2572:
--

Fixed in http://svn.apache.org/viewvc?view=revision=1831346

> [PATCH] Non-breaking space within a Text node causes an Exception.
> --
>
> Key: FOP-2572
> URL: https://issues.apache.org/jira/browse/FOP-2572
> Project: FOP
>  Issue Type: Bug
>  Components: fo/inline
>Affects Versions: 2.0
> Environment: All
>Reporter: Karl Snyder
>Priority: Major
> Attachments: fop-2572.patch
>
>
> A non-breaking space (Option+Space on the Mac) in content will cause the 
> following exception.
> {code}java.lang.ArrayIndexOutOfBoundsException: 14
>   at 
> org.apache.fop.fonts.GlyphMapping.addToLetterAdjust(GlyphMapping.java:286) 
> ~[fop-2.0.jar:na]
>   at 
> org.apache.fop.fonts.GlyphMapping.processWordNoMapping(GlyphMapping.java:248) 
> ~[fop-2.0.jar:na]
>   at 
> org.apache.fop.fonts.GlyphMapping.doGlyphMapping(GlyphMapping.java:93) 
> ~[fop-2.0.jar:na]
>   at 
> org.apache.fop.svg.font.FOPGVTGlyphVector.performDefaultLayout(FOPGVTGlyphVector.java:94)
>  ~[fop-2.0.jar:na]
>   at org.apache.batik.bridge.GlyphLayout.doExplicitGlyphLayout(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.GlyphLayout.adjustTextSpacing(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.GlyphLayout.getAdvance2D(Unknown Source) 
> ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.StrokingTextPainter.getTextChunk(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.StrokingTextPainter.computeTextRuns(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at 
> org.apache.fop.svg.NativeTextPainter.computeTextRuns(NativeTextPainter.java:223)
>  ~[fop-2.0.jar:na]
>   at org.apache.batik.bridge.StrokingTextPainter.getTextRuns(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.StrokingTextPainter.getBounds2D(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.TextNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-bridge-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedPrimitiveBounds(Unknown
>  Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedBounds(Unknown 
> Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getTransformedPrimitiveBounds(Unknown
>  Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedBounds(Unknown 
> Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getTransformedPrimitiveBounds(Unknown
>  Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedBounds(Unknown 
> Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getTransformedPrimitiveBounds(Unknown
>  Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedBounds(Unknown 
> Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at org.apache.batik.gvt.AbstractGraphicsNode.getBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at org.apache.batik.gvt.AbstractGraphicsNode.paint(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at org.apache.fop.svg.PDFTranscoder.transcode(PDFTranscoder.java:185) 
> ~[fop-2.0.jar:na]
>   at org.apache.batik.transcoder.XMLAbstractTranscoder.transcode(Unknown 
> Source) ~[batik-transcoder-1.8.jar:1.8]
>   at org.apache.batik.transcoder.SVGAbstractTranscoder.transcode(Unknown 
> Source) ~[batik-transcoder-1.8.jar:1.8]
> ...{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FOP-2784) [PATCH] FOP-2738: correct array offset when string span interator is used

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2784:
--

[~vladislav]: a proper fix for this issue is attached as patch in FOP-2572.

> [PATCH] FOP-2738: correct array offset when string span interator is used
> -
>
> Key: FOP-2784
> URL: https://issues.apache.org/jira/browse/FOP-2784
> Project: FOP
>  Issue Type: Improvement
>  Components: font/unqualified
>Affects Versions: 2.2
>Reporter: Vlad Ivanov
>Priority: Major
> Attachments: 
> 0001-FOP-2738-correct-array-offset-when-string-span-inter.patch, fop.conf, 
> fop1.fo, image.svg
>
>
> This patch fixes FOP-2738.
> The issue occurred when code in GlyphMapping.java was used with string span 
> iterator. This kind of iterator points somewhere in the string, not 
> necessarily the start; however, iterator indexes were used to index into an 
> array, which caused an exception in some cases. Fix removes iterator index 
> offset in addLetterAdjust.
> Reproducing:
> {code}
> fop -c fop.conf fop1.fo fop1.pdf
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FOP-2789) Page number citation sometimes overlaps text in rl content

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher resolved FOP-2789.
--
Resolution: Fixed

Fixed with http://svn.apache.org/viewvc?view=revision=1830287

> Page number citation sometimes overlaps text in rl content
> --
>
> Key: FOP-2789
> URL: https://issues.apache.org/jira/browse/FOP-2789
> Project: FOP
>  Issue Type: Bug
>    Reporter: Matthias Reischenbacher
>Priority: Critical
> Attachments: rl-link-issue.pdf, rl-link-issue.xml, 
> rl-link-issue_fixed.pdf
>
>
> If the target of a page-number-citation is already resolved, the page number 
> text is created without ipd value and bidi level. This causes the page number 
> to overlap text in right to left content.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FOP-2789) Page number citation sometimes overlaps text in rl content

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2789:
-
Attachment: rl-link-issue.pdf

> Page number citation sometimes overlaps text in rl content
> --
>
> Key: FOP-2789
> URL: https://issues.apache.org/jira/browse/FOP-2789
> Project: FOP
>  Issue Type: Bug
>    Reporter: Matthias Reischenbacher
>Priority: Critical
> Attachments: rl-link-issue.pdf, rl-link-issue.xml, 
> rl-link-issue_fixed.pdf
>
>
> If the target of a page-number-citation is already resolved, the page number 
> text is created without ipd value and bidi level. This causes the page number 
> to overlap text in right to left content.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FOP-2789) Page number citation sometimes overlaps text in rl content

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2789:
-
Attachment: rl-link-issue_fixed.pdf

> Page number citation sometimes overlaps text in rl content
> --
>
> Key: FOP-2789
> URL: https://issues.apache.org/jira/browse/FOP-2789
> Project: FOP
>  Issue Type: Bug
>    Reporter: Matthias Reischenbacher
>Priority: Critical
> Attachments: rl-link-issue.pdf, rl-link-issue.xml, 
> rl-link-issue_fixed.pdf
>
>
> If the target of a page-number-citation is already resolved, the page number 
> text is created without ipd value and bidi level. This causes the page number 
> to overlap text in right to left content.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FOP-2789) Page number citation sometimes overlaps text in rl content

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2789:
-
Attachment: rl-link-issue.xml

> Page number citation sometimes overlaps text in rl content
> --
>
> Key: FOP-2789
> URL: https://issues.apache.org/jira/browse/FOP-2789
> Project: FOP
>  Issue Type: Bug
>    Reporter: Matthias Reischenbacher
>Priority: Critical
> Attachments: rl-link-issue.xml
>
>
> If the target of a page-number-citation is already resolved, the page number 
> text is created without ipd value and bidi level. This causes the page number 
> to overlap text in right to left content.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FOP-2789) Page number citation sometimes overlaps text in rl content

[Matthias Reischenbacher (JIRA)]

Matthias Reischenbacher created FOP-2789:


 Summary: Page number citation sometimes overlaps text in rl content
 Key: FOP-2789
 URL: https://issues.apache.org/jira/browse/FOP-2789
 Project: FOP
  Issue Type: Bug
Reporter: Matthias Reischenbacher


If the target of a page-number-citation is already resolved, the page number 
text is created without ipd value and bidi level. This causes the page number 
to overlap text in right to left content.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Merge Temp_SurrogatePairs to trunk

[Matthias Reischenbacher]

+1


On 09.03.2018 11:04, Simon Steiner wrote:
> Hi,
>
> Simone Rondelli has done some changes that allows you to use code points >
> 65535
>
> The vote will last 5 working days, ending next Friday. 
>
> https://issues.apache.org/jira/browse/FOP-1969
> http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_SurrogatePairs/
>
> Here is my vote: +1
>
> Thanks
>

[jira] [Commented] (FOP-2710) SVG Gradient missing

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2710:
--

Simon, this might be related to: https://issues.apache.org/jira/browse/FOP-2549

> SVG Gradient missing
> 
>
> Key: FOP-2710
> URL: https://issues.apache.org/jira/browse/FOP-2710
> Project: FOP
>  Issue Type: Bug
>Reporter: simon steiner
>Assignee: simon steiner
> Attachments: test.fo
>
>
> fop test.fo out.pdf
> Part of logo missing



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (FOP-1648) [PATCH]internal named destinations

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-1648:
--

As you want. I think I'll have some time end of June, if you can wait until 
then, I can finish it. I'm still not totally sure how I can make SVG/PDF 
related output features testable. I'll look into adding some test methods to 
PDFGraphics2DTestCase, please let me know if you have any other/better ideas. 
Thanks.

> [PATCH]internal named destinations
> --
>
> Key: FOP-1648
> URL: https://issues.apache.org/jira/browse/FOP-1648
> Project: FOP
>  Issue Type: Improvement
>  Components: renderer/pdf
>Affects Versions: trunk
> Environment: Operating System: All
> Platform: All
>Reporter: michaelrichardson89
>Assignee: Chris Bowditch
>  Labels: PatchAvailable
> Attachments: b46980.diff, fop-1648.patch, 
> internal_named_destinations.diff
>
>
> [PATCH]
> I was experiencing an issue where svg graphics would enterpret links of the 
> format:
> 
> as external web-links opening up a web browser.
> I have now fixed this issue (given in the attached patch) so that links in 
> the above format now properly go to an internal named destinations.
> The named destination must be specified with the tag:
> 
> I hope this is helpfull.
> -Michael



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (FOP-1648) [PATCH]internal named destinations

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-1648:
-
Attachment: fop-1648.patch

> [PATCH]internal named destinations
> --
>
> Key: FOP-1648
> URL: https://issues.apache.org/jira/browse/FOP-1648
> Project: FOP
>  Issue Type: Improvement
>  Components: renderer/pdf
>Affects Versions: trunk
> Environment: Operating System: All
> Platform: All
>Reporter: michaelrichardson89
>Assignee: Chris Bowditch
>  Labels: PatchAvailable
> Attachments: b46980.diff, fop-1648.patch, 
> internal_named_destinations.diff
>
>
> [PATCH]
> I was experiencing an issue where svg graphics would enterpret links of the 
> format:
> 
> as external web-links opening up a web browser.
> I have now fixed this issue (given in the attached patch) so that links in 
> the above format now properly go to an internal named destinations.
> The named destination must be specified with the tag:
> 
> I hope this is helpfull.
> -Michael



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (FOP-1648) [PATCH]internal named destinations

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-1648:
--

Chris: I have been working on this ticket some month ago, but didn't get it 
ready for commit. I'll attach you a patch (based on an older version of FOP), 
in case you want to use it.

> [PATCH]internal named destinations
> --
>
> Key: FOP-1648
> URL: https://issues.apache.org/jira/browse/FOP-1648
> Project: FOP
>  Issue Type: Improvement
>  Components: renderer/pdf
>Affects Versions: trunk
> Environment: Operating System: All
> Platform: All
>Reporter: michaelrichardson89
>Assignee: Chris Bowditch
>  Labels: PatchAvailable
> Attachments: b46980.diff, fop-1648.patch, 
> internal_named_destinations.diff
>
>
> [PATCH]
> I was experiencing an issue where svg graphics would enterpret links of the 
> format:
> 
> as external web-links opening up a web browser.
> I have now fixed this issue (given in the attached patch) so that links in 
> the above format now properly go to an internal named destinations.
> The named destination must be specified with the tag:
> 
> I hope this is helpfull.
> -Michael



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (FOP-2570) [PATCH] Misplaced border of spanned table cells in RTL WM context

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher resolved FOP-2570.
--
Resolution: Fixed

Fixed in http://svn.apache.org/viewvc?view=revision=1796180

> [PATCH] Misplaced border of spanned table cells in RTL WM context
> -
>
> Key: FOP-2570
> URL: https://issues.apache.org/jira/browse/FOP-2570
> Project: FOP
>  Issue Type: Bug
>  Components: layout/unqualified
>    Reporter: Matthias Reischenbacher
>    Assignee: Matthias Reischenbacher
> Attachments: fop-2570.patch, rl-table-border-issue-fixed.pdf, 
> rl-table-border-issue.pdf, rl-table-border-issue.xml
>
>
> FOP-2047 fixed table borders of spanned table cells. Since FOP-2310 some 
> borders are misplaced again.
> I'm adding a patch for a first review. I'll add additional checks in the 
> layout test case of FOP-2047 a bit later.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Reopened] (FOP-2570) [PATCH] Misplaced border of spanned table cells in RTL WM context

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher reopened FOP-2570:
--

The fix for col spans contains a bug, which causes slightly misplaced borders, 
when there are row spans.

> [PATCH] Misplaced border of spanned table cells in RTL WM context
> -
>
> Key: FOP-2570
> URL: https://issues.apache.org/jira/browse/FOP-2570
> Project: FOP
>  Issue Type: Bug
>  Components: layout/unqualified
>    Reporter: Matthias Reischenbacher
>    Assignee: Matthias Reischenbacher
> Attachments: fop-2570.patch, rl-table-border-issue-fixed.pdf, 
> rl-table-border-issue.pdf, rl-table-border-issue.xml
>
>
> FOP-2047 fixed table borders of spanned table cells. Since FOP-2310 some 
> borders are misplaced again.
> I'm adding a patch for a first review. I'll add additional checks in the 
> layout test case of FOP-2047 a bit later.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (FOP-2707) Writing mode lost after spanned block

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher resolved FOP-2707.
--
Resolution: Fixed

Fixed in http://svn.apache.org/viewvc?view=revision=1796102

> Writing mode lost after spanned block
> -
>
> Key: FOP-2707
> URL: https://issues.apache.org/jira/browse/FOP-2707
> Project: FOP
>  Issue Type: Bug
>  Components: layout/page
>    Reporter: Matthias Reischenbacher
> Attachments: 2707_test_case.xml
>
>
> If writing-mode "rl-tb" is used in a multi column page, the writing-mode is 
> not applied to the multi column layout, if the page starts with a spanned 
> block.
> The expected page layout in right to left writing mode is:
> Spanned Block
> Col3Col2Col1
> But currently the following layout is generated:
> Spanned Block
> Col1Col2Col3



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (FOP-2707) Writing mode lost after spanned block

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2707:
-
Attachment: 2707_test_case.xml

> Writing mode lost after spanned block
> -
>
> Key: FOP-2707
> URL: https://issues.apache.org/jira/browse/FOP-2707
> Project: FOP
>  Issue Type: Bug
>  Components: layout/page
>    Reporter: Matthias Reischenbacher
> Attachments: 2707_test_case.xml
>
>
> If writing-mode "rl-tb" is used in a multi column page, the writing-mode is 
> not applied to the multi column layout, if the page starts with a spanned 
> block.
> The expected page layout in right to left writing mode is:
> Spanned Block
> Col3Col2Col1
> But currently the following layout is generated:
> Spanned Block
> Col1Col2Col3



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (FOP-2707) Writing mode lost after spanned block

[Matthias Reischenbacher (JIRA)]

Matthias Reischenbacher created FOP-2707:


 Summary: Writing mode lost after spanned block
 Key: FOP-2707
 URL: https://issues.apache.org/jira/browse/FOP-2707
 Project: FOP
  Issue Type: Bug
  Components: layout/page
Reporter: Matthias Reischenbacher


If writing-mode "rl-tb" is used in a multi column page, the writing-mode is not 
applied to the multi column layout, if the page starts with a spanned block.

The expected page layout in right to left writing mode is:

Spanned Block
Col3Col2Col1

But currently the following layout is generated:

Spanned Block
Col1Col2Col3



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Edit wiki page

[Matthias Reischenbacher]

Hi Chris,

yes, it worked. Thanks! Thanks Glenn!

Matthias

On 02.05.2017 05:52, Chris wrote:
> Hi Matthias,
>
> It looks like Glenn added you to the Contributors Group. Can you try again?
>
> Thanks
>
> Chris
>
> On 29/04/2017 20:32, Matthias Reischenbacher wrote:
>> Hi,
>>
>> I'd like to add some additional documentation about running single
>> layout test cases with maven on
>> https://wiki.apache.org/xmlgraphics-fop/HowToCreateLayoutEngineTests. I
>> just created a wiki account: MatthiasReischenbacher. Can anybody give
>> write access in the wiki ACLs?
>>
>> Thanks,
>>
>> Matthias
>>
>> .
>>

[jira] [Resolved] (FOP-2570) [PATCH] Misplaced border of spanned table cells in RTL WM context

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher resolved FOP-2570.
--
Resolution: Fixed

> [PATCH] Misplaced border of spanned table cells in RTL WM context
> -
>
> Key: FOP-2570
> URL: https://issues.apache.org/jira/browse/FOP-2570
> Project: FOP
>  Issue Type: Bug
>  Components: layout/unqualified
>    Reporter: Matthias Reischenbacher
>    Assignee: Matthias Reischenbacher
> Attachments: fop-2570.patch, rl-table-border-issue-fixed.pdf, 
> rl-table-border-issue.pdf, rl-table-border-issue.xml
>
>
> FOP-2047 fixed table borders of spanned table cells. Since FOP-2310 some 
> borders are misplaced again.
> I'm adding a patch for a first review. I'll add additional checks in the 
> layout test case of FOP-2047 a bit later.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Edit wiki page

[Matthias Reischenbacher]

Hi,

I'd like to add some additional documentation about running single
layout test cases with maven on
https://wiki.apache.org/xmlgraphics-fop/HowToCreateLayoutEngineTests. I
just created a wiki account: MatthiasReischenbacher. Can anybody give
write access in the wiki ACLs?

Thanks,

Matthias

[jira] [Comment Edited] (FOP-2536) [PATCH] Varying table border thickness in PDF output

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher edited comment on FOP-2536 at 4/24/17 10:14 AM:


[~segadora] I'll commit the fix. I still haven't found enough time to create 
some unit tests, but hope to be able to do that soon.


was (Author: matthias8283):
~segadora I'll commit the fix. I still haven't found enough time to create some 
unit tests, but hope to be able to do that soon.

> [PATCH] Varying table border thickness in PDF output
> 
>
> Key: FOP-2536
> URL: https://issues.apache.org/jira/browse/FOP-2536
> Project: FOP
>  Issue Type: Improvement
>  Components: renderer/pdf
>Reporter: Martin Leitner
> Attachments: fop-2434-alternative.patch, patch-FOP-2434.diff, 
> Polygon.java, tableBorders.fo, tableBorders_fop_2.0.pdf, 
> tableBorders_fop_2.1_AdobeReader_11.png, tableBorders_fop_2.1.pdf, 
> tableBorders_patched.pdf
>
>
> As already pointed out in a comment to the original issue, this is a problem 
> with the PDF viewers. FOP generates the borders correctly. The viewers render 
> border segments correctly when they are rectangles, but they make mistakes 
> when the segments are more general polygons. In my patch, I am splitting the 
> polygons into rectangles, covering as much of the polygon as possible, write 
> the rectangles to the PDF, then write the remaining triangles.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (FOP-2536) [PATCH] Varying table border thickness in PDF output

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2536:
--

~segadora I'll commit the fix. I still haven't found enough time to create some 
unit tests, but hope to be able to do that soon.

> [PATCH] Varying table border thickness in PDF output
> 
>
> Key: FOP-2536
> URL: https://issues.apache.org/jira/browse/FOP-2536
> Project: FOP
>  Issue Type: Improvement
>  Components: renderer/pdf
>Reporter: Martin Leitner
> Attachments: fop-2434-alternative.patch, patch-FOP-2434.diff, 
> Polygon.java, tableBorders.fo, tableBorders_fop_2.0.pdf, 
> tableBorders_fop_2.1_AdobeReader_11.png, tableBorders_fop_2.1.pdf, 
> tableBorders_patched.pdf
>
>
> As already pointed out in a comment to the original issue, this is a problem 
> with the PDF viewers. FOP generates the borders correctly. The viewers render 
> border segments correctly when they are rectangles, but they make mistakes 
> when the segments are more general polygons. In my patch, I am splitting the 
> polygons into rectangles, covering as much of the polygon as possible, write 
> the rectangles to the PDF, then write the remaining triangles.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (FOP-2536) [PATCH] Varying table border thickness in PDF output

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2536:
--

[~segadora], you might try the other patch: fop-2434-alternative.patch and set 
the following config option:
userAgent.getRendererOptions().put("overpaint-table-borders", Boolean.TRUE);

> [PATCH] Varying table border thickness in PDF output
> 
>
> Key: FOP-2536
> URL: https://issues.apache.org/jira/browse/FOP-2536
> Project: FOP
>  Issue Type: Improvement
>  Components: renderer/pdf
>Reporter: Martin Leitner
> Attachments: fop-2434-alternative.patch, patch-FOP-2434.diff, 
> Polygon.java, tableBorders.fo, tableBorders_fop_2.0.pdf, 
> tableBorders_fop_2.1_AdobeReader_11.png, tableBorders_fop_2.1.pdf, 
> tableBorders_patched.pdf
>
>
> As already pointed out in a comment to the original issue, this is a problem 
> with the PDF viewers. FOP generates the borders correctly. The viewers render 
> border segments correctly when they are rectangles, but they make mistakes 
> when the segments are more general polygons. In my patch, I am splitting the 
> polygons into rectangles, covering as much of the polygon as possible, write 
> the rectangles to the PDF, then write the remaining triangles.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (FOP-2570) [PATCH] Misplaced border of spanned table cells in RTL WM context

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2570:
-
Attachment: rl-table-border-issue-fixed.pdf

> [PATCH] Misplaced border of spanned table cells in RTL WM context
> -
>
> Key: FOP-2570
> URL: https://issues.apache.org/jira/browse/FOP-2570
> Project: FOP
>  Issue Type: Bug
>  Components: layout/unqualified
>    Reporter: Matthias Reischenbacher
>    Assignee: Matthias Reischenbacher
> Attachments: fop-2570.patch, rl-table-border-issue-fixed.pdf, 
> rl-table-border-issue.pdf, rl-table-border-issue.xml
>
>
> FOP-2047 fixed table borders of spanned table cells. Since FOP-2310 some 
> borders are misplaced again.
> I'm adding a patch for a first review. I'll add additional checks in the 
> layout test case of FOP-2047 a bit later.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (FOP-2570) [PATCH] Misplaced border of spanned table cells in RTL WM context

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2570:
-
Attachment: rl-table-border-issue.xml
rl-table-border-issue.pdf

> [PATCH] Misplaced border of spanned table cells in RTL WM context
> -
>
> Key: FOP-2570
> URL: https://issues.apache.org/jira/browse/FOP-2570
> Project: FOP
>  Issue Type: Bug
>  Components: layout/unqualified
>    Reporter: Matthias Reischenbacher
>    Assignee: Matthias Reischenbacher
> Attachments: fop-2570.patch, rl-table-border-issue.pdf, 
> rl-table-border-issue.xml
>
>
> FOP-2047 fixed table borders of spanned table cells. Since FOP-2310 some 
> borders are misplaced again.
> I'm adding a patch for a first review. I'll add additional checks in the 
> layout test case of FOP-2047 a bit later.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (FOP-2617) Text run using "dy" in SVG published to PDF is not properly placed vertically

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2617:
--

I have been working on ComplexGlyphLayout (there are other issues too e.g. 
baseline-shift, see FOP-2528), so I hope that I'll be able to post a patch 
soon. If you don't need the complex script features, I'd recommend to comment 
the code in NativeTextPainter in the meantime.

> Text run using "dy" in SVG published to PDF is not properly placed vertically
> -
>
> Key: FOP-2617
> URL: https://issues.apache.org/jira/browse/FOP-2617
> Project: FOP
>  Issue Type: Bug
>  Components: image/svg
>Affects Versions: 2.1
>Reporter: Radu Coravu
> Fix For: trunk
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> If we have an SVG like:
> {code} "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd;>
> http://www.w3.org/2000/svg; 
>   width="15.90551in" height="12.93701in"
>   >
>   
>   A B  
> 
> {code}
> which gets embedded in an XSL-FO document and then using Apache FOP and Batik 
> we build the PDF, the PDF does not contain the "B" text run on a line under 
> the "A" text run. So it seems to ignore the "dy" attribute set on it.
> Using just Batik to convert the SVG to a binary image works though. So there 
> is probably a problem somewhere in the PDF Graphics 2D or the PDF Text 
> Painter.



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

[jira] [Commented] (FOP-2617) Text run using "dy" in SVG published to PDF is not properly placed vertically

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2617:
--

This is caused by an issue in the ComplexGlyphLayout class. You may comment it 
in the COMPLEX_SCRIPT_TEXT_LAYOUT_FACTORY inside NativeTextPainter in order to 
fall back to the previously used GlyphLayout class by Batik.

> Text run using "dy" in SVG published to PDF is not properly placed vertically
> -
>
> Key: FOP-2617
> URL: https://issues.apache.org/jira/browse/FOP-2617
> Project: FOP
>  Issue Type: Bug
>  Components: image/svg
>Affects Versions: 2.1
>Reporter: Radu Coravu
> Fix For: trunk
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> If we have an SVG like:
> {code} "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd;>
> http://www.w3.org/2000/svg; 
>   width="15.90551in" height="12.93701in"
>   >
>   
>   A B  
> 
> {code}
> which gets embedded in an XSL-FO document and then using Apache FOP and Batik 
> we build the PDF, the PDF does not contain the "B" text run on a line under 
> the "A" text run. So it seems to ignore the "dy" attribute set on it.
> Using just Batik to convert the SVG to a binary image works though. So there 
> is probably a problem somewhere in the PDF Graphics 2D or the PDF Text 
> Painter.



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

[jira] [Comment Edited] (FOP-2536) [PATCH] Varying table border thickness in PDF output

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher edited comment on FOP-2536 at 6/9/16 5:23 PM:
--

Martin: I tried the attached patch but didn't see a visual difference when 
viewing the generated PDF file with Adobe Acrobat. Perhaps you can attach a 
test case and a before/after PDF file.

I attached an alternative patch which takes a different approach: during the 
layout phase the border traits are analyzed and additional layout blocks are 
created, that span over multiple cells and will paint over the existing table 
borders. This over painting can be activated by setting the following renderer 
option:
userAgent.getRendererOptions().put("overpaint-table-borders", Boolean.TRUE);
The visual output is close to optimal (for my use case), but I'm not too happy 
about having duplicate borders (also PDF file size increases a bit). So I'm 
still thinking about how this could be fixed in a more optimal way.


was (Author: matthias8283):
Alternative patch that "overpaints" table borders

> [PATCH] Varying table border thickness in PDF output
> 
>
> Key: FOP-2536
> URL: https://issues.apache.org/jira/browse/FOP-2536
> Project: FOP
>  Issue Type: Improvement
>  Components: renderer/pdf
>Reporter: Martin Leitner
> Attachments: Polygon.java, fop-2434-alternative.patch, 
> patch-FOP-2434.diff
>
>
> As already pointed out in a comment to the original issue, this is a problem 
> with the PDF viewers. FOP generates the borders correctly. The viewers render 
> border segments correctly when they are rectangles, but they make mistakes 
> when the segments are more general polygons. In my patch, I am splitting the 
> polygons into rectangles, covering as much of the polygon as possible, write 
> the rectangles to the PDF, then write the remaining triangles.



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

[jira] [Updated] (FOP-2536) [PATCH] Varying table border thickness in PDF output

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2536:
-
Attachment: fop-2434-alternative.patch

Alternative patch that "overpaints" table borders

> [PATCH] Varying table border thickness in PDF output
> 
>
> Key: FOP-2536
> URL: https://issues.apache.org/jira/browse/FOP-2536
> Project: FOP
>  Issue Type: Improvement
>  Components: renderer/pdf
>Reporter: Martin Leitner
> Attachments: Polygon.java, fop-2434-alternative.patch, 
> patch-FOP-2434.diff
>
>
> As already pointed out in a comment to the original issue, this is a problem 
> with the PDF viewers. FOP generates the borders correctly. The viewers render 
> border segments correctly when they are rectangles, but they make mistakes 
> when the segments are more general polygons. In my patch, I am splitting the 
> polygons into rectangles, covering as much of the polygon as possible, write 
> the rectangles to the PDF, then write the remaining triangles.



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

[jira] [Commented] (FOP-2460) Subsetting OTF font leads to PDF errors when viewing / incorrect characters

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2460:
--

I can confirm that your patch for FOP-2557 fixes also this issue. Nice work 
chunlinyao! Robert, could you do a review of the patch? chunlinyao: if you 
could add a test case (similar to OTFSubSetFileTestCase.java), it would be 
perfect.

> Subsetting OTF font leads to PDF errors when viewing / incorrect characters
> ---
>
> Key: FOP-2460
> URL: https://issues.apache.org/jira/browse/FOP-2460
> Project: FOP
>  Issue Type: Bug
>  Components: font/opentype
>Affects Versions: trunk
>Reporter: Robert Meyer
>
> When attempting to generate a document whilst subsetting the 
> VilleroyBoch-Regular.otf font, different viewers will either show errors, no 
> text or lead to incorrect or corrupt characters being drawn.
> I currentlty believe this is down to either a subroutine not being copied 
> from the original font leading to a invalid reference, or the subroutine does 
> not contain valid data. When looking at this font in FontForge, 3 characters 
> in a "hello world" example I used were missing which backs up this hypothesis.
> [EDIT] I've removed the font as I did not check if there were copyright 
> issues by making it public domain. I will work when I am able to do so but 
> keep the font privately unless I hear otherwise from the user who originally 
> posted the problem



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

[jira] [Commented] (FOP-2572) Non-breaking space within a Text node causes an Exception.

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2572:
--

Unfortunately it's a bit more complicated then that. The GlyphMapping class 
normally expects a letterSpaceAdjustArray for all chars (not only the current 
range, that starts with startIndex). So not the index is wrong, it's the array.

Attaching a patch, that attempts to fix this issue. I haven't committed it yet, 
because it still needs a proper test case.

> Non-breaking space within a Text node causes an Exception.
> --
>
> Key: FOP-2572
> URL: https://issues.apache.org/jira/browse/FOP-2572
> Project: FOP
>  Issue Type: Bug
>  Components: fo/inline
>Affects Versions: 2.0
> Environment: All
>Reporter: Karl Snyder
>
> A non-breaking space (Option+Space on the Mac) in content will cause the 
> following exception.
> {code}java.lang.ArrayIndexOutOfBoundsException: 14
>   at 
> org.apache.fop.fonts.GlyphMapping.addToLetterAdjust(GlyphMapping.java:286) 
> ~[fop-2.0.jar:na]
>   at 
> org.apache.fop.fonts.GlyphMapping.processWordNoMapping(GlyphMapping.java:248) 
> ~[fop-2.0.jar:na]
>   at 
> org.apache.fop.fonts.GlyphMapping.doGlyphMapping(GlyphMapping.java:93) 
> ~[fop-2.0.jar:na]
>   at 
> org.apache.fop.svg.font.FOPGVTGlyphVector.performDefaultLayout(FOPGVTGlyphVector.java:94)
>  ~[fop-2.0.jar:na]
>   at org.apache.batik.bridge.GlyphLayout.doExplicitGlyphLayout(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.GlyphLayout.adjustTextSpacing(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.GlyphLayout.getAdvance2D(Unknown Source) 
> ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.StrokingTextPainter.getTextChunk(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.StrokingTextPainter.computeTextRuns(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at 
> org.apache.fop.svg.NativeTextPainter.computeTextRuns(NativeTextPainter.java:223)
>  ~[fop-2.0.jar:na]
>   at org.apache.batik.bridge.StrokingTextPainter.getTextRuns(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.StrokingTextPainter.getBounds2D(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.TextNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-bridge-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedPrimitiveBounds(Unknown
>  Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedBounds(Unknown 
> Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getTransformedPrimitiveBounds(Unknown
>  Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedBounds(Unknown 
> Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getTransformedPrimitiveBounds(Unknown
>  Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedBounds(Unknown 
> Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getTransformedPrimitiveBounds(Unknown
>  Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedBounds(Unknown 
> Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at org.apache.batik.gvt.AbstractGraphicsNode.getBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at org.apache.batik.gvt.AbstractGraphicsNode.paint(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at org.apache.fop.svg.PDFTranscoder.transcode(PDFTranscoder.java:185) 
> ~[fop-2.0.jar:na]
>   at org.apache.batik.transcoder.XMLAbstractTranscoder.transcode(Unknown 
> Source) ~[batik-transcoder-1.8.jar:1.8]
>   at org.apache.batik.transcoder.SVGAbstractTranscoder.transcode(Unknown 
> Source) ~[batik-transcoder-1.8.jar:1.8]
> ...{code}



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

[jira] [Updated] (FOP-2572) Non-breaking space within a Text node causes an Exception.

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2572:
-
Attachment: fop-2572.patch

> Non-breaking space within a Text node causes an Exception.
> --
>
> Key: FOP-2572
> URL: https://issues.apache.org/jira/browse/FOP-2572
> Project: FOP
>  Issue Type: Bug
>  Components: fo/inline
>Affects Versions: 2.0
> Environment: All
>Reporter: Karl Snyder
> Attachments: fop-2572.patch
>
>
> A non-breaking space (Option+Space on the Mac) in content will cause the 
> following exception.
> {code}java.lang.ArrayIndexOutOfBoundsException: 14
>   at 
> org.apache.fop.fonts.GlyphMapping.addToLetterAdjust(GlyphMapping.java:286) 
> ~[fop-2.0.jar:na]
>   at 
> org.apache.fop.fonts.GlyphMapping.processWordNoMapping(GlyphMapping.java:248) 
> ~[fop-2.0.jar:na]
>   at 
> org.apache.fop.fonts.GlyphMapping.doGlyphMapping(GlyphMapping.java:93) 
> ~[fop-2.0.jar:na]
>   at 
> org.apache.fop.svg.font.FOPGVTGlyphVector.performDefaultLayout(FOPGVTGlyphVector.java:94)
>  ~[fop-2.0.jar:na]
>   at org.apache.batik.bridge.GlyphLayout.doExplicitGlyphLayout(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.GlyphLayout.adjustTextSpacing(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.GlyphLayout.getAdvance2D(Unknown Source) 
> ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.StrokingTextPainter.getTextChunk(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.StrokingTextPainter.computeTextRuns(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at 
> org.apache.fop.svg.NativeTextPainter.computeTextRuns(NativeTextPainter.java:223)
>  ~[fop-2.0.jar:na]
>   at org.apache.batik.bridge.StrokingTextPainter.getTextRuns(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.StrokingTextPainter.getBounds2D(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.TextNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-bridge-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedPrimitiveBounds(Unknown
>  Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedBounds(Unknown 
> Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getTransformedPrimitiveBounds(Unknown
>  Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedBounds(Unknown 
> Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getTransformedPrimitiveBounds(Unknown
>  Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedBounds(Unknown 
> Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getTransformedPrimitiveBounds(Unknown
>  Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedBounds(Unknown 
> Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at org.apache.batik.gvt.AbstractGraphicsNode.getBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at org.apache.batik.gvt.AbstractGraphicsNode.paint(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at org.apache.fop.svg.PDFTranscoder.transcode(PDFTranscoder.java:185) 
> ~[fop-2.0.jar:na]
>   at org.apache.batik.transcoder.XMLAbstractTranscoder.transcode(Unknown 
> Source) ~[batik-transcoder-1.8.jar:1.8]
>   at org.apache.batik.transcoder.SVGAbstractTranscoder.transcode(Unknown 
> Source) ~[batik-transcoder-1.8.jar:1.8]
> ...{code}



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

[jira] [Updated] (FOP-2572) [PATCH] Non-breaking space within a Text node causes an Exception.

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2572:
-
Summary: [PATCH] Non-breaking space within a Text node causes an Exception. 
 (was: Non-breaking space within a Text node causes an Exception.)

> [PATCH] Non-breaking space within a Text node causes an Exception.
> --
>
> Key: FOP-2572
> URL: https://issues.apache.org/jira/browse/FOP-2572
> Project: FOP
>  Issue Type: Bug
>  Components: fo/inline
>Affects Versions: 2.0
> Environment: All
>Reporter: Karl Snyder
> Attachments: fop-2572.patch
>
>
> A non-breaking space (Option+Space on the Mac) in content will cause the 
> following exception.
> {code}java.lang.ArrayIndexOutOfBoundsException: 14
>   at 
> org.apache.fop.fonts.GlyphMapping.addToLetterAdjust(GlyphMapping.java:286) 
> ~[fop-2.0.jar:na]
>   at 
> org.apache.fop.fonts.GlyphMapping.processWordNoMapping(GlyphMapping.java:248) 
> ~[fop-2.0.jar:na]
>   at 
> org.apache.fop.fonts.GlyphMapping.doGlyphMapping(GlyphMapping.java:93) 
> ~[fop-2.0.jar:na]
>   at 
> org.apache.fop.svg.font.FOPGVTGlyphVector.performDefaultLayout(FOPGVTGlyphVector.java:94)
>  ~[fop-2.0.jar:na]
>   at org.apache.batik.bridge.GlyphLayout.doExplicitGlyphLayout(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.GlyphLayout.adjustTextSpacing(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.GlyphLayout.getAdvance2D(Unknown Source) 
> ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.StrokingTextPainter.getTextChunk(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.StrokingTextPainter.computeTextRuns(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at 
> org.apache.fop.svg.NativeTextPainter.computeTextRuns(NativeTextPainter.java:223)
>  ~[fop-2.0.jar:na]
>   at org.apache.batik.bridge.StrokingTextPainter.getTextRuns(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.StrokingTextPainter.getBounds2D(Unknown 
> Source) ~[batik-bridge-1.8.jar:1.8]
>   at org.apache.batik.bridge.TextNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-bridge-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedPrimitiveBounds(Unknown
>  Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedBounds(Unknown 
> Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getTransformedPrimitiveBounds(Unknown
>  Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedBounds(Unknown 
> Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getTransformedPrimitiveBounds(Unknown
>  Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedBounds(Unknown 
> Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getTransformedPrimitiveBounds(Unknown
>  Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.AbstractGraphicsNode.getTransformedBounds(Unknown 
> Source) ~[batik-gvt-1.8.jar:1.8]
>   at 
> org.apache.batik.gvt.CompositeGraphicsNode.getPrimitiveBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at org.apache.batik.gvt.AbstractGraphicsNode.getBounds(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at org.apache.batik.gvt.AbstractGraphicsNode.paint(Unknown Source) 
> ~[batik-gvt-1.8.jar:1.8]
>   at org.apache.fop.svg.PDFTranscoder.transcode(PDFTranscoder.java:185) 
> ~[fop-2.0.jar:na]
>   at org.apache.batik.transcoder.XMLAbstractTranscoder.transcode(Unknown 
> Source) ~[batik-transcoder-1.8.jar:1.8]
>   at org.apache.batik.transcoder.SVGAbstractTranscoder.transcode(Unknown 
> Source) ~[batik-transcoder-1.8.jar:1.8]
> ...{code}



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

[jira] [Created] (FOP-2570) [PATCH] Misplaced border of spanned table cells in RTL WM context

[Matthias Reischenbacher (JIRA)]

Matthias Reischenbacher created FOP-2570:


 Summary: [PATCH] Misplaced border of spanned table cells in RTL WM 
context
 Key: FOP-2570
 URL: https://issues.apache.org/jira/browse/FOP-2570
 Project: FOP
  Issue Type: Bug
  Components: layout/unqualified
Reporter: Matthias Reischenbacher


FOP-2047 fixed table borders of spanned table cells. Since FOP-2310 some 
borders are misplaced again.
I'm adding a patch for a first review. I'll add additional checks in the layout 
test case of FOP-2047 a bit later.



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

Re: Issue with margin-bottom="10px" for of:block inside a list item.

[Matthias Reischenbacher]

Hi,

this is caused by https://issues.apache.org/jira/browse/FOP-2461 and
should be fixed in FOP 2.1, which will be released in a few days.

BR,
Matthias

On 08.01.2016 18:10, bharat.attal...@hotmail.com wrote:
> Below is the error message getting back.
>
> Jan 08, 2016 2:54:09 PM org.apache.fop.fo.FOTreeBuilder fatalError
> SEVERE: org.xml.sax.SAXParseException; systemId:
> file:/Users/Attaluri/Documents/Projects/R/abc/fop-2.0/BOTTOM_TEST.xsl;
> lineNumber: 25; columnNumber: 51; java.lang.NullPointerException
> Jan 08, 2016 2:54:09 PM org.apache.fop.cli.Main startFOP
> SEVERE: Exception
> org.apache.fop.apps.FOPException: java.lang.NullPointerException
> javax.xml.transform.TransformerException: java.lang.NullPointerException
>   at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288)
>   at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115)
>   at org.apache.fop.cli.Main.startFOP(Main.java:186)
>   at org.apache.fop.cli.Main.main(Main.java:217)
> Caused by: javax.xml.transform.TransformerException:
> java.lang.NullPointerException
>   at
> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2416)
>   at
> org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:1374)
>   at
> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
>   at
> org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(TransformerImpl.java:2281)
>   at
> org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1367)
>   at
> org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:709)
>   at
> org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1284)
>   at
> org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1262)
>   at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285)
>   ... 3 more
> Caused by: java.lang.NullPointerException
>   at
> org.apache.fop.layoutmgr.list.ListItemLayoutManager.getCombinedKnuthElementsForListItem(ListItemLayoutManager.java:396)
>   at
> org.apache.fop.layoutmgr.list.ListItemLayoutManager.getNextKnuthElements(ListItemLayoutManager.java:326)
>   at
> org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:239)
>   at
> org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:498)
>   at
> org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:289)
>   at
> org.apache.fop.layoutmgr.list.ListBlockLayoutManager.getNextKnuthElements(ListBlockLayoutManager.java:103)
>   at
> org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:239)
>   at
> org.apache.fop.layoutmgr.BlockLayoutManager.getNextChildElements(BlockLayoutManager.java:141)
>   at
> org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:289)
>   at
> org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:113)
>   at
> org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:105)
>   at
> org.apache.fop.layoutmgr.FlowLayoutManager.getNextChildElements(FlowLayoutManager.java:223)
>   at
> org.apache.fop.layoutmgr.FlowLayoutManager.addChildElements(FlowLayoutManager.java:147)
>   at
> org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:116)
>   at
> org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:69)
>   at
> org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:252)
>   at
> org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:643)
>   at
> org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:178)
>   at
> org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:158)
>   at
> org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:384)
>   at org.apache.fop.layoutmgr.PageBreaker.doLayout(PageBreaker.java:112)
>   at
> org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:138)
>   at
> org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:267)
>   at
> org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:130)
>   at
> org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:360)
>   at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:190)
>   at
> org.apache.xml.serializer.ToXMLSAXHandler.endElement(ToXMLSAXHandler.java:261)
>   at
> org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:1399)
>   at
> 

Re: JavaIO Default ICC Profiles

[Matthias Reischenbacher]

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

[jira] [Updated] (FOP-2564) Ignore ICC profiles added by ImageIO loader

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2564:
-
Attachment: fop-2564-commons.patch

> Ignore ICC profiles added by ImageIO loader
> ---
>
> Key: FOP-2564
> URL: https://issues.apache.org/jira/browse/FOP-2564
> Project: FOP
>  Issue Type: Bug
>  Components: image/png
>    Reporter: Matthias Reischenbacher
> Attachments: fop-2564-commons.patch, fop-2564.patch
>
>
> When rendering PNG files for PDF output, ICC profiles are taken into account 
> which were added by the ImageIO loader. This causes an unexpected color 
> display (light, dull colors) and should be avoided.
> This bug only applies to image files that don't have an embedded ICC profile 
> and are loaded by ImageLoaderImageIO.



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

[jira] [Updated] (FOP-2564) Ignore ICC profiles added by ImageIO loader

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2564:
-
Attachment: fop-2564.patch

> Ignore ICC profiles added by ImageIO loader
> ---
>
> Key: FOP-2564
> URL: https://issues.apache.org/jira/browse/FOP-2564
> Project: FOP
>  Issue Type: Bug
>  Components: image/png
>    Reporter: Matthias Reischenbacher
> Attachments: fop-2564-commons.patch, fop-2564.patch
>
>
> When rendering PNG files for PDF output, ICC profiles are taken into account 
> which were added by the ImageIO loader. This causes an unexpected color 
> display (light, dull colors) and should be avoided.
> This bug only applies to image files that don't have an embedded ICC profile 
> and are loaded by ImageLoaderImageIO.



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

[jira] [Updated] (FOP-2564) [PATCH] Ignore ICC profiles added by ImageIO loader

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2564:
-
Summary: [PATCH] Ignore ICC profiles added by ImageIO loader  (was: Ignore 
ICC profiles added by ImageIO loader)

> [PATCH] Ignore ICC profiles added by ImageIO loader
> ---
>
> Key: FOP-2564
> URL: https://issues.apache.org/jira/browse/FOP-2564
> Project: FOP
>  Issue Type: Bug
>  Components: image/png
>    Reporter: Matthias Reischenbacher
> Attachments: fop-2564-commons.patch, fop-2564.patch
>
>
> When rendering PNG files for PDF output, ICC profiles are taken into account 
> which were added by the ImageIO loader. This causes an unexpected color 
> display (light, dull colors) and should be avoided.
> This bug only applies to image files that don't have an embedded ICC profile 
> and are loaded by ImageLoaderImageIO.



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

Re: JavaIO Default ICC Profiles

[Matthias Reischenbacher]

Hi,

I just added two patches at
https://issues.apache.org/jira/browse/FOP-2564 which attempt to give
more control over ICC profile handling. On commons side I added the ICC
profile as a separate parameter to the ImageBuffered/ImageRendered
constructors. This causes quite some code changes in other classes, but
I think is nicer than just resetting the ICC profile after instantiation
of those objects.
On FOP side the change is much simpler: instead of always using the ICC
profile provided by the encoding helper (which is only necessary if the
color model actually changes), the ICC profile of the image is used
(just as in AbstractImageAdapter.getEffectiveICCProfile()).
With this new version of my fix, both image types (files with and
without ICC profiles) are correctly processed.

BR,
Matthias

On 13.01.2016 09:26, Luis Bernardo wrote:
>
> 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 <mailto: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
> >>
> >
>
>
>

[jira] [Updated] (FOP-2564) [PATCH] Ignore ICC profiles added by ImageIO loader

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2564:
-
Attachment: fop-2564.patch
fop-2564-commons.patch

> [PATCH] Ignore ICC profiles added by ImageIO loader
> ---
>
> Key: FOP-2564
> URL: https://issues.apache.org/jira/browse/FOP-2564
> Project: FOP
>  Issue Type: Bug
>  Components: image/png
>    Reporter: Matthias Reischenbacher
> Attachments: fop-2564-commons.patch, fop-2564.patch
>
>
> When rendering PNG files for PDF output, ICC profiles are taken into account 
> which were added by the ImageIO loader. This causes an unexpected color 
> display (light, dull colors) and should be avoided.
> This bug only applies to image files that don't have an embedded ICC profile 
> and are loaded by ImageLoaderImageIO.



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

[jira] [Updated] (FOP-2564) [PATCH] Ignore ICC profiles added by ImageIO loader

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2564:
-
Attachment: (was: fop-2564-commons.patch)

> [PATCH] Ignore ICC profiles added by ImageIO loader
> ---
>
> Key: FOP-2564
> URL: https://issues.apache.org/jira/browse/FOP-2564
> Project: FOP
>  Issue Type: Bug
>  Components: image/png
>    Reporter: Matthias Reischenbacher
> Attachments: fop-2564-commons.patch, fop-2564.patch
>
>
> When rendering PNG files for PDF output, ICC profiles are taken into account 
> which were added by the ImageIO loader. This causes an unexpected color 
> display (light, dull colors) and should be avoided.
> This bug only applies to image files that don't have an embedded ICC profile 
> and are loaded by ImageLoaderImageIO.



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

[jira] [Updated] (FOP-2564) [PATCH] Ignore ICC profiles added by ImageIO loader

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2564:
-
Attachment: (was: fop-2564.patch)

> [PATCH] Ignore ICC profiles added by ImageIO loader
> ---
>
> Key: FOP-2564
> URL: https://issues.apache.org/jira/browse/FOP-2564
> Project: FOP
>  Issue Type: Bug
>  Components: image/png
>    Reporter: Matthias Reischenbacher
> Attachments: fop-2564-commons.patch, fop-2564.patch
>
>
> When rendering PNG files for PDF output, ICC profiles are taken into account 
> which were added by the ImageIO loader. This causes an unexpected color 
> display (light, dull colors) and should be avoided.
> This bug only applies to image files that don't have an embedded ICC profile 
> and are loaded by ImageLoaderImageIO.



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

[jira] [Commented] (FOP-2564) [PATCH] Ignore ICC profiles added by ImageIO loader

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2564:
--

Added a new version of the patch, which fixes s problem with Graphics2D output 
(e.g. SVG --> PDF). PDFGraphics2D.addRenderedImage re-creates a 
org.apache.xmlgraphics.image.loader.impl.ImageRendered instance, that can be 
handled by the ImageRenderedAdapter. This is not nice, because the image loader 
originally creates a org.apache.xmlgraphics.image.loader.impl.ImageRendered 
instance, which is then lost because 
ImageConverterBitmap2G2D.Graphics2DImagePainterImpl.paint() can only pass a 
java.awt.image.RenderedImage instance. This problem is also visible when 
PDFGraphics2D.addRenderedImage has to re-create the ImageInfo instance 
(ImageInfo info = new ImageInfo(null, "image/unknown")). In order to fix that, 
I wrap the org.apache.xmlgraphics.image.loader.impl.ImageRendered instance in a 
new class (ImageRenderedG2D) that implements the java.awt.image.RenderedImage 
interface and gives access to the original 
org.apache.xmlgraphics.image.loader.impl.ImageRendered instance.


> [PATCH] Ignore ICC profiles added by ImageIO loader
> ---
>
> Key: FOP-2564
> URL: https://issues.apache.org/jira/browse/FOP-2564
> Project: FOP
>  Issue Type: Bug
>  Components: image/png
>    Reporter: Matthias Reischenbacher
> Attachments: fop-2564-commons.patch, fop-2564.patch
>
>
> When rendering PNG files for PDF output, ICC profiles are taken into account 
> which were added by the ImageIO loader. This causes an unexpected color 
> display (light, dull colors) and should be avoided.
> This bug only applies to image files that don't have an embedded ICC profile 
> and are loaded by ImageLoaderImageIO.



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

[jira] [Created] (FOP-2564) Ignore ICC profiles added by ImageIO loader

[Matthias Reischenbacher (JIRA)]

Matthias Reischenbacher created FOP-2564:


 Summary: Ignore ICC profiles added by ImageIO loader
 Key: FOP-2564
 URL: https://issues.apache.org/jira/browse/FOP-2564
 Project: FOP
  Issue Type: Bug
  Components: image/png
Reporter: Matthias Reischenbacher


When rendering PNG files for PDF output, ICC profiles are taken into account 
which were added by the ImageIO loader. This causes an unexpected color display 
(light, dull colors) and should be avoided.
This bug only applies to image files that don't have an embedded ICC profile 
and are loaded by ImageLoaderImageIO.



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

JavaIO Default ICC Profiles

[Matthias Reischenbacher]

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)

[Matthias Reischenbacher]

+1

On 07.01.2016 11:23, Simon Steiner wrote:
> 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
>
>

[jira] [Commented] (FOP-2557) Adobe Reader report corrupt embedded font

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2557:
--

This might be related to issue #2460.

> Adobe Reader report corrupt embedded font 
> --
>
> Key: FOP-2557
> URL: https://issues.apache.org/jira/browse/FOP-2557
> Project: FOP
>  Issue Type: Bug
>  Components: fo/block
>Affects Versions: trunk
> Environment: Mac OSX 10.10, JDK 1.8
>Reporter: chunlinyao
> Attachments: fop.xconf, test_fail.xml, test_fail2.xml, test_good.xml
>
>
> When use NotoSansCJKSc regular font, If I don't include any number the 
> embedded subset is corrupt.
> How to repeat
> 1. Get FOP from trunk@1720811
> 2. Get Font from 
> https://github.com/googlei18n/noto-cjk/blob/40d9f5b179a59a06b98373c76bdc3e2119e4e6b2/NotoSansCJKsc-Regular.otf
> 3. Use my config file and transform my fo files.



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

[jira] [Commented] (FOP-2512) java.lang.NullPointerException: Parameter alpha must not be null

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2512:
--

Yes. I can't, because I don't seem to have the right to do so.

> java.lang.NullPointerException: Parameter alpha must not be null
> 
>
> Key: FOP-2512
> URL: https://issues.apache.org/jira/browse/FOP-2512
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Mathieu Malaterre
> Attachments: 16x16.png, 19x13.png, 22x22.png
>
>
> fop is not capable of dealing with some PNG, it keeps on failing with:
> Error while rendering page 9
> java.lang.NullPointerException: Parameter alpha must not be null
> Exception
> java.lang.NullPointerException: Parameter alpha must not be null
> Input is:
> $ pnginfo test.png
> test.png...
>   Image Width: 411 Image Length: 225
>   Bitdepth (Bits/Sample): 8
>   Channels (Samples/Pixel): 1
>   Pixel depth (Pixel Depth): 8
>   Colour Type (Photometric Interpretation): PALETTED COLOUR with alpha (18 
> colours, 17 transparent) 
>   Image filter: Single row per byte filter 
>   Interlacing: No interlacing 
>   Compression Scheme: Deflate method 8, 32k window
>   Resolution: 0, 0 (unit unknown)
>   FillOrder: msb-to-lsb
>   Byte Order: Network (Big Endian)
>   Number of text strings: 0 of 0



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

[jira] [Commented] (FOP-2549) [PATCH] SVGs with radial gradiant causes PDF display error

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2549:
--

Thanks for looking into this too, Andreas! So basically the fourth stop element 
needs be ignored, because it makes no sense to have two stop elements with the 
same offset, right?

> [PATCH] SVGs with radial gradiant causes PDF display error
> --
>
> Key: FOP-2549
> URL: https://issues.apache.org/jira/browse/FOP-2549
> Project: FOP
>  Issue Type: Bug
>  Components: image/svg
>    Reporter: Matthias Reischenbacher
> Attachments: fop-2549-test-case.pdf, fop-2549-test-case.svg, 
> fop-2549-test-case_wrong.pdf, fop-2549.patch
>
>
> A radial gradiant isn't processed correctly by FOP. E.g. the following 
> gradiant:
> cx="51159.898"
>cy="57300"
>r="5279.6602"
>fx="51159.898"
>fy="57300"
>id="id0"
>gradientUnits="userSpaceOnUse">
>id="stop28"
>style="stop-color:#fefefe;stop-opacity:1"
>offset="0" />
>id="stop30"
>style="stop-color:#cdcece;stop-opacity:1"
>offset="0.58823502" />
>id="stop32"
>style="stop-color:#9d9e9e;stop-opacity:1"
>offset="1" />
>id="stop34"
>style="stop-color:#9d9e9e;stop-opacity:1"
>offset="1" />
>   
> is only outputted with one "Bound" entry in the PDF color function (instead 
> of two).
> When opening the PDF with Adobe Acrobat the SVG is only partially displayed 
> and an error message pops up after clicking on the image.



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

[jira] [Created] (FOP-2549) [PATCH] SVGs with radial gradiant causes PDF display error

[Matthias Reischenbacher (JIRA)]

Matthias Reischenbacher created FOP-2549:


 Summary: [PATCH] SVGs with radial gradiant causes PDF display error
 Key: FOP-2549
 URL: https://issues.apache.org/jira/browse/FOP-2549
 Project: FOP
  Issue Type: Bug
  Components: image/svg
Reporter: Matthias Reischenbacher


A radial gradiant isn't processed correctly by FOP. E.g. the following gradiant:


   
   
   
   
  

is only outputted with one "Bound" entry in the PDF color function (instead of 
two).

When opening the PDF with Adobe Acrobat the SVG is only partially displayed and 
an error message pops up after clicking on the image.



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

[jira] [Updated] (FOP-2549) [PATCH] SVGs with radial gradiant causes PDF display error

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2549:
-
Attachment: fop-2549-test-case.pdf

> [PATCH] SVGs with radial gradiant causes PDF display error
> --
>
> Key: FOP-2549
> URL: https://issues.apache.org/jira/browse/FOP-2549
> Project: FOP
>  Issue Type: Bug
>  Components: image/svg
>    Reporter: Matthias Reischenbacher
> Attachments: fop-2549-test-case.pdf, fop-2549-test-case.svg, 
> fop-2549-test-case_wrong.pdf
>
>
> A radial gradiant isn't processed correctly by FOP. E.g. the following 
> gradiant:
> cx="51159.898"
>cy="57300"
>r="5279.6602"
>fx="51159.898"
>fy="57300"
>id="id0"
>gradientUnits="userSpaceOnUse">
>id="stop28"
>style="stop-color:#fefefe;stop-opacity:1"
>offset="0" />
>id="stop30"
>style="stop-color:#cdcece;stop-opacity:1"
>offset="0.58823502" />
>id="stop32"
>style="stop-color:#9d9e9e;stop-opacity:1"
>offset="1" />
>id="stop34"
>style="stop-color:#9d9e9e;stop-opacity:1"
>offset="1" />
>   
> is only outputted with one "Bound" entry in the PDF color function (instead 
> of two).
> When opening the PDF with Adobe Acrobat the SVG is only partially displayed 
> and an error message pops up after clicking on the image.



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

[jira] [Updated] (FOP-2549) [PATCH] SVGs with radial gradiant causes PDF display error

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2549:
-
Attachment: fop-2549.patch

> [PATCH] SVGs with radial gradiant causes PDF display error
> --
>
> Key: FOP-2549
> URL: https://issues.apache.org/jira/browse/FOP-2549
> Project: FOP
>  Issue Type: Bug
>  Components: image/svg
>    Reporter: Matthias Reischenbacher
> Attachments: fop-2549-test-case.pdf, fop-2549-test-case.svg, 
> fop-2549-test-case_wrong.pdf, fop-2549.patch
>
>
> A radial gradiant isn't processed correctly by FOP. E.g. the following 
> gradiant:
> cx="51159.898"
>cy="57300"
>r="5279.6602"
>fx="51159.898"
>fy="57300"
>id="id0"
>gradientUnits="userSpaceOnUse">
>id="stop28"
>style="stop-color:#fefefe;stop-opacity:1"
>offset="0" />
>id="stop30"
>style="stop-color:#cdcece;stop-opacity:1"
>offset="0.58823502" />
>id="stop32"
>style="stop-color:#9d9e9e;stop-opacity:1"
>offset="1" />
>id="stop34"
>style="stop-color:#9d9e9e;stop-opacity:1"
>offset="1" />
>   
> is only outputted with one "Bound" entry in the PDF color function (instead 
> of two).
> When opening the PDF with Adobe Acrobat the SVG is only partially displayed 
> and an error message pops up after clicking on the image.



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

[jira] [Commented] (FOP-2549) [PATCH] SVGs with radial gradiant causes PDF display error

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2549:
--

I'm not 100% sure if my patch is correct, because I have never worked with 
shadings before. From what I could deduce so far, is that the function "Bounds" 
are derived from the SVG stop elements. If the stop offset is "1", the function 
Bound isn't correctly processed. Is it valid to assume 0.999... when the offset 
is 1? Using "1" isn't allowed because the Bound values must be within the 
"Domain" (in this case between 0 and 1).

> [PATCH] SVGs with radial gradiant causes PDF display error
> --
>
> Key: FOP-2549
> URL: https://issues.apache.org/jira/browse/FOP-2549
> Project: FOP
>  Issue Type: Bug
>  Components: image/svg
>Reporter: Matthias Reischenbacher
> Attachments: fop-2549-test-case.pdf, fop-2549-test-case.svg, 
> fop-2549-test-case_wrong.pdf, fop-2549.patch
>
>
> A radial gradiant isn't processed correctly by FOP. E.g. the following 
> gradiant:
> cx="51159.898"
>cy="57300"
>r="5279.6602"
>fx="51159.898"
>fy="57300"
>id="id0"
>gradientUnits="userSpaceOnUse">
>id="stop28"
>style="stop-color:#fefefe;stop-opacity:1"
>offset="0" />
>id="stop30"
>style="stop-color:#cdcece;stop-opacity:1"
>offset="0.58823502" />
>id="stop32"
>style="stop-color:#9d9e9e;stop-opacity:1"
>offset="1" />
>id="stop34"
>style="stop-color:#9d9e9e;stop-opacity:1"
>offset="1" />
>   
> is only outputted with one "Bound" entry in the PDF color function (instead 
> of two).
> When opening the PDF with Adobe Acrobat the SVG is only partially displayed 
> and an error message pops up after clicking on the image.



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

[jira] [Commented] (FOP-2512) java.lang.NullPointerException: Parameter alpha must not be null

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2512:
--

Fixed in http://svn.apache.org/viewvc?view=revision=1716758

It's interesting to see how much bug reports are out there in the web about 
this same issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692556
https://github.com/dita-ot/dita-ot/issues/1822
http://jira.xwiki.org/browse/XWIKI-8274

My fix avoids to create an alpha raster, if the ColorModel implementation 
doesn't return one. This issue seems to affect only transparent PNGs with 
indexed color model. The alpha raster is used for the SMask entry in PDF. 
Transparency works in PDF even without SMask (any only with Mask) entry. Please 
let me know if there is anything wrong with my approach.

> java.lang.NullPointerException: Parameter alpha must not be null
> 
>
> Key: FOP-2512
> URL: https://issues.apache.org/jira/browse/FOP-2512
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Mathieu Malaterre
> Attachments: 16x16.png, 19x13.png, 22x22.png
>
>
> fop is not capable of dealing with some PNG, it keeps on failing with:
> Error while rendering page 9
> java.lang.NullPointerException: Parameter alpha must not be null
> Exception
> java.lang.NullPointerException: Parameter alpha must not be null
> Input is:
> $ pnginfo test.png
> test.png...
>   Image Width: 411 Image Length: 225
>   Bitdepth (Bits/Sample): 8
>   Channels (Samples/Pixel): 1
>   Pixel depth (Pixel Depth): 8
>   Colour Type (Photometric Interpretation): PALETTED COLOUR with alpha (18 
> colours, 17 transparent) 
>   Image filter: Single row per byte filter 
>   Interlacing: No interlacing 
>   Compression Scheme: Deflate method 8, 32k window
>   Resolution: 0, 0 (unit unknown)
>   FillOrder: msb-to-lsb
>   Byte Order: Network (Big Endian)
>   Number of text strings: 0 of 0



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

[jira] [Commented] (FOP-2539) Apache PDF issue with Symbol.ttf

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2539:
--

I don't think that the user refers to the Base14 Symbol font, no re-mapping is 
required there. This is just a special "feature" of the Windows Symbol font 
which requires this non-standard behavior, when using characters in a Unicode 
range which actually aren't contained in the font.

> Apache PDF issue with Symbol.ttf
> 
>
> Key: FOP-2539
> URL: https://issues.apache.org/jira/browse/FOP-2539
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 1.0
> Environment: Windox, unix
>Reporter: Sushmitha
>
> I have Symbol.ttf, configured the same in config file. Symbol font is not 
> applying properly.
> Please find the below details
> FOP version - 1.0
> OS - Unix, Windows
> XSL-FO desc:
> 
> Abcdefgh α β γ
> 
> Result - the charcters are not displaying properly and they are not human 
> readable format
> fop.xconf:-
> 
> 
> 
> 
> 
> 
> 
> 
> 



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

[jira] [Commented] (FOP-2539) Apache PDF issue with Symbol.ttf

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2539:
--

The release tag for version 1.0 has revision 1141997, 1.1 has 1398854. So 
Wingdings/Symbol font support was present in 1.0 release, but not anymore in 
1.1.

> Apache PDF issue with Symbol.ttf
> 
>
> Key: FOP-2539
> URL: https://issues.apache.org/jira/browse/FOP-2539
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 1.0
> Environment: Windox, unix
>Reporter: Sushmitha
> Attachments: symbol_test.fo, symbol_test_2.fo
>
>
> I have Symbol.ttf, configured the same in config file. Symbol font is not 
> applying properly.
> Please find the below details
> FOP version - 1.0
> OS - Unix, Windows
> XSL-FO desc:
> 
> Abcdefgh α β γ
> 
> Result - the charcters are not displaying properly and they are not human 
> readable format
> fop.xconf:-
> 
> 
> 
> 
> 
> 
> 
> 
> 



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

[jira] [Commented] (FOP-2539) Apache PDF issue with Symbol.ttf

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher commented on FOP-2539:
--

I had a quick look at this a while ago. Support for Symbol (or other 
Symbol-Windows fonts like Wingdings etc.) was originally added by Jeremias in

http://svn.apache.org/viewvc?view=revision=891181

Glenn then remove it in

http://svn.apache.org/viewvc?view=revision=1328579

See also:
https://bz.apache.org/bugzilla/show_bug.cgi?id=50492#c7

The code fragment, Glenn had commented, was then re-introduced by:
http://svn.apache.org/viewvc?view=revision=1514076 (see OpenFont.java)

see also:
https://issues.apache.org/jira/browse/FOP-2252

But the code fragment is in the wrong place, at least for making it work again 
for Symbol/Wingdings.

If I remember correctly the characters of the Symbol/Wingdings font can be 
accessed via the code points in the private use area. So instead of using "a" 
you need to use 
<

[jira] [Updated] (FOP-2528) [PATCH] Re-add css baseline-shift support for SVGs

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2528:
-
Attachment: fop_2528_testcase.svg

> [PATCH] Re-add css baseline-shift support for SVGs
> --
>
> Key: FOP-2528
> URL: https://issues.apache.org/jira/browse/FOP-2528
> Project: FOP
>  Issue Type: Improvement
>  Components: image/svg
>    Reporter: Matthias Reischenbacher
> Attachments: fop_2528.patch, fop_2528_testcase.svg
>
>
> When FOP handles text rendering for SVG output, baseline-shift doesn't work. 
> Attaching a patch which fixes that. Please review, I'm not a font expert.



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

[jira] [Created] (FOP-2529) [PATCH] Avoid character remapping if font contains the same character multiple times

[Matthias Reischenbacher (JIRA)]

Matthias Reischenbacher created FOP-2529:


 Summary: [PATCH] Avoid character remapping if font contains the 
same character multiple times
 Key: FOP-2529
 URL: https://issues.apache.org/jira/browse/FOP-2529
 Project: FOP
  Issue Type: Improvement
  Components: font/opentype
Reporter: Matthias Reischenbacher


When using font Meiryo for japanese PDF output, some japanese characters where 
remapped, e.g. 青 (decimal unicode: 38738) was remapped to ⻘ (decimal unicode: 
11992). My patch contains a changed MultiByteFont.findCharacterFromGlyphIndex() 
method that tries to preserve the original character, if possible, but falls 
back to the current behavior if not.

Preserving the original characters is important for a more predictable search 
behavior in PDF viewers. Since the characters were remapped, searching for the 
original character didn't show any results.



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

[jira] [Created] (FOP-2528) [PATCH] Re-add css baseline-shift support in SVG output

[Matthias Reischenbacher (JIRA)]

Matthias Reischenbacher created FOP-2528:


 Summary: [PATCH] Re-add css baseline-shift support in SVG output
 Key: FOP-2528
 URL: https://issues.apache.org/jira/browse/FOP-2528
 Project: FOP
  Issue Type: Improvement
  Components: image/svg
Reporter: Matthias Reischenbacher


When FOP handles text rendering for SVG output, baseline-shift doesn't work. 
Attaching a patch which fixes that. Please review, I'm not a font expert.



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

[jira] [Updated] (FOP-2529) [PATCH] Avoid character remapping if font contains the same character multiple times

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2529:
-
Attachment: fop_2529.patch

> [PATCH] Avoid character remapping if font contains the same character 
> multiple times
> 
>
> Key: FOP-2529
> URL: https://issues.apache.org/jira/browse/FOP-2529
> Project: FOP
>  Issue Type: Improvement
>  Components: font/opentype
>    Reporter: Matthias Reischenbacher
> Attachments: fop_2529.patch
>
>
> When using font Meiryo for japanese PDF output, some japanese characters 
> where remapped, e.g. 青 (decimal unicode: 38738) was remapped to ⻘ (decimal 
> unicode: 11992). My patch contains a changed 
> MultiByteFont.findCharacterFromGlyphIndex() method that tries to preserve the 
> original character, if possible, but falls back to the current behavior if 
> not.
> Preserving the original characters is important for a more predictable search 
> behavior in PDF viewers. Since the characters were remapped, searching for 
> the original character didn't show any results.



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

[jira] [Updated] (FOP-2528) [PATCH] Re-add css baseline-shift support in SVG output

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2528:
-
Attachment: fop_2528.patch

> [PATCH] Re-add css baseline-shift support in SVG output
> ---
>
> Key: FOP-2528
> URL: https://issues.apache.org/jira/browse/FOP-2528
> Project: FOP
>  Issue Type: Improvement
>  Components: image/svg
>    Reporter: Matthias Reischenbacher
> Attachments: fop_2528.patch
>
>
> When FOP handles text rendering for SVG output, baseline-shift doesn't work. 
> Attaching a patch which fixes that. Please review, I'm not a font expert.



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

[jira] [Updated] (FOP-2528) [PATCH] Re-add css baseline-shift support for SVGs

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher updated FOP-2528:
-
Summary: [PATCH] Re-add css baseline-shift support for SVGs  (was: [PATCH] 
Re-add css baseline-shift support in SVG output)

> [PATCH] Re-add css baseline-shift support for SVGs
> --
>
> Key: FOP-2528
> URL: https://issues.apache.org/jira/browse/FOP-2528
> Project: FOP
>  Issue Type: Improvement
>  Components: image/svg
>    Reporter: Matthias Reischenbacher
> Attachments: fop_2528.patch
>
>
> When FOP handles text rendering for SVG output, baseline-shift doesn't work. 
> Attaching a patch which fixes that. Please review, I'm not a font expert.



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

[jira] [Resolved] (FOP-2530) Fix performance regression in MultiByteFont.findGlyphIndex

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher resolved FOP-2530.
--
Resolution: Fixed

Fixed in http://svn.apache.org/viewvc?view=revision=1705133

> Fix performance regression in MultiByteFont.findGlyphIndex
> --
>
> Key: FOP-2530
> URL: https://issues.apache.org/jira/browse/FOP-2530
> Project: FOP
>  Issue Type: Bug
>  Components: font/opentype
>    Reporter: Matthias Reischenbacher
>
> As suggested here:
> http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/201508.mbox/%3C1439303811674-42749.post%40n5.nabble.com%3E
> by
> dvineshku...@gmail.com
> the MultiByteFont.findGlyphIndex method contains a performance regression.



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

[jira] [Created] (FOP-2530) Fix performance regression in MultiByteFont.findGlyphIndex

[Matthias Reischenbacher (JIRA)]

Matthias Reischenbacher created FOP-2530:


 Summary: Fix performance regression in MultiByteFont.findGlyphIndex
 Key: FOP-2530
 URL: https://issues.apache.org/jira/browse/FOP-2530
 Project: FOP
  Issue Type: Bug
  Components: font/opentype
Reporter: Matthias Reischenbacher


As suggested here:
http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/201508.mbox/%3C1439303811674-42749.post%40n5.nabble.com%3E

by
dvineshku...@gmail.com

the MultiByteFont.findGlyphIndex method contains a performance regression.



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

Re: SingleByteFont Patch

[Matthias Reischenbacher]

Hi Robert,

interesting, thanks for the insight! I'll do a bit more local testing
and commit a fix.
If I interpret the code correctly, the bounding boxes are only set when
the FontCache is filled, so the performance impact wouldn't matter too
much I suppose. I'll leave a TODO mark in the code, in case anybody
wants to continue to improve this.

Best regards,
Matthias

On 06.08.2015 11:54, Robert Meyer wrote:
 Hi,
 
 I have had dealings with this when I was implementing open-type font
 support as that and Type-1 fonts share similar CharString data.
 Initially I thought the bounding box was a necessary part of getting the
 font to work and as such put forward two patches to FontBox. The first
 fixed their CharStringRenderer which renders each character and returns
 the width:
 
 https://issues.apache.org/jira/browse/PDFBOX-1505
 
 Once that was approved, I put forward a second patch which calculated an
 accurate bounding box for the given character using the same renderer:
 
 https://issues.apache.org/jira/browse/PDFBOX-1645
 
 Unfortunately doing this takes a fair amount of processing power and
 after reading some of their concerns, while also realising that in the
 end I didn't need the bounding box, I gave up on my attempt and the
 issue was closed. From my testing it was certainly possible to get very
 accurate bounding boxes for Type 1 font missing metrics. Whether it
 would be worth the effort implementing this is doubtful though
 considering firstly the fact that we lack much of the infrastructure to
 implement this, but more importantly having a detrimental impact upon
 performance for these limited cases.
 
 If Jeremias's approximation is anywhere near accurate I'd certainly
 suggest giving that a go.
 
 Robert
 
 Date: Thu, 6 Aug 2015 09:42:12 -0300
 From: matthias8...@gmx.at
 To: fop-dev@xmlgraphics.apache.org
 Subject: Re: SingleByteFont Patch

 Hi Team,

 the same issue described below, came up today on my side. I did a debug
 session and what I have found out so far is, that this only happens for
 Type1 fonts, that don't have a AFM file. The PFM file doesn't contain
 the char metrics so the bounding boxes can't be initialized.
 When transcoding SVGs to PDF, the code seems to rely on those bounding
 boxes (see FOPGVTGlyphVector), so I'm wondering what a correct fix would
 be. The PFMFile class contains a getFontBBox method, which, as its
 JavaDoc says, returns an approximation of the bounding box. I guess
 returning the approximation is better than nothing, so what I've come up
 so far code-wise is:

 returnFont.setLastChar(pfm.getLastChar());
 for (short i = pfm.getFirstChar(); i = pfm.getLastChar(); i++) {
 int cw = pfm.getCharWidth(i);
 singleFont.setWidth(i, cw);
 // start of my code change
 int[] bbox = pfm.getFontBBox();
 singleFont.setBoundingBox(i, new Rectangle(bbox[0], bbox[1], cw,
 bbox[3]));
 // end of my code change
 }

 Basically I'm using the approximation plus the current char width to
 build a rectangle.

 Any thoughts? Or ideas for a better fix?

 Thanks  Best regards,
 Matthias

 On 01.07.2014 08:43, Pascal Sancho wrote:
  Hi,
  can you file in entries in Jira, please?
  see our HowTo [1] submitting patches.
 
  [1] http://xmlgraphics.apache.org/fop/dev/#patches
 
  2014-07-01 12:36 GMT+02:00 Kai Hofmann powers...@web.de:
 
  Dear all,
 
  looks like there is another bug based on the before mentioned problem:
 
  FOPGVTGlyphVector:
 
  private void buildBoundingBoxes() {
  boundingBoxes = new Rectangle2D[glyphs.length];
  for (int i = 0; i  glyphs.length; i++) {
  Rectangle bbox = fontMetrics.getBoundingBox(glyphs[i], fontSize);
  boundingBoxes[i] = new Rectangle2D.Float(bbox.x / 100f,
 -(bbox.y + bbox.height) / 100f,
  bbox.width / 100f, bbox.height / 100f);
  }
  }
 
 
  Here the result of the patched getBoundingBox seems to be used
 without a null pointer check. Please keep attention on getBoundingBox
 which explizitly returns null 
  Looks like it would help to have complete javadocs which describe
 the possible return values to avoid such mistakes.
 
 
  Gesendet: Dienstag, 01. Juli 2014 um 10:52 Uhr
  Von: Kai Hofmann powers...@web.de
  An: fop-us...@xmlgraphics.apache.org
  Betreff: SingleByteFont Patch
  Dear all,
 
  I found a small bug in SingleByteFont - please see attached patch -
 in getBoundingBox:
 
  if (idx = 0  idx  boundingBoxes.length)
 
  might result in a null pointer exception, when getBoundingBox is
 called before setBoudning box.
  So repleace with:
 
  if (boundingBoxes != null  idx = 0  idx  boundingBoxes.length)
 
 

Re: SingleByteFont Patch

[Matthias Reischenbacher]

Hi Team,

the same issue described below, came up today on my side. I did a debug
session and what I have found out so far is, that this only happens for
Type1 fonts, that don't have a AFM file. The PFM file doesn't contain
the char metrics so the bounding boxes can't be initialized.
When transcoding SVGs to PDF, the code seems to rely on those bounding
boxes (see FOPGVTGlyphVector), so I'm wondering what a correct fix would
be. The PFMFile class contains a getFontBBox method, which, as its
JavaDoc says, returns an approximation of the bounding box. I guess
returning the approximation is better than nothing, so what I've come up
so far code-wise is:

returnFont.setLastChar(pfm.getLastChar());
for (short i = pfm.getFirstChar(); i = pfm.getLastChar(); i++) {
int cw = pfm.getCharWidth(i);
singleFont.setWidth(i, cw);
// start of my code change
int[] bbox = pfm.getFontBBox();
singleFont.setBoundingBox(i, new Rectangle(bbox[0], bbox[1], cw,
bbox[3]));
// end of my code change
}

Basically I'm using the approximation plus the current char width to
build a rectangle.

Any thoughts? Or ideas for a better fix?

Thanks  Best regards,
Matthias

On 01.07.2014 08:43, Pascal Sancho wrote:
 Hi,
 can you file in entries in Jira, please?
 see our HowTo [1] submitting patches.
 
 [1] http://xmlgraphics.apache.org/fop/dev/#patches
 
 2014-07-01 12:36 GMT+02:00 Kai Hofmann powers...@web.de:

 Dear all,

 looks like there is another bug based on the before mentioned problem:

 FOPGVTGlyphVector:

private void buildBoundingBoxes() {
 boundingBoxes = new Rectangle2D[glyphs.length];
 for (int i = 0; i  glyphs.length; i++) {
 Rectangle bbox = fontMetrics.getBoundingBox(glyphs[i], fontSize);
 boundingBoxes[i] = new Rectangle2D.Float(bbox.x / 100f, 
 -(bbox.y + bbox.height) / 100f,
 bbox.width / 100f, bbox.height / 100f);
 }
 }


 Here the result of the patched getBoundingBox seems to be used without a 
 null pointer check. Please keep attention on getBoundingBox which explizitly 
 returns null 
 Looks like it would help to have complete javadocs which describe the 
 possible return values to avoid such mistakes.


 Gesendet: Dienstag, 01. Juli 2014 um 10:52 Uhr
 Von: Kai Hofmann powers...@web.de
 An: fop-us...@xmlgraphics.apache.org
 Betreff: SingleByteFont Patch
 Dear all,

 I found a small bug in SingleByteFont - please see attached patch - in 
 getBoundingBox:

 if (idx = 0  idx  boundingBoxes.length)

 might result in a null pointer exception, when getBoundingBox is called 
 before setBoudning box.
 So repleace with:

 if (boundingBoxes != null  idx = 0  idx  boundingBoxes.length)
 
 

Re: [VOTE] Merge Temp_PCLSoftFont branch with trunk

[Matthias Reischenbacher]

+1

On 04.08.2015 12:33, Robert Meyer wrote:
 Hi All,
 
 This is a vote to merge the temporary branch for adding PCL soft font
 support to FOP trunk.
 
 What this allows for are TrueType fonts to be converted into a PCL
 native font format. This moves FOP away from using AWT and rasterized
 characters allowing for PCL output to potentially be generated over a
 cloud, better rendering quality and smaller documents. Other font
 formats will still be rasterized but TrueType will now default to being
 converted for PCL output.
 
 If you want to give it a try please do. The branch can be found here:
 
 http://svn.eu.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_PCLSoftFonts
 https://svn.eu.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_PCLSoftFonts
 
 This vote wll last 6 days (as I'm unavailable this weekend) and will
 conclude next Monday.
 
 Here is my +1.
 
 Thanks,
 
 Robert

Re: blank pages and conditional-page-master-reference page-position=last

[Matthias Reischenbacher]

Hi Carlos,

that's funny, the exact same problem was reported by one of my clients 
today, so I had a closer look and created 
https://issues.apache.org/jira/browse/FOP-2498


It seems that this was caused by the changes for 
https://issues.apache.org/jira/browse/FOP-1976

I'll commit a fix a bit later.

BR,
Matthias

On 13.07.2015 04:23, Carlos Villegas wrote:
When a blank page is generated because the page-sequence specified 
force-page-count, does this page also match the page-position=last 
condition?
It seems in some old versions of FOP (1.0?) this was not the case, 
page-position=last didn't match the padding pages.
We were actually counting on that behavior using 
conditional-page-master-reference, but it seems the current version 
doesn't work that way anymore.
Actually we were getting some unreliable output, when the last page 
(before the blank page) is full, it didn't match page-position=last, 
but when there was some space left it was matching. I was going to 
report that as a bug, but then I tested versions 1.1 and 2.0 and they 
work differently.
It seems that in the current version of FOP a generated blank page 
also matches page-position=last.
We were trying to generate a End of Section message on the footer of 
the last page with content using a special master matching 
page-position=last.
But this doesn't work if the last page is a generated blank page, 
which matches a different master in our case.


So, what's the correct  behavior: is a generated blank page at end of 
page sequence also the last page?
If that's the case, then there's no condition that matches the last 
page with content, is this right?


Thanks,
Carlos

[jira] [Resolved] (FOP-2498) Fix last page master usage with force-page-count=end-on-even/-odd

[Matthias Reischenbacher (JIRA)]

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

Matthias Reischenbacher resolved FOP-2498.
--
Resolution: Fixed

Implemented in rev http://svn.apache.org/viewvc?view=revisionrevision=1690781

 Fix last page master usage with force-page-count=end-on-even/-odd
 ---

 Key: FOP-2498
 URL: https://issues.apache.org/jira/browse/FOP-2498
 Project: FOP
  Issue Type: Bug
  Components: layout/page
Reporter: Matthias Reischenbacher

 The last page master isn't applied correctly when the page sequence uses a 
 force-page-count property with end-on-even or end-on-odd value.



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