[jira] [Comment Edited] (FOP-2580) Wrong Position of Thai Glyph in FOP 2.0+ (Binary version)
[ https://issues.apache.org/jira/browse/FOP-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15813819#comment-15813819 ] AEKAPAN TAWEELUER edited comment on FOP-2580 at 1/10/17 4:23 AM: - Thank you for recommended, it work only Garuda and Norasi but have effect with upper(2nd) glyphs of other fonts. you can see in complex-script-disabled.pdf was (Author: mikeii): Thank you for recommended, it work only Garuda and Norasi but have effect with upper(2nd) glyphs of other fonts. you see in with complex-script-disabled.pdf > Wrong Position of Thai Glyph in FOP 2.0+ (Binary version) > - > > Key: FOP-2580 > URL: https://issues.apache.org/jira/browse/FOP-2580 > Project: FOP > Issue Type: Bug > Components: documentation, font/unqualified >Affects Versions: 2.0, 2.1 > Environment: Windows 10 64bit CPU Core I-5 Ram 8G JRE 1.80_73 fop > binary 2.1 >Reporter: AEKAPAN TAWEELUER > Labels: build > Fix For: 1.1 > > Attachments: Norasi.ttf, complex-script-disabled.pdf, > complex-script-enabled.pdf, fop.xconf, leelawad.ttf, log.txt, true.pdf, > wrong.fo, wrong.pdf > > > Glyph of Thai Font have problem when start in new line or have white space in > front of word. > In Example Wrong.pdf you'll see upper and lower glyph shift to the right 1 > character when the base character no have any character before or have white > space before. > "อ ิ" the true is should be "อิ" > "อกี" the true is should be "อีก" > "อ ุ" the true is should be "อุ" > "อบุ" the true is should be "อุบ" > remark : Font Angsana New AngsanaUPC , Leelawadee , Norasi and Tahoma are > most use in Thai font. > I use Windows command line (cmd) to generate pdf file. > example command line > C:\fop-2.1>fop.bat fop -c conf\fop.xconf -fo wrong.fo wrong.pdf -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2580) Wrong Position of Thai Glyph in FOP 2.0+ (Binary version)
[ https://issues.apache.org/jira/browse/FOP-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AEKAPAN TAWEELUER updated FOP-2580: --- Attachment: (was: complex-script-disabled.pdf) > Wrong Position of Thai Glyph in FOP 2.0+ (Binary version) > - > > Key: FOP-2580 > URL: https://issues.apache.org/jira/browse/FOP-2580 > Project: FOP > Issue Type: Bug > Components: documentation, font/unqualified >Affects Versions: 2.0, 2.1 > Environment: Windows 10 64bit CPU Core I-5 Ram 8G JRE 1.80_73 fop > binary 2.1 >Reporter: AEKAPAN TAWEELUER > Labels: build > Fix For: 1.1 > > Attachments: Norasi.ttf, fop.xconf, leelawad.ttf, log.txt, true.pdf, > wrong.fo, wrong.pdf > > > Glyph of Thai Font have problem when start in new line or have white space in > front of word. > In Example Wrong.pdf you'll see upper and lower glyph shift to the right 1 > character when the base character no have any character before or have white > space before. > "อ ิ" the true is should be "อิ" > "อกี" the true is should be "อีก" > "อ ุ" the true is should be "อุ" > "อบุ" the true is should be "อุบ" > remark : Font Angsana New AngsanaUPC , Leelawadee , Norasi and Tahoma are > most use in Thai font. > I use Windows command line (cmd) to generate pdf file. > example command line > C:\fop-2.1>fop.bat fop -c conf\fop.xconf -fo wrong.fo wrong.pdf -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2580) Wrong Position of Thai Glyph in FOP 2.0+ (Binary version)
[ https://issues.apache.org/jira/browse/FOP-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AEKAPAN TAWEELUER updated FOP-2580: --- Attachment: (was: complex-script-enabled.pdf) > Wrong Position of Thai Glyph in FOP 2.0+ (Binary version) > - > > Key: FOP-2580 > URL: https://issues.apache.org/jira/browse/FOP-2580 > Project: FOP > Issue Type: Bug > Components: documentation, font/unqualified >Affects Versions: 2.0, 2.1 > Environment: Windows 10 64bit CPU Core I-5 Ram 8G JRE 1.80_73 fop > binary 2.1 >Reporter: AEKAPAN TAWEELUER > Labels: build > Fix For: 1.1 > > Attachments: Norasi.ttf, fop.xconf, leelawad.ttf, log.txt, true.pdf, > wrong.fo, wrong.pdf > > > Glyph of Thai Font have problem when start in new line or have white space in > front of word. > In Example Wrong.pdf you'll see upper and lower glyph shift to the right 1 > character when the base character no have any character before or have white > space before. > "อ ิ" the true is should be "อิ" > "อกี" the true is should be "อีก" > "อ ุ" the true is should be "อุ" > "อบุ" the true is should be "อุบ" > remark : Font Angsana New AngsanaUPC , Leelawadee , Norasi and Tahoma are > most use in Thai font. > I use Windows command line (cmd) to generate pdf file. > example command line > C:\fop-2.1>fop.bat fop -c conf\fop.xconf -fo wrong.fo wrong.pdf -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2580) Wrong Position of Thai Glyph in FOP 2.0+ (Binary version)
[ https://issues.apache.org/jira/browse/FOP-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AEKAPAN TAWEELUER updated FOP-2580: --- Attachment: complex-script-enabled.pdf > Wrong Position of Thai Glyph in FOP 2.0+ (Binary version) > - > > Key: FOP-2580 > URL: https://issues.apache.org/jira/browse/FOP-2580 > Project: FOP > Issue Type: Bug > Components: documentation, font/unqualified >Affects Versions: 2.0, 2.1 > Environment: Windows 10 64bit CPU Core I-5 Ram 8G JRE 1.80_73 fop > binary 2.1 >Reporter: AEKAPAN TAWEELUER > Labels: build > Fix For: 1.1 > > Attachments: Norasi.ttf, complex-script-disabled.pdf, > complex-script-enabled.pdf, fop.xconf, leelawad.ttf, log.txt, true.pdf, > wrong.fo, wrong.pdf > > > Glyph of Thai Font have problem when start in new line or have white space in > front of word. > In Example Wrong.pdf you'll see upper and lower glyph shift to the right 1 > character when the base character no have any character before or have white > space before. > "อ ิ" the true is should be "อิ" > "อกี" the true is should be "อีก" > "อ ุ" the true is should be "อุ" > "อบุ" the true is should be "อุบ" > remark : Font Angsana New AngsanaUPC , Leelawadee , Norasi and Tahoma are > most use in Thai font. > I use Windows command line (cmd) to generate pdf file. > example command line > C:\fop-2.1>fop.bat fop -c conf\fop.xconf -fo wrong.fo wrong.pdf -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2580) Wrong Position of Thai Glyph in FOP 2.0+ (Binary version)
[ https://issues.apache.org/jira/browse/FOP-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AEKAPAN TAWEELUER updated FOP-2580: --- Attachment: complex-script-disabled.pdf > Wrong Position of Thai Glyph in FOP 2.0+ (Binary version) > - > > Key: FOP-2580 > URL: https://issues.apache.org/jira/browse/FOP-2580 > Project: FOP > Issue Type: Bug > Components: documentation, font/unqualified >Affects Versions: 2.0, 2.1 > Environment: Windows 10 64bit CPU Core I-5 Ram 8G JRE 1.80_73 fop > binary 2.1 >Reporter: AEKAPAN TAWEELUER > Labels: build > Fix For: 1.1 > > Attachments: Norasi.ttf, complex-script-disabled.pdf, fop.xconf, > leelawad.ttf, log.txt, true.pdf, wrong.fo, wrong.pdf > > > Glyph of Thai Font have problem when start in new line or have white space in > front of word. > In Example Wrong.pdf you'll see upper and lower glyph shift to the right 1 > character when the base character no have any character before or have white > space before. > "อ ิ" the true is should be "อิ" > "อกี" the true is should be "อีก" > "อ ุ" the true is should be "อุ" > "อบุ" the true is should be "อุบ" > remark : Font Angsana New AngsanaUPC , Leelawadee , Norasi and Tahoma are > most use in Thai font. > I use Windows command line (cmd) to generate pdf file. > example command line > C:\fop-2.1>fop.bat fop -c conf\fop.xconf -fo wrong.fo wrong.pdf -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2580) Wrong Position of Thai Glyph in FOP 2.0+ (Binary version)
[ https://issues.apache.org/jira/browse/FOP-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15813819#comment-15813819 ] AEKAPAN TAWEELUER commented on FOP-2580: Thank you for recommended, it work only Garuda and Norasi but have effect with upper(2nd) glyphs of other fonts. you see in with complex-script-disabled.pdf > Wrong Position of Thai Glyph in FOP 2.0+ (Binary version) > - > > Key: FOP-2580 > URL: https://issues.apache.org/jira/browse/FOP-2580 > Project: FOP > Issue Type: Bug > Components: documentation, font/unqualified >Affects Versions: 2.0, 2.1 > Environment: Windows 10 64bit CPU Core I-5 Ram 8G JRE 1.80_73 fop > binary 2.1 >Reporter: AEKAPAN TAWEELUER > Labels: build > Fix For: 1.1 > > Attachments: Norasi.ttf, fop.xconf, leelawad.ttf, log.txt, true.pdf, > wrong.fo, wrong.pdf > > > Glyph of Thai Font have problem when start in new line or have white space in > front of word. > In Example Wrong.pdf you'll see upper and lower glyph shift to the right 1 > character when the base character no have any character before or have white > space before. > "อ ิ" the true is should be "อิ" > "อกี" the true is should be "อีก" > "อ ุ" the true is should be "อุ" > "อบุ" the true is should be "อุบ" > remark : Font Angsana New AngsanaUPC , Leelawadee , Norasi and Tahoma are > most use in Thai font. > I use Windows command line (cmd) to generate pdf file. > example command line > C:\fop-2.1>fop.bat fop -c conf\fop.xconf -fo wrong.fo wrong.pdf -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2362) [PATCH] Rendering AFP extension to intermediate format throws NullPointerException
[ https://issues.apache.org/jira/browse/FOP-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] simon steiner updated FOP-2362: --- Summary: [PATCH] Rendering AFP extension to intermediate format throws NullPointerException (was: Rendering AFP extension to intermediate format throws NullPointerException) > [PATCH] Rendering AFP extension to intermediate format throws > NullPointerException > -- > > Key: FOP-2362 > URL: https://issues.apache.org/jira/browse/FOP-2362 > Project: FOP > Issue Type: Bug > Components: unqualified >Affects Versions: 1.1 > Environment: Apple OSX 10.9.2 / Java version 1.7.0_11 >Reporter: Hauke Haastert > Attachments: extensions.diff, simple.xsl, test.fo > > > When rendering an XSL-FO file that contains an AFP-Extension to the > intermediate format while using Saxon as XSLT transformer, a > NullPointerException is thrown. > Steps to reproduce: > 1. Download and unpack the FOP 1.1 binary release. > 2. Change into the root directory "fop-1.1" of the release > 3. Download Saxon HE from > http://repo1.maven.org/maven2/net/sf/saxon/Saxon-HE/9.4/Saxon-HE-9.4.jar and > copy the file to the lib directory of the FOP 1.1 release > 4. Edit the file fop that is located in the root directory of the release and > add the following JVM parameter to the java_exec_args: > > -Djavax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl > The line should now look like: > java_exec_args="-Djava.awt.headless=true > -Djavax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl" > 5. Download the attached files test.fo and simple.xsl and run the following > fop command: > fop -fo test.fo -out application/X-fop-intermediate-format test.if.xml > Actual Results: > Application throws NullPointerException: > java.lang.NullPointerException > at > net.sf.saxon.event.ReceivingContentHandler.getNodeName(ReceivingContentHandler.java:391) > at > net.sf.saxon.event.ReceivingContentHandler.startElement(ReceivingContentHandler.java:316) > at > org.apache.fop.util.DelegatingContentHandler.startElement(DelegatingContentHandler.java:185) > at > org.apache.fop.render.afp.extensions.AFPPageSetup.toSAX(AFPPageSetup.java:125) > at > org.apache.fop.render.intermediate.IFSerializer.handleExtensionObject(IFSerializer.java:680) > Expected Results: > Application should render IF from FO > Additional Information: > In the toSAX method of the class > org.apache.fop.render.afp.extensions.AFPPageSetup the method addAttribute of > the class org.xml.sax.helpers.AttributesImpl is called with null as first > argument. Due to the APIDOC of the class org.xml.sax.helpers.AttributesImpl > the first argument must either be the namespace or an empty string, but not > null: > uri - The Namespace URI, or the empty string if none is available or > Namespace processing is not being performed. > When changing the parameter value to an empty string, no NullPointerException > is thrown anymore. The same problem exists in other classes in the package > org.apache.fop.render.afp.extensions, so I added a diff file for the complete > package (extensions.diff). > The exception is not thrown when using Xalan as XSL transformer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FOP-2360) Can no longer get -awt (FOP viewer) to work
[ https://issues.apache.org/jira/browse/FOP-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] simon steiner resolved FOP-2360. Resolution: Cannot Reproduce > Can no longer get -awt (FOP viewer) to work > --- > > Key: FOP-2360 > URL: https://issues.apache.org/jira/browse/FOP-2360 > Project: FOP > Issue Type: Bug > Components: renderer/awt >Affects Versions: 1.1 > Environment: Windows 7, Windows 8.1 >Reporter: nick.heyworth > Attachments: tmp.fo > > > Calling > fop.bat -fo tmp.fo -awt > results in > "SEVERE: Exception > java.awt.HeadlessException" > due to > -Djava.awt.headless=true > in fop.bat which is there since FOP 1.1. Removing this at least opens the > viewer, but no document is displayed, and I get > "org.apache.fop.apps.FOPException: Requested page number is out of range: 0; > only 0 page(s) available." > This occurs for any XML-FO file; an example is attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2276) [PATCH] currentFObj is not updated if Throwable is thrown
[ https://issues.apache.org/jira/browse/FOP-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] simon steiner updated FOP-2276: --- Summary: [PATCH] currentFObj is not updated if Throwable is thrown (was: currentFObj is not updated if Throwable is thrown) > [PATCH] currentFObj is not updated if Throwable is thrown > - > > Key: FOP-2276 > URL: https://issues.apache.org/jira/browse/FOP-2276 > Project: FOP > Issue Type: Bug > Components: fo/unqualified >Affects Versions: 1.1 >Reporter: Daniel Dracott >Assignee: Andreas L. Delmelle > Attachments: FOP-2276.patch > > > If an exception is thrown during > org.apache.fop.fo.FOTreeBuilder.MainFOHandler.endElement(String, String, > String), then the line "currentFObj = currentFObj.getParent();" does not get > executed. If the SAX event source decides to store the exception and > continue, then subsequent endElement calls can generate SAXExceptions of the > form: > Caused by: org.xml.sax.SAXException: Mismatch: page-sequence > (http://www.w3.org/1999/XSL/Format) vs. root > (http://www.w3.org/1999/XSL/Format) > at > org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:338) > at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:181) > ... > Some implementations of javax.xml.transform.Transformer that we have used > will attempt to perform further endElement calls in this way and the > SAXException can hide the original Throwable, making diagnosis of problems > difficult. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2383) [PATCH] table cells inherit inline styles from preceding cells.
[ https://issues.apache.org/jira/browse/FOP-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] simon steiner updated FOP-2383: --- Summary: [PATCH] table cells inherit inline styles from preceding cells. (was: [patch] table cells inherit inline styles from preceding cells.) > [PATCH] table cells inherit inline styles from preceding cells. > --- > > Key: FOP-2383 > URL: https://issues.apache.org/jira/browse/FOP-2383 > Project: FOP > Issue Type: Bug > Components: renderer/rtf >Affects Versions: 1.1 >Reporter: Michael Hombre Brinkmann >Priority: Minor > Attachments: rtf-table-inline-attribute-patch.diff > > > If in a table cell a style bold, italic, strikethrough, underline, super or > sub is given, these styles are applied to all subsequent cells of the same > row. > The given patch only solves the problems for the 6 named styles. > It can be probably enhanced to fix also issures #FOP-2225 and #FOP-1487. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2438) [PATCH] Non-breaking space causes alignment problems with text-align-last="justify"
[ https://issues.apache.org/jira/browse/FOP-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] simon steiner updated FOP-2438: --- Summary: [PATCH] Non-breaking space causes alignment problems with text-align-last="justify" (was: Non-breaking space causes alignment problems with text-align-last="justify") > [PATCH] Non-breaking space causes alignment problems with > text-align-last="justify" > --- > > Key: FOP-2438 > URL: https://issues.apache.org/jira/browse/FOP-2438 > Project: FOP > Issue Type: Bug >Affects Versions: 1.1, 2.0, trunk, 2.1 >Reporter: Martin Doucha > Attachments: nbsp.patch, test.fo > > > Non-breaking spaces are not included in stretch factor calculation under > special circumstances but they are stretched by the resulting (oversized) > stretch factor, leading to text overflowing out of block. Those special > circumstances are: > - text-align-last="justify" > - text-align="start" (or anything else other than justify) > - the non-breaking space has to get positioned on the last line of the block > Here's Knuth sequence for block "Test TestTest" with the above > alignment settings: > aux. box w=2500, box w=17220, penalty p=-INFINITE w=0 (forced break, ??? > (-1))]> > Notice that the second space is represented as box instead of glue with > penalty. > Here's Knuth sequence for the same block but this time with alignment > justify/justify: > w=17220, aux. box w=0, aux. penalty p=INFINITE w=0, glue w=2500 stretch=1250 > shrink=833, box w=17220, penalty p=-INFINITE w=0 (forced break, ??? (-1))]> > This gets rendered correctly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2540) [PATCH] Enhance TTF/OTF support beyond Windows
[ https://issues.apache.org/jira/browse/FOP-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] simon steiner updated FOP-2540: --- Summary: [PATCH] Enhance TTF/OTF support beyond Windows (was: Enhance TTF/OTF support beyond Windows) > [PATCH] Enhance TTF/OTF support beyond Windows > -- > > Key: FOP-2540 > URL: https://issues.apache.org/jira/browse/FOP-2540 > Project: FOP > Issue Type: Improvement > Components: font/opentype >Affects Versions: 2.0 > Environment: OS X >Reporter: Andreas L. Delmelle >Assignee: Andreas L. Delmelle >Priority: Minor > Attachments: FOP-2540.patch, test_osx_fonts_after_1.log, > test_osx_fonts_before.log > > > Currently, cmap tables in TTF/OTF are only supported for Platform ID = 3, > i.e. MS Windows. There is no support for Platform ID = 0, i.e. basic Unicode, > or 1, i.e. Macintosh. > This makes quite some system fonts bundled with OS X supposedly unusable. The > solution is fairly trivial (patch proposal will be attached shortly), > provided the cmap table format in the font is already supported. FOP > currently only has support for cmap format 4 (segment to delta mapping), but > this seems to suffice for most of the Unicode cmaps as well. > See also FOP-2539, which triggered me to investigate this closer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2324) [PATCH] Character not found in AFP font but no warning is issued
[
https://issues.apache.org/jira/browse/FOP-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
simon steiner updated FOP-2324:
---
Summary: [PATCH] Character not found in AFP font but no warning is issued
(was: Character not found in AFP font but no warning is issued)
> [PATCH] Character not found in AFP font but no warning is issued
>
>
> Key: FOP-2324
> URL: https://issues.apache.org/jira/browse/FOP-2324
> Project: FOP
> Issue Type: Improvement
> Components: font/unqualified
>Affects Versions: trunk
>Reporter: Seifeddine Dridi
>Priority: Minor
> Fix For: trunk
>
> Attachments: patch.diff
>
>
> I noticed that the AFP font system never files a warning whenever a character
> was not found in the font, unlike font systems for other output formats where
> a warning is always displayed whenever FOP detects a possible error.
> Apparently, this is mainly happening because there is no defined mapping
> between Unicode values and font code points for AFP, as can be seen in
> CharacterSet.mapChar(). That's why I propose to change it to:
> public char mapChar(char c) {
> //TODO This is not strictly correct but we'll let it be for the moment
> if (this.encoder.canEncode(c)) {
> return c;
> }
> return 0;
> }
> So we can check later in AbstractOutlineFont.mapChar() whenever a character
> was found or not and display a warning if necessary.
> Any thoughts?
> Thanks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FOP-2580) Wrong Position of Thai Glyph in FOP 2.0+ (Binary version)
[ https://issues.apache.org/jira/browse/FOP-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15811800#comment-15811800 ] simon steiner commented on FOP-2580: Try adding to fop.xconf after : > Wrong Position of Thai Glyph in FOP 2.0+ (Binary version) > - > > Key: FOP-2580 > URL: https://issues.apache.org/jira/browse/FOP-2580 > Project: FOP > Issue Type: Bug > Components: documentation, font/unqualified >Affects Versions: 2.0, 2.1 > Environment: Windows 10 64bit CPU Core I-5 Ram 8G JRE 1.80_73 fop > binary 2.1 >Reporter: AEKAPAN TAWEELUER > Labels: build > Fix For: 1.1 > > Attachments: Norasi.ttf, fop.xconf, leelawad.ttf, log.txt, true.pdf, > wrong.fo, wrong.pdf > > > Glyph of Thai Font have problem when start in new line or have white space in > front of word. > In Example Wrong.pdf you'll see upper and lower glyph shift to the right 1 > character when the base character no have any character before or have white > space before. > "อ ิ" the true is should be "อิ" > "อกี" the true is should be "อีก" > "อ ุ" the true is should be "อุ" > "อบุ" the true is should be "อุบ" > remark : Font Angsana New AngsanaUPC , Leelawadee , Norasi and Tahoma are > most use in Thai font. > I use Windows command line (cmd) to generate pdf file. > example command line > C:\fop-2.1>fop.bat fop -c conf\fop.xconf -fo wrong.fo wrong.pdf -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FOP-1702) [PATCH] implements color pcl output
[ https://issues.apache.org/jira/browse/FOP-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] simon steiner resolved FOP-1702. Resolution: Duplicate Dup of FOP-2309 > [PATCH] implements color pcl output > --- > > Key: FOP-1702 > URL: https://issues.apache.org/jira/browse/FOP-1702 > Project: FOP > Issue Type: Bug > Components: renderer/pcl >Affects Versions: trunk > Environment: Operating System: Windows XP > Platform: PC >Reporter: jim gabriel > Attachments: FOP-colorpcl.patch > > > The implementation to support color pcl is automatic. If a color image is > used, then color pcl is output. Otherwise, the output remains B/W. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FOP-2559) [PATCH] Kerning doesn't work for OTF/CFF font
[ https://issues.apache.org/jira/browse/FOP-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] simon steiner resolved FOP-2559. Resolution: Duplicate Dup of FOP-2557 > [PATCH] Kerning doesn't work for OTF/CFF font > - > > Key: FOP-2559 > URL: https://issues.apache.org/jira/browse/FOP-2559 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: trunk >Reporter: chunlinyao >Priority: Minor > Labels: patch > Attachments: patch.txt > > > According to the spec. "OpenType™ fonts containing CFF outlines are not > supported by the 'kern' table and must use the 'GPOS' OpenType Layout table." > But OFFontLoader hasn't pass the useAdvanced flag to OTFFile, so GPOS table > not read. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FOP-1180) [PATCH] Fop fails to render non-ascii characters in PDF output
[ https://issues.apache.org/jira/browse/FOP-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] simon steiner resolved FOP-1180. Resolution: Cannot Reproduce > [PATCH] Fop fails to render non-ascii characters in PDF output > -- > > Key: FOP-1180 > URL: https://issues.apache.org/jira/browse/FOP-1180 > Project: FOP > Issue Type: Bug > Components: font/unqualified >Affects Versions: 1.0 > Environment: Operating System: Windows XP > Platform: PC >Reporter: Max Berger > Labels: PatchAvailable > Attachments: patch_for_symbols_in_svg.patch, sigmatest.fo, > svgfilewithsigma.svg > > > Dear developers, > I know the font system is currently undergoing changes. Please excuse this if > this gets fixed soon. > When rendering a document containing "special" characters to pdf, they get > shown as # instead of the > right character. > (fop svn, current checkout) > For a full example, see the attached test file. > Example: > test test > should render: test E test (where E is the sigma character). > On the pdf output I get: > test # test > AWT output works fine. > I don't know if this is specific to a Mac system. I have no user fonts > installed. > (What it should do is figure out that the standard font does not have the > SIGMA character and switch to > the symbol font). > If there is no one working on it and you point me in the right direction I > may be able to provide a patch. > Max -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FOP-2541) [PATCH] AFP PTX fields chaining
[ https://issues.apache.org/jira/browse/FOP-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] simon steiner resolved FOP-2541. Resolution: Duplicate > [PATCH] AFP PTX fields chaining > --- > > Key: FOP-2541 > URL: https://issues.apache.org/jira/browse/FOP-2541 > Project: FOP > Issue Type: Bug > Components: renderer/afp >Affects Versions: trunk >Reporter: Luca Bellonda > Labels: patch > Attachments: apache_fop_chain_ptx_2015_11_19.patch > > > This patch fixes an issue in the AFP emitter, when a long text is split into > multiple PTX fields inside a Presentation Text object. > The boundaries of the fields are not following the AFP specifications, > leading to problems on some printers. It seems that the function chaining is > implicitly broken at the chunk boundary and not at the end of the PTX segment. > The size of the PTX segment has been checked to respect the maximum length. > In the patch you will find a test case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2550) Paths in svg images to urls gets duplicated
[ https://issues.apache.org/jira/browse/FOP-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15811539#comment-15811539 ] hexdump commented on FOP-2550: -- Doesn't happen if path are absolute > Paths in svg images to urls gets duplicated > --- > > Key: FOP-2550 > URL: https://issues.apache.org/jira/browse/FOP-2550 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0 > Environment: Windows 7 >Reporter: Olof Wolgast > Fix For: 1.1 > > > Consider the following > > src="url(SwComponents/ShDet/gd_GearDet/SL/gd_GearDet_gd_GearDet_Schedule_Predicted_Gear_If_Action_Subsystem1.svg)" > width="auto" height="auto" content-width="auto" content-height="auto" /> > > It results in an error > org.apache.batik.bridge.BridgeException: > SwComponents\ShDet\gd_GearDet\SL\SwComp > onents\ShDet\gd_GearDet\SL\gd_GearDet_gd_GearDet_Schedule_Predicted_Gear_If_Acti > on_Subsystem1.svg (The system cannot find the path specified) > The directory part of the path is repeated! > If I replace the svg with a png it works fine. Both svg and png works in > FOP-1.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
