[jira] [Created] (FOP-2899) Setting a background-color let border vanish
Svante Schubert created FOP-2899: Summary: Setting a background-color let border vanish Key: FOP-2899 URL: https://issues.apache.org/jira/browse/FOP-2899 Project: FOP Issue Type: Bug Components: fo/block Affects Versions: 2.4 Reporter: Svante Schubert Attachments: UBL-Invoice-2.0-Example_backgroundColor.fo, UBL-Invoice-2.0-Example_backgroundColor.pdf, UBL-Invoice-2.0-Example_backgroundColor_indent.fo, UBL-Invoice-2.0-Example_noBackground.fo, UBL-Invoice-2.0-Example_noBackground.pdf, UBL-Invoice-2.0-Example_noBackground_indent.fo As soon a background-color is being added to cells the cell border is vanishing as it seems to use the same color as the background. I have attached two versions of a document, one with and the other without background colour as PDF and FO (indent and without indent). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (FOP-1802) [PATCH] NativeTextHandler ignores AWT Font AffineTransform
[ https://issues.apache.org/jira/browse/FOP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-1802. --- Resolution: Cannot Reproduce > [PATCH] NativeTextHandler ignores AWT Font AffineTransform > -- > > Key: FOP-1802 > URL: https://issues.apache.org/jira/browse/FOP-1802 > Project: FOP > Issue Type: Bug > Components: renderer/ps >Affects Versions: trunk > Environment: Operating System: All > Platform: PC >Reporter: Julien Aymé > Attachments: NativeTextHandler.diff, NativeTextHandler.diff > > > The NativeTextHandler class ignores the AffineTransform of the AWT Font, and > the generated Postscript document is incorrect. > I suggest that the NativeTextHandler adds a transformation matrix > corresponding to the font's AffineTransform if it is not the Identity matrix. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-1802) [PATCH] NativeTextHandler ignores AWT Font AffineTransform
[ https://issues.apache.org/jira/browse/FOP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010528#comment-17010528 ] Chris Bowditch commented on FOP-1802: - Thanks for the patch, but I have no means to replicate the issue. Also, we no longer use AWT Fonts for rendering Postscript. Instead we try to identify a font registered in the fop.xconf file with same name, style, etc. Since this is now 10 years old, I'm going to close it, but if you can provide a test case for the latest FOP version please do re-open > [PATCH] NativeTextHandler ignores AWT Font AffineTransform > -- > > Key: FOP-1802 > URL: https://issues.apache.org/jira/browse/FOP-1802 > Project: FOP > Issue Type: Bug > Components: renderer/ps >Affects Versions: trunk > Environment: Operating System: All > Platform: PC >Reporter: Julien Aymé > Attachments: NativeTextHandler.diff, NativeTextHandler.diff > > > The NativeTextHandler class ignores the AffineTransform of the AWT Font, and > the generated Postscript document is incorrect. > I suggest that the NativeTextHandler adds a transformation matrix > corresponding to the font's AffineTransform if it is not the Identity matrix. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FOP-1581) Improve border painting in collapsing border model
[ https://issues.apache.org/jira/browse/FOP-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-1581: Attachment: (was: az-900-Exam-Dumps-2019.pdf) > Improve border painting in collapsing border model > -- > > Key: FOP-1581 > URL: https://issues.apache.org/jira/browse/FOP-1581 > Project: FOP > Issue Type: Improvement > Components: unqualified >Affects Versions: trunk > Environment: Operating System: All > Platform: All >Reporter: Vincent Hennebert > Attachments: border-painting.fo > > > See attached file: the corners adjacent to the cell without borders aren't > fully painted, which makes the result not very nice. > It would be a nice to have if the borders were fully painted, like in the > separate border model (second table). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-1690) int overflow with large font size values
[ https://issues.apache.org/jira/browse/FOP-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010525#comment-17010525 ] Chris Bowditch commented on FOP-1690: - Testing this in the latest trunk, this bug now appears to be resolved as I get the expected output without any error > int overflow with large font size values > > > Key: FOP-1690 > URL: https://issues.apache.org/jira/browse/FOP-1690 > Project: FOP > Issue Type: Bug > Components: font/unqualified >Affects Versions: trunk > Environment: Operating System: All > Platform: All >Reporter: Jeremias Maerki > Attachments: svg-text.fo > > > A rather nasty bug: In XSL-FO, we usually have font sizes under 11'000 points. > No problem. Switch to SVG and define a viewBox with relatively high values and > you can quickly end up with a font size of 11'000 (units not points). It > happened to me when I ran an SVG that was produced by the SVG document handler > in the FOP sandbox. That one just sets up FOP's internal millipoint coordinate > system in SVG. No SVG editor/viewer has a problem with that. > So, the problem is, for example, the generated Helvetica class' getWidth(int > i, > int size) method which returns an int. Multiply a number in the 1000 range > with > the font size that has been multiplied by 1000 (pt -> mpt conversion for > normal > FO). > 950 * (1000 * 11000) = 1045000 (0x26EDE5880) > That result is bigger than a 32-bit int. > For comparison, the usual case in FO: > 950 * (1000 * 11) = 1045 (0x9F7450) > I've locally added long variants of the problematic methods (getWidth() -> > getWidthLong()) to see if this really solves the problem and it does indeed. > Just replacing int with long everywhere is not a good idea because of > backwards-compatibility. We know that some people are using these classes > outside of FOP. To me, the additional long variants look like the cleanest > solution, but maybe someone has a better solution. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (FOP-1690) int overflow with large font size values
[ https://issues.apache.org/jira/browse/FOP-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-1690. --- Resolution: Cannot Reproduce > int overflow with large font size values > > > Key: FOP-1690 > URL: https://issues.apache.org/jira/browse/FOP-1690 > Project: FOP > Issue Type: Bug > Components: font/unqualified >Affects Versions: trunk > Environment: Operating System: All > Platform: All >Reporter: Jeremias Maerki > Attachments: svg-text.fo > > > A rather nasty bug: In XSL-FO, we usually have font sizes under 11'000 points. > No problem. Switch to SVG and define a viewBox with relatively high values and > you can quickly end up with a font size of 11'000 (units not points). It > happened to me when I ran an SVG that was produced by the SVG document handler > in the FOP sandbox. That one just sets up FOP's internal millipoint coordinate > system in SVG. No SVG editor/viewer has a problem with that. > So, the problem is, for example, the generated Helvetica class' getWidth(int > i, > int size) method which returns an int. Multiply a number in the 1000 range > with > the font size that has been multiplied by 1000 (pt -> mpt conversion for > normal > FO). > 950 * (1000 * 11000) = 1045000 (0x26EDE5880) > That result is bigger than a 32-bit int. > For comparison, the usual case in FO: > 950 * (1000 * 11) = 1045 (0x9F7450) > I've locally added long variants of the problematic methods (getWidth() -> > getWidthLong()) to see if this really solves the problem and it does indeed. > Just replacing int with long everywhere is not a good idea because of > backwards-compatibility. We know that some people are using these classes > outside of FOP. To me, the additional long variants look like the cleanest > solution, but maybe someone has a better solution. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FOP-1690) int overflow with large font size values
[ https://issues.apache.org/jira/browse/FOP-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-1690: Attachment: (was: h13-623-Exam-Dumps-2019.pdf) > int overflow with large font size values > > > Key: FOP-1690 > URL: https://issues.apache.org/jira/browse/FOP-1690 > Project: FOP > Issue Type: Bug > Components: font/unqualified >Affects Versions: trunk > Environment: Operating System: All > Platform: All >Reporter: Jeremias Maerki > Attachments: svg-text.fo > > > A rather nasty bug: In XSL-FO, we usually have font sizes under 11'000 points. > No problem. Switch to SVG and define a viewBox with relatively high values and > you can quickly end up with a font size of 11'000 (units not points). It > happened to me when I ran an SVG that was produced by the SVG document handler > in the FOP sandbox. That one just sets up FOP's internal millipoint coordinate > system in SVG. No SVG editor/viewer has a problem with that. > So, the problem is, for example, the generated Helvetica class' getWidth(int > i, > int size) method which returns an int. Multiply a number in the 1000 range > with > the font size that has been multiplied by 1000 (pt -> mpt conversion for > normal > FO). > 950 * (1000 * 11000) = 1045000 (0x26EDE5880) > That result is bigger than a 32-bit int. > For comparison, the usual case in FO: > 950 * (1000 * 11) = 1045 (0x9F7450) > I've locally added long variants of the problematic methods (getWidth() -> > getWidthLong()) to see if this really solves the problem and it does indeed. > Just replacing int with long everywhere is not a good idea because of > backwards-compatibility. We know that some people are using these classes > outside of FOP. To me, the additional long variants look like the cleanest > solution, but maybe someone has a better solution. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FOP-1690) int overflow with large font size values
[ https://issues.apache.org/jira/browse/FOP-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-1690: Attachment: (was: h13-623-Exam-Dumps-2019.pdf) > int overflow with large font size values > > > Key: FOP-1690 > URL: https://issues.apache.org/jira/browse/FOP-1690 > Project: FOP > Issue Type: Bug > Components: font/unqualified >Affects Versions: trunk > Environment: Operating System: All > Platform: All >Reporter: Jeremias Maerki > Attachments: svg-text.fo > > > A rather nasty bug: In XSL-FO, we usually have font sizes under 11'000 points. > No problem. Switch to SVG and define a viewBox with relatively high values and > you can quickly end up with a font size of 11'000 (units not points). It > happened to me when I ran an SVG that was produced by the SVG document handler > in the FOP sandbox. That one just sets up FOP's internal millipoint coordinate > system in SVG. No SVG editor/viewer has a problem with that. > So, the problem is, for example, the generated Helvetica class' getWidth(int > i, > int size) method which returns an int. Multiply a number in the 1000 range > with > the font size that has been multiplied by 1000 (pt -> mpt conversion for > normal > FO). > 950 * (1000 * 11000) = 1045000 (0x26EDE5880) > That result is bigger than a 32-bit int. > For comparison, the usual case in FO: > 950 * (1000 * 11) = 1045 (0x9F7450) > I've locally added long variants of the problematic methods (getWidth() -> > getWidthLong()) to see if this really solves the problem and it does indeed. > Just replacing int with long everywhere is not a good idea because of > backwards-compatibility. We know that some people are using these classes > outside of FOP. To me, the additional long variants look like the cleanest > solution, but maybe someone has a better solution. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FOP-1802) [PATCH] NativeTextHandler ignores AWT Font AffineTransform
[ https://issues.apache.org/jira/browse/FOP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-1802: Attachment: (was: mb2-717-Exam-Dumps-NewYear-2019.pdf) > [PATCH] NativeTextHandler ignores AWT Font AffineTransform > -- > > Key: FOP-1802 > URL: https://issues.apache.org/jira/browse/FOP-1802 > Project: FOP > Issue Type: Bug > Components: renderer/ps >Affects Versions: trunk > Environment: Operating System: All > Platform: PC >Reporter: Julien Aymé > Attachments: NativeTextHandler.diff, NativeTextHandler.diff > > > The NativeTextHandler class ignores the AffineTransform of the AWT Font, and > the generated Postscript document is incorrect. > I suggest that the NativeTextHandler adds a transformation matrix > corresponding to the font's AffineTransform if it is not the Identity matrix. -- This message was sent by Atlassian Jira (v8.3.4#803005)
