[jira] [Commented] (FOP-2536) [PATCH] Varying table border thickness in PDF output
[ 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)
[jira] [Assigned] (FOP-2845) File leak to background-image
[
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
[ 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
[
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
[ 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
[ 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
[
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
[ 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
[ 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
[ 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
[
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
[ 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)
[jira] [Commented] (FOP-2704) Google fonts Roboto font (updated 2017) UnsupportedOperationException: coverage set class table not yet supported
[
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)
[jira] [Resolved] (FOP-2818) PDF color spaces are lost when embedding PDF image
[ 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
[ 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
[ 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
[ 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
[ 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 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
[ 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
[ 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)
[jira] [Resolved] (FOP-2572) [PATCH] Non-breaking space within a Text node causes an Exception.
[
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.
[
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
[
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
[ 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
[ 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
[ 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
[ 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 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)
[jira] [Commented] (FOP-2710) SVG Gradient missing
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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 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)
[jira] [Resolved] (FOP-2570) [PATCH] Misplaced border of spanned table cells in RTL WM context
[ 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)
[jira] [Comment Edited] (FOP-2536) [PATCH] Varying table border thickness in PDF output
[ 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
[ 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
[
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
[ 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
[ 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
[
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
[
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
[
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
[ 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
[ 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.
[
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.
[
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.
[
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 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)
[jira] [Updated] (FOP-2564) Ignore ICC profiles added by ImageIO loader
[ 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
[ 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
[ 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)
[jira] [Updated] (FOP-2564) [PATCH] Ignore ICC profiles added by ImageIO loader
[ 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
[ 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
[ 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
[ 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 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)
[jira] [Commented] (FOP-2557) Adobe Reader report corrupt embedded font
[ 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
[ 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
[ 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 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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 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 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
[ 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
[ 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
[ 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
[ 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 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)
[jira] [Resolved] (FOP-2498) Fix last page master usage with force-page-count=end-on-even/-odd
[ 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)
[jira] [Created] (FOP-2498) Fix last page master usage with force-page-count=end-on-even/-odd
Matthias Reischenbacher created FOP-2498: Summary: 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)
[jira] [Resolved] (FOP-2462) Fop PDF Image Plugin broken since rev 1590626
[ https://issues.apache.org/jira/browse/FOP-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Reischenbacher resolved FOP-2462. -- Resolution: Fixed Yes, it is. Thanks a lot for having a second look and fixing it right away! Fop PDF Image Plugin broken since rev 1590626 - Key: FOP-2462 URL: https://issues.apache.org/jira/browse/FOP-2462 Project: FOP Issue Type: Bug Components: image/unqualified Affects Versions: trunk Reporter: Matthias Reischenbacher Attachments: fop-2462-acrobat-error-message.png, fop-2462-external-pdf.pdf, fop-2462-test-case-null-filter.pdf, fop-2462-test-case.pdf, fop-2462-test-case.xml, out-nocomp.pdf, out.pdf Rendering the attached sample fo and pdf file with FOP and the PDF Image Plugin creates a corrupted PDF file since revision 1590626. The generated PDF file can be opened with Adobe Acrobat but when opening the page with the external PDF file an error message is displayed and no content is visible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FOP-2487) Page overflow breaks multi column layout
[ https://issues.apache.org/jira/browse/FOP-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Reischenbacher resolved FOP-2487. -- Resolution: Fixed Fix Version/s: trunk Fixed in http://svn.apache.org/viewvc?view=revisionrevision=1685586 Page overflow breaks multi column layout Key: FOP-2487 URL: https://issues.apache.org/jira/browse/FOP-2487 Project: FOP Issue Type: Bug Components: layout/page Reporter: Matthias Reischenbacher Fix For: trunk Attachments: fop-2487-current-output.pdf, fop-2487-expected-output.pdf, fop-2487-test-case.xml If the content of a page overflows the region body, a two column layout on the next page is broken. The content, which should be on the second column, is rendered on a third page in the left column. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2487) Page overflow breaks multi column layout
[ https://issues.apache.org/jira/browse/FOP-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Reischenbacher updated FOP-2487: - Attachment: fop-2487-test-case.xml fop-2487-expected-output.pdf fop-2487-current-output.pdf Page overflow breaks multi column layout Key: FOP-2487 URL: https://issues.apache.org/jira/browse/FOP-2487 Project: FOP Issue Type: Bug Components: layout/page Reporter: Matthias Reischenbacher Attachments: fop-2487-current-output.pdf, fop-2487-expected-output.pdf, fop-2487-test-case.xml If the content of a page overflows the region body, a two column layout on the next page is broken. The content, which should be on the second column, is rendered on a third page in the left column. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FOP-2487) Page overflow breaks multi column layout
Matthias Reischenbacher created FOP-2487: Summary: Page overflow breaks multi column layout Key: FOP-2487 URL: https://issues.apache.org/jira/browse/FOP-2487 Project: FOP Issue Type: Bug Components: layout/page Reporter: Matthias Reischenbacher If the content of a page overflows the region body, a two column layout on the next page is broken. The content, which should be on the second column, is rendered on a third page in the left column. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2060) adjoining blocks with break-before=page break-after=page cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584022#comment-14584022 ] Matthias Reischenbacher commented on FOP-2060: -- It makes more sense to wait until the refactoring of the LayoutContext handling is done as part of FOP-2469, before continuing to look into this, right? adjoining blocks with break-before=page break-after=page cause extra empty page --- Key: FOP-2060 URL: https://issues.apache.org/jira/browse/FOP-2060 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Luis Bernardo Fix For: trunk Attachments: 2060-empty-block-issue.xml, test.fo, test.pdf This causes five pages instead of four: fo:block fo:blockpage 1/fo:block fo:block break-before=page break-after=pagepage 2/fo:block fo:block break-before=page break-after=pagepage 3/fo:block fo:blockpage 4/fo:block /fo:block The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2462) Fop PDF Image Plugin broken since rev 1590626
[ https://issues.apache.org/jira/browse/FOP-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584030#comment-14584030 ] Matthias Reischenbacher commented on FOP-2462: -- Simon: I'd like to investigate why our PDFs are generated differently. Could you please attach a PDF without compression? Thanks! Fop PDF Image Plugin broken since rev 1590626 - Key: FOP-2462 URL: https://issues.apache.org/jira/browse/FOP-2462 Project: FOP Issue Type: Bug Components: image/unqualified Affects Versions: trunk Reporter: Matthias Reischenbacher Attachments: fop-2462-acrobat-error-message.png, fop-2462-external-pdf.pdf, fop-2462-test-case-null-filter.pdf, fop-2462-test-case.pdf, fop-2462-test-case.xml, out.pdf Rendering the attached sample fo and pdf file with FOP and the PDF Image Plugin creates a corrupted PDF file since revision 1590626. The generated PDF file can be opened with Adobe Acrobat but when opening the page with the external PDF file an error message is displayed and no content is visible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2465) [PATCH] Links to 'last' page aren't working
[ https://issues.apache.org/jira/browse/FOP-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584065#comment-14584065 ] Matthias Reischenbacher commented on FOP-2465: -- Fixed in http://svn.apache.org/viewvc?view=revisionrevision=1685165 -- My first commit, I hope I didn't do anything wrong. [PATCH] Links to 'last' page aren't working --- Key: FOP-2465 URL: https://issues.apache.org/jira/browse/FOP-2465 Project: FOP Issue Type: Bug Components: layout/page Reporter: Matthias Reischenbacher Attachments: fop-2465-link-to-last-page.patch, fop-2465-link-to-last-page.xml If there is a separate page master for the 'last' page and the layout is redone (see PageBreaker.redoLayout) links to content inside the last page don't work. My test case fo file contains a bookmark to a block on the last page. The following warning is displayed when generating PDF output: WARNING: 1 link target could not be fully resolved and now point to the top of the page or is dysfunctional. My Patch tries to fix the ID handling and replaces the old PageViewport instances inside the IDTracker with the one. Please let me know if there is a better way to fix this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FOP-2465) [PATCH] Links to 'last' page aren't working
[ https://issues.apache.org/jira/browse/FOP-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Reischenbacher resolved FOP-2465. -- Resolution: Fixed Fix Version/s: trunk [PATCH] Links to 'last' page aren't working --- Key: FOP-2465 URL: https://issues.apache.org/jira/browse/FOP-2465 Project: FOP Issue Type: Bug Components: layout/page Reporter: Matthias Reischenbacher Fix For: trunk Attachments: fop-2465-link-to-last-page.patch, fop-2465-link-to-last-page.xml If there is a separate page master for the 'last' page and the layout is redone (see PageBreaker.redoLayout) links to content inside the last page don't work. My test case fo file contains a bookmark to a block on the last page. The following warning is displayed when generating PDF output: WARNING: 1 link target could not be fully resolved and now point to the top of the page or is dysfunctional. My Patch tries to fix the ID handling and replaces the old PageViewport instances inside the IDTracker with the one. Please let me know if there is a better way to fix this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2060) adjoining blocks with break-before=page break-after=page cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Reischenbacher updated FOP-2060: - Attachment: 2060-empty-block-issue.xml The attached file produces a 2-page output with the change of this ticket. Previously it was a 3-page-output. Perhaps it would be better to avoid adding the auxiliary positions in the first place, instead of removing them in the AbstractBreaker. Do want me to have a look in this direction, Luis? Or can you? adjoining blocks with break-before=page break-after=page cause extra empty page --- Key: FOP-2060 URL: https://issues.apache.org/jira/browse/FOP-2060 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Luis Bernardo Fix For: trunk Attachments: 2060-empty-block-issue.xml, test.fo, test.pdf This causes five pages instead of four: fo:block fo:blockpage 1/fo:block fo:block break-before=page break-after=pagepage 2/fo:block fo:block break-before=page break-after=pagepage 3/fo:block fo:blockpage 4/fo:block /fo:block The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2060) adjoining blocks with break-before=page break-after=page cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14575232#comment-14575232 ] Matthias Reischenbacher commented on FOP-2060: -- Andreas: I played around with the SUPPRESS_BREAK_BEFORE flag of the LayoutContext in order to avoid the break-before of the third block being processed. I check inside the AbstractBreaker if the last element list terminates with a forced break and if it does, I set the SUPPRESS_BREAK_BEFORE flag to true. What makes me doubt, if this is a valid approach, is that I have to take care that the flag is copied to all the LayoutContexts of the child LMs. What do you think? adjoining blocks with break-before=page break-after=page cause extra empty page --- Key: FOP-2060 URL: https://issues.apache.org/jira/browse/FOP-2060 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Luis Bernardo Fix For: trunk Attachments: 2060-empty-block-issue.xml, test.fo, test.pdf This causes five pages instead of four: fo:block fo:blockpage 1/fo:block fo:block break-before=page break-after=pagepage 2/fo:block fo:block break-before=page break-after=pagepage 3/fo:block fo:blockpage 4/fo:block /fo:block The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (FOP-2060) adjoining blocks with break-before=page break-after=page cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Reischenbacher updated FOP-2060: - Comment: was deleted (was: Hm, could be. But are you sure? Before your change the output was 3 pages. From what I understand about https://www.w3.org/Bugs/Public/show_bug.cgi?id=6276 it clarifies mainly breaks when nesting blocks. I also agree that your test case should produce a 4 page output. But two sibling blocks, like in my case: fo:block break-before=page/fo:block fo:block break-before=page/fo:block Shouldn't that generate two page breaks? Btw: I tested with AntennaHouse and my test cases produced a 3 page output.) adjoining blocks with break-before=page break-after=page cause extra empty page --- Key: FOP-2060 URL: https://issues.apache.org/jira/browse/FOP-2060 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Luis Bernardo Fix For: trunk Attachments: 2060-empty-block-issue.xml, test.fo, test.pdf This causes five pages instead of four: fo:block fo:blockpage 1/fo:block fo:block break-before=page break-after=pagepage 2/fo:block fo:block break-before=page break-after=pagepage 3/fo:block fo:blockpage 4/fo:block /fo:block The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2060) adjoining blocks with break-before=page break-after=page cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14575352#comment-14575352 ] Matthias Reischenbacher commented on FOP-2060: -- Hm, could be. But are you sure? Before your change the output was 3 pages. From what I understand about https://www.w3.org/Bugs/Public/show_bug.cgi?id=6276 it clarifies mainly breaks when nesting blocks. I also agree that your test case should produce a 4 page output. But two sibling blocks, like in my case: fo:block break-before=page/fo:block fo:block break-before=page/fo:block Shouldn't that generate two page breaks? Btw: I tested with AntennaHouse and my test cases produced a 3 page output. adjoining blocks with break-before=page break-after=page cause extra empty page --- Key: FOP-2060 URL: https://issues.apache.org/jira/browse/FOP-2060 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Luis Bernardo Fix For: trunk Attachments: 2060-empty-block-issue.xml, test.fo, test.pdf This causes five pages instead of four: fo:block fo:blockpage 1/fo:block fo:block break-before=page break-after=pagepage 2/fo:block fo:block break-before=page break-after=pagepage 3/fo:block fo:blockpage 4/fo:block /fo:block The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2060) adjoining blocks with break-before=page break-after=page cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14575351#comment-14575351 ] Matthias Reischenbacher commented on FOP-2060: -- Hm, could be. But are you sure? Before your change the output was 3 pages. From what I understand about https://www.w3.org/Bugs/Public/show_bug.cgi?id=6276 it clarifies mainly breaks when nesting blocks. I also agree that your test case should produce a 4 page output. But two sibling blocks, like in my case: fo:block break-before=page/fo:block fo:block break-before=page/fo:block Shouldn't that generate two page breaks? Btw: I tested with AntennaHouse and my test cases produced a 3 page output. adjoining blocks with break-before=page break-after=page cause extra empty page --- Key: FOP-2060 URL: https://issues.apache.org/jira/browse/FOP-2060 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Luis Bernardo Fix For: trunk Attachments: 2060-empty-block-issue.xml, test.fo, test.pdf This causes five pages instead of four: fo:block fo:blockpage 1/fo:block fo:block break-before=page break-after=pagepage 2/fo:block fo:block break-before=page break-after=pagepage 3/fo:block fo:blockpage 4/fo:block /fo:block The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-1488) [PATCH] orphans/widows not respected in some cases
[ https://issues.apache.org/jira/browse/FOP-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14530408#comment-14530408 ] Matthias Reischenbacher commented on FOP-1488: -- Thanks a lot Andreas for updating your patch. I updated my fop code base some weeks ago and had difficulties correctly applying your changes. This patch has been very useful for my clients, the only minor thing which still needs to be addressed, is the line counting when images are used. If there are several images, one after each other, they are all hold together if a high orphans/widows value is used, because each image is counted as one line. If the images are very high, it can easily happen that the images overflow the page. Would it be correct (from a xsl-fo standard's point of view) to handle the line counting for images differently? [PATCH] orphans/widows not respected in some cases -- Key: FOP-1488 URL: https://issues.apache.org/jira/browse/FOP-1488 Project: Fop Issue Type: Bug Components: unqualified Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Andrew McFarland Attachments: FOP-1488-code.patch, FOP-1488-test.patch, b44328.patch, b44328.patch, b44328.patch, b44328.patch, b44328.patch, b44328.patch, b44328.patch, b44328_test.patch, block_orphans_widows.fo, block_orphans_widows.fo, block_orphans_widows.fo, block_orphans_widows.fo, block_orphans_widows.fo, widow.fo When I process the following fo, I get a PDF with a one-line widow at the start of the second page, even though widows for that fo:block is set to 4. ?xml version=1.0 encoding=ISO-8859-1? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=A4 fo:region-body / /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=A4 fo:flow flow-name=xsl-region-body fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:block widows=4 linefeed-treatment=preserve line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line /fo:block /fo:flow /fo:page-sequence /fo:root -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2462) Fop PDF Image Plugin broken since rev 1590626
[ https://issues.apache.org/jira/browse/FOP-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14513979#comment-14513979 ] Matthias Reischenbacher commented on FOP-2462: -- Thanks Simon. What I could see so far is that the page content stream (32 0 obj in your case) is different. Could you please also attach a file without compression (null filter in fop config). Thanks. Fop PDF Image Plugin broken since rev 1590626 - Key: FOP-2462 URL: https://issues.apache.org/jira/browse/FOP-2462 Project: Fop Issue Type: Bug Components: image/unqualified Affects Versions: trunk Reporter: Matthias Reischenbacher Attachments: fop-2462-acrobat-error-message.png, fop-2462-external-pdf.pdf, fop-2462-test-case-null-filter.pdf, fop-2462-test-case.pdf, fop-2462-test-case.xml, out.pdf Rendering the attached sample fo and pdf file with FOP and the PDF Image Plugin creates a corrupted PDF file since revision 1590626. The generated PDF file can be opened with Adobe Acrobat but when opening the page with the external PDF file an error message is displayed and no content is visible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2465) [PATCH] Links to 'last' page aren't working
[ https://issues.apache.org/jira/browse/FOP-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Reischenbacher updated FOP-2465: - Attachment: fop-2465-link-to-last-page.xml Test case [PATCH] Links to 'last' page aren't working --- Key: FOP-2465 URL: https://issues.apache.org/jira/browse/FOP-2465 Project: Fop Issue Type: Bug Components: layout/page Reporter: Matthias Reischenbacher Attachments: fop-2465-link-to-last-page.xml If there is a separate page master for the 'last' page and the layout is redone (see PageBreaker.redoLayout) links to content inside the last page don't work. My test case fo file contains a bookmark to a block on the last page. The following warning is displayed when generating PDF output: WARNING: 1 link target could not be fully resolved and now point to the top of the page or is dysfunctional. My Patch tries to fix the ID handling and replaces the old PageViewport instances inside the IDTracker with the one. Please let me know if there is a better way to fix this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FOP-2465) [PATCH] Links to 'last' page aren't working
Matthias Reischenbacher created FOP-2465: Summary: [PATCH] Links to 'last' page aren't working Key: FOP-2465 URL: https://issues.apache.org/jira/browse/FOP-2465 Project: Fop Issue Type: Bug Components: layout/page Reporter: Matthias Reischenbacher If there is a separate page master for the 'last' page and the layout is redone (see PageBreaker.redoLayout) links to content inside the last page don't work. My test case fo file contains a bookmark to a block on the last page. The following warning is displayed when generating PDF output: WARNING: 1 link target could not be fully resolved and now point to the top of the page or is dysfunctional. My Patch tries to fix the ID handling and replaces the old PageViewport instances inside the IDTracker with the one. Please let me know if there is a better way to fix this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2465) [PATCH] Links to 'last' page aren't working
[ https://issues.apache.org/jira/browse/FOP-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Reischenbacher updated FOP-2465: - Attachment: fop-2465-link-to-last-page.patch Patch [PATCH] Links to 'last' page aren't working --- Key: FOP-2465 URL: https://issues.apache.org/jira/browse/FOP-2465 Project: Fop Issue Type: Bug Components: layout/page Reporter: Matthias Reischenbacher Attachments: fop-2465-link-to-last-page.patch, fop-2465-link-to-last-page.xml If there is a separate page master for the 'last' page and the layout is redone (see PageBreaker.redoLayout) links to content inside the last page don't work. My test case fo file contains a bookmark to a block on the last page. The following warning is displayed when generating PDF output: WARNING: 1 link target could not be fully resolved and now point to the top of the page or is dysfunctional. My Patch tries to fix the ID handling and replaces the old PageViewport instances inside the IDTracker with the one. Please let me know if there is a better way to fix this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
