[jira] [Commented] (FOP-2495) Embedding: missing migration documentation from FOP 1.x

[Robert Oschwald (JIRA)]

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

Robert Oschwald commented on FOP-2495:
--

If you have fonts in other locations than the base url  (e.g. other path, 
Classpath, etc.) it seems the only possible way currently is to implement a 
custom ResourceResolver which tries to get the resource from fontBaseUrl and if 
not found, from the default ResourceResolver. Not very efficient imho.

But thats not the point. The upgrade document needs an update, or FOP should 
re-introduce the fontBaseUrl.

 

 

> Embedding: missing migration documentation from FOP 1.x
> ---
>
> Key: FOP-2495
> URL: https://issues.apache.org/jira/browse/FOP-2495
> Project: FOP
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 2.0
> Environment: WIndows, Java 8, FOP 1.0
>Reporter: MH
>Priority: Major
>  Labels: documentation
>
> Because of bug FOP-2177 we couldn't upgrade form FOP 1.0 to FOP 1.1. FOP 2.0 
> has solved this bug (tested with standalone FOP scripts).
> Now we would like to upgrade our Java code from FOP 1.0 to FOP 2.0. The 
> Upgrading page (https://xmlgraphics.apache.org/fop/2.0/upgrading.html) says 
> "You should encounter very few issues in upgrading from FOP 1.0, except as 
> noted in the following: ...". The truth is completely different: starting by 
> replacing fop.jar, our code gets dozens of compiler errors! Many methods are 
> simply gone:
> FopFactory.newInstance()
> FoUserAgent.setBaseURL(String);
> FopFactory.getFontManager().setFontBaseURL(String)
> FopFactory.setURIResolver(URIResolver);
> etc.
> The javadocs from 1.1 to 2.0 simple changed - no deprecated methods, no hints 
> how to replace old methods.
> The FOP 2.0 embedding page 
> (https://xmlgraphics.apache.org/fop/2.0/embedding.html) just shows simple 
> examples to start from the ground. I can't find any migration help how to 
> replace old code. 
> E.g. how can I set the font base? 
> FopFactory.getFontManager().setFontBaseURL(String) is gone and I can't find 
> any equivalent code for FOP 2.0!
> This is a major bug in FOP 2.0 as API changes are not documented to upgrade 
> from FOP 1.x Java API to FOP 2.0!
> Now I just can search and try and experiment if I get our old code somehow 
> running with all those undocumented API changes. Can you please state a 
> migration documentation for all methods (method signatures) that don't exist 
> anymore? We can't start coding all over again from scratch. Thank you very 
> much!



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

[jira] [Commented] (FOP-2495) Embedding: missing migration documentation from FOP 1.x

[Robert Oschwald (JIRA)]

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

Robert Oschwald commented on FOP-2495:
--

Any news on this? Would be great if the upgrade document would be extended to 
show how to set the baseUrl / fontBaseUrl in FOP >= 2.0 when upgrading.

 

 

 

 

> Embedding: missing migration documentation from FOP 1.x
> ---
>
> Key: FOP-2495
> URL: https://issues.apache.org/jira/browse/FOP-2495
> Project: FOP
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 2.0
> Environment: WIndows, Java 8, FOP 1.0
>Reporter: MH
>Priority: Major
>  Labels: documentation
>
> Because of bug FOP-2177 we couldn't upgrade form FOP 1.0 to FOP 1.1. FOP 2.0 
> has solved this bug (tested with standalone FOP scripts).
> Now we would like to upgrade our Java code from FOP 1.0 to FOP 2.0. The 
> Upgrading page (https://xmlgraphics.apache.org/fop/2.0/upgrading.html) says 
> "You should encounter very few issues in upgrading from FOP 1.0, except as 
> noted in the following: ...". The truth is completely different: starting by 
> replacing fop.jar, our code gets dozens of compiler errors! Many methods are 
> simply gone:
> FopFactory.newInstance()
> FoUserAgent.setBaseURL(String);
> FopFactory.getFontManager().setFontBaseURL(String)
> FopFactory.setURIResolver(URIResolver);
> etc.
> The javadocs from 1.1 to 2.0 simple changed - no deprecated methods, no hints 
> how to replace old methods.
> The FOP 2.0 embedding page 
> (https://xmlgraphics.apache.org/fop/2.0/embedding.html) just shows simple 
> examples to start from the ground. I can't find any migration help how to 
> replace old code. 
> E.g. how can I set the font base? 
> FopFactory.getFontManager().setFontBaseURL(String) is gone and I can't find 
> any equivalent code for FOP 2.0!
> This is a major bug in FOP 2.0 as API changes are not documented to upgrade 
> from FOP 1.x Java API to FOP 2.0!
> Now I just can search and try and experiment if I get our old code somehow 
> running with all those undocumented API changes. Can you please state a 
> migration documentation for all methods (method signatures) that don't exist 
> anymore? We can't start coding all over again from scratch. Thank you very 
> much!



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

[jira] [Created] (FOP-2807) Table cell padding reversed in RTL mode

[Robert Flaherty (JIRA)]

Robert Flaherty created FOP-2807:


 Summary: Table cell padding reversed in RTL mode
 Key: FOP-2807
 URL: https://issues.apache.org/jira/browse/FOP-2807
 Project: FOP
  Issue Type: Bug
  Components: renderer/pdf
Affects Versions: 2.3
 Environment: Win10
Reporter: Robert Flaherty
 Attachments: LiberationSans-Bold.ttf, LiberationSans-BoldItalic.ttf, 
LiberationSans-Italic.ttf, LiberationSans-Regular.ttf, fo-config.xml, ltr.pdf, 
ltr.renderx.pdf, ltr.xml, rtl.pdf, rtl.renderx.pdf, rtl.xml, run.bat

I've included a sample for LTR and the same file modified for RTL by just 
switching the writing mode.  The columns flip, and anything with start/end 
should flip, with anything left/right remaining the same.  It looks like the 
cell padding left/right/start/end are all reversed in RTL mode.  Its hard to 
tell from the example, as the border boxes are offset (which I reported 
separately), but all of the alignments look to be correct.

I poked around to see what other free processors I could try, and there was an 
online version (old) of RenderX, which I included their output.  The only 
problem there was the first 5 rows which have left/right alignment, which 
should have been flipped.



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

[jira] [Created] (FOP-2806) Table cell padding offsets the entire cell border in RTL

[Robert Flaherty (JIRA)]

Robert Flaherty created FOP-2806:


 Summary: Table cell padding offsets the entire cell border in RTL
 Key: FOP-2806
 URL: https://issues.apache.org/jira/browse/FOP-2806
 Project: FOP
  Issue Type: Bug
  Components: renderer/pdf
Affects Versions: 2.3
 Environment: Win10 and Linux6
Reporter: Robert Flaherty
 Attachments: FopLtrOk.pdf, FopLtrOk.xml, FopRtlBug1.pdf, 
FopRtlBug1.xml, FopRtlBug2.pdf, FopRtlBug2.xml, LiberationSans-Bold.ttf, 
LiberationSans-BoldItalic.ttf, LiberationSans-Italic.ttf, 
LiberationSans-Regular.ttf, fo-config.xml, run.bat

My FO document in LR writing mode lays out fine, with three row headers left 
aligned with some left padding.  Roughly the same document except with the 
writing mode / alignment / padding flipped doesn't render correctly.  The cell 
border is shifted, almost acting like a margin, but spills over into other 
cells.  I also tried flipping the left/right padding in RTL, just to see what 
would happen, and the border was pushed the other way.  I didn't upload 
examples for padding-start/end, but they were the same.



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

Re: [VOTE] Merge Temp_SurrogatePairs to trunk

[Robert Meyer]

+1

From: Matthias Reischenbacher 
Sent: 14 March 2018 11:06
To: fop-dev@xmlgraphics.apache.org
Subject: Re: [VOTE] Merge Temp_SurrogatePairs to trunk

+1


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

RE: rendering Image file(png/bmp) on AFP file

[Robert Meyer]

Do you mean something like the following:
   


?
Best regards,
Robert
From: rajkumar_si...@newgen.co.in
To: fop-dev@xmlgraphics.apache.org
Subject: rendering Image file(png/bmp) on AFP file
Date: Tue, 16 Aug 2016 20:15:25 +0530

Dear Sir, I am developing an application using fop2.1 that create an AFP file 
and write text and image at specified position in that file.I am able to write 
text at specified position. But I am not getting any clue how to do it with an 
image. Can you please guide for this. Thanks in advance! RegardsRajkumar Singh 


Disclaimer :- This e-mail and any attachment may contain confidential, 
proprietary or legally privileged information. If you are not the original 
intended recipient and have erroneously received this message, you are 
prohibited from using, copying, altering or disclosing the content of this 
message. Please delete it immediately and notify the sender. Newgen Software 
Technologies Ltd (NSTL)  accepts no responsibilities for loss or damage arising 
from the use of the information transmitted by this email including damages 
from virus and further acknowledges that no binding nature of the message shall 
be implied or assumed unless the sender does so expressly with due authority of 
NSTL.




  

RE: [VOTE] Release XML Graphics FOP 2.1 (2nd attempt)

[Robert Meyer]

+1

Subject: Re: [VOTE] Release XML Graphics FOP 2.1 (2nd attempt)
To: fop-dev@xmlgraphics.apache.org; gene...@xmlgraphics.apache.org
From: matthias8...@gmx.at
Date: Fri, 8 Jan 2016 07:55:09 -0300


  

  
  
+1



On 07.01.2016 11:23, Simon Steiner wrote:

Hi,

  

  This is a vote to release XML Graphics FOP 2.1, status.xml has
  been removed.

  

  Artifacts can be found there:

  https://people.apache.org/~ssteiner/fop-2.1

  

  The release is signed with the key: 

  https://people.apache.org/~ssteiner/KEYS

  

  The vote will end on 14/1/2016

  

  +1 from me.

  

  Thanks

  


>




  

Re: unsubscribe

[Robert-B Koch]

Mit freundlichen Gruessen / with best regards





Robert Koch

Deutsche Bank Bauspar AG
Prozess- und IT-Management / Anwendungsentwicklung Technologie
Tel. +49(69)910-50244
Fax +49(69)910-50375


--

Informationen (einschließlich Pflichtangaben) zu einzelnen, innerhalb der EU 
tätigen Gesellschaften und Zweigniederlassungen des Konzerns Deutsche Bank 
finden Sie unter http://www.deutsche-bank.de/de/content/pflichtangaben.htm. 
Diese E-Mail enthält vertrauliche und/ oder rechtlich geschützte Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten 
haben, informieren Sie bitte sofort den Absender und vernichten Sie diese 
E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail 
ist nicht gestattet.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for information 
(including mandatory corporate particulars) on selected Deutsche Bank branches 
and group companies registered or incorporated in the European Union. This 
e-mail may contain confidential and/or privileged information. If you are not 
the intended recipient (or have received this e-mail in error) please notify 
the sender immediately and delete this e-mail. Any unauthorized copying, 
disclosure or distribution of the material in this e-mail is strictly forbidden.

RE: Build failed in Jenkins: xmlgraphics-fop #161

[Robert Meyer]

I am going to be resolving this shortly.

I'll also use this as an opportunity to resolve currently ignored findbugs 
issue as well.

I'll update this once done and the fix has been committed.

 Date: Mon, 10 Aug 2015 14:32:21 +
 From: jenk...@builds.apache.org
 To: fop-dev@xmlgraphics.apache.org
 Subject: Build failed in Jenkins: xmlgraphics-fop #161
 
 See https://builds.apache.org/job/xmlgraphics-fop/161/changes
 
 Changes:
 
 [rmeyer] FOP-2486: Soft font support for TrueType fonts in PCL
 
 --
 [...truncated 7618 lines...]
 [junit] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.06 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.extensions.prepress.PageBoundariesTestCase
 [junit] Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.003 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.extensions.prepress.PageScaleTestCase
 [junit] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.002 sec
 [junit] 
 [junit] Testsuite: org.apache.fop.render.gradient.GradientTestCase
 [junit] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.01 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.intermediate.AbstractIFPainterTestCase
 [junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.02 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.intermediate.ArcToBezierCurveTransformerTestCase
 [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.004 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.intermediate.BorderPainterTestCase
 [junit] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.113 sec
 [junit] 
 [junit] Testsuite: org.apache.fop.render.intermediate.IFSerializerTestCase
 [junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.005 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.intermediate.IFStructureTreeBuilderTestCase
 [junit] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.014 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.intermediate.SAXEventRecorderTestCase
 [junit] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.005 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.pcl.PCLRendererConfigParserTestCase
 [junit] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.019 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.pcl.PCLRendererConfiguratorTestCase
 [junit] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.038 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.pcl.fonts.PCLByteWriterUtilTestCase
 [junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.002 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.pcl.fonts.PCLFontReaderFactoryTestCase
 [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.034 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.pcl.fonts.PCLTTFFontReaderTestCase
 [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.022 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.pcl.fonts.truetype.PCLTTFCharacterWriterTestCase
 [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.013 sec
 [junit] 
 [junit] Testsuite: org.apache.fop.render.pdf.ImageRawPNGAdapterTestCase
 [junit] Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.108 sec
 [junit] 
 [junit] Testsuite: org.apache.fop.render.pdf.PDFAConformanceTestCase
 [junit] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.107 sec
 [junit] 
 [junit] Testsuite: org.apache.fop.render.pdf.PDFAMetadataTestCase
 [junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.012 sec
 [junit] 
 [junit] Testsuite: org.apache.fop.render.pdf.PDFBorderPainterTestCase
 [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.002 sec
 [junit] 
 [junit] Testsuite: org.apache.fop.render.pdf.PDFCMapTestCase
 [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.001 sec
 [junit] 
 [junit] Testsuite: org.apache.fop.render.pdf.PDFEncodingTestCase
 [junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 
 0.031 sec
 [junit] 
 [junit] Testcase: 
 testPDFEncodingWithCustomFont(org.apache.fop.render.pdf.PDFEncodingTestCase):SKIPPED:
  This should be tested using PDFBox. If PDFBox can extract the text 
 correctly,everything is fine. The tests here are too unstable.
 [junit] Testsuite: org.apache.fop.render.pdf.PDFGraphicsPainterTestCase
 [junit] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.022 sec
 [junit] 
 

RE: Build failed in Jenkins: xmlgraphics-fop #161

[Robert Meyer]

Fix has now been applied:

http://svn.apache.org/viewvc?view=revisionrevision=1695225

From: rme...@hotmail.co.uk
To: fop-dev@xmlgraphics.apache.org
Subject: RE: Build failed in Jenkins: xmlgraphics-fop #161
Date: Tue, 11 Aug 2015 08:03:19 +




I am going to be resolving this shortly.

I'll also use this as an opportunity to resolve currently ignored findbugs 
issue as well.

I'll update this once done and the fix has been committed.

 Date: Mon, 10 Aug 2015 14:32:21 +
 From: jenk...@builds.apache.org
 To: fop-dev@xmlgraphics.apache.org
 Subject: Build failed in Jenkins: xmlgraphics-fop #161
 
 See https://builds.apache.org/job/xmlgraphics-fop/161/changes
 
 Changes:
 
 [rmeyer] FOP-2486: Soft font support for TrueType fonts in PCL
 
 --
 [...truncated 7618 lines...]
 [junit] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.06 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.extensions.prepress.PageBoundariesTestCase
 [junit] Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.003 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.extensions.prepress.PageScaleTestCase
 [junit] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.002 sec
 [junit] 
 [junit] Testsuite: org.apache.fop.render.gradient.GradientTestCase
 [junit] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.01 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.intermediate.AbstractIFPainterTestCase
 [junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.02 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.intermediate.ArcToBezierCurveTransformerTestCase
 [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.004 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.intermediate.BorderPainterTestCase
 [junit] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.113 sec
 [junit] 
 [junit] Testsuite: org.apache.fop.render.intermediate.IFSerializerTestCase
 [junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.005 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.intermediate.IFStructureTreeBuilderTestCase
 [junit] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.014 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.intermediate.SAXEventRecorderTestCase
 [junit] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.005 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.pcl.PCLRendererConfigParserTestCase
 [junit] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.019 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.pcl.PCLRendererConfiguratorTestCase
 [junit] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.038 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.pcl.fonts.PCLByteWriterUtilTestCase
 [junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.002 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.pcl.fonts.PCLFontReaderFactoryTestCase
 [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.034 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.pcl.fonts.PCLTTFFontReaderTestCase
 [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.022 sec
 [junit] 
 [junit] Testsuite: 
 org.apache.fop.render.pcl.fonts.truetype.PCLTTFCharacterWriterTestCase
 [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.013 sec
 [junit] 
 [junit] Testsuite: org.apache.fop.render.pdf.ImageRawPNGAdapterTestCase
 [junit] Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.108 sec
 [junit] 
 [junit] Testsuite: org.apache.fop.render.pdf.PDFAConformanceTestCase
 [junit] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.107 sec
 [junit] 
 [junit] Testsuite: org.apache.fop.render.pdf.PDFAMetadataTestCase
 [junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.012 sec
 [junit] 
 [junit] Testsuite: org.apache.fop.render.pdf.PDFBorderPainterTestCase
 [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.002 sec
 [junit] 
 [junit] Testsuite: org.apache.fop.render.pdf.PDFCMapTestCase
 [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
 0.001 sec
 [junit] 
 [junit] Testsuite: org.apache.fop.render.pdf.PDFEncodingTestCase
 [junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 
 0.031 sec
 [junit] 
 [junit] Testcase: 
 testPDFEncodingWithCustomFont(org.apache.fop.render.pdf.PDFEncodingTestCase):SKIPPED:
  This should be tested using PDFBox. If PDFBox can extract the text 
 

RE: [VOTE RESULT] Merge Temp_PCLSoftFont branch with trunk

[Robert Meyer]

Hi,

The vote has now closed and has 6 +1 with no other votes. I will merge the 
branch in shortly.

Thanks all,

Robert

 Subject: Re: [VOTE] Merge Temp_PCLSoftFont branch with trunk
 To: fop-dev@xmlgraphics.apache.org
 From: bowditch_ch...@hotmail.com
 Date: Mon, 10 Aug 2015 13:25:09 +0100
 
 Hi Rob,
 
 Thanks for developing this useful addition to PCL Renderer.
 
 +1
 
 Thanks,
 
 Chris
 
 On 04/08/2015 16:33, Robert Meyer wrote:
  Hi All,
 
  This is a vote to merge the temporary branch for adding PCL soft font 
  support to FOP trunk.
 
  What this allows for are TrueType fonts to be converted into a PCL 
  native font format. This moves FOP away from using AWT and rasterized 
  characters allowing for PCL output to potentially be generated over a 
  cloud, better rendering quality and smaller documents. Other font 
  formats will still be rasterized but TrueType will now default to 
  being converted for PCL output.
 
  If you want to give it a try please do. The branch can be found here:
 
  http://svn.eu.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_PCLSoftFonts
   
  https://svn.eu.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_PCLSoftFonts
 
  This vote wll last 6 days (as I'm unavailable this weekend) and will 
  conclude next Monday.
 
  Here is my +1.
 
  Thanks,
 
  Robert
 
  

[jira] [Commented] (FOP-2486) [PATCH] Soft font support for TrueType fonts in PCL

[Robert Meyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14680164#comment-14680164
 ] 

Robert Meyer commented on FOP-2486:
---

Change applied: http://svn.apache.org/viewvc?view=revisionrevision=1695082

 [PATCH] Soft font support for TrueType fonts in PCL
 ---

 Key: FOP-2486
 URL: https://issues.apache.org/jira/browse/FOP-2486
 Project: FOP
  Issue Type: Improvement
  Components: renderer/pcl
Affects Versions: trunk
Reporter: Robert Meyer
 Fix For: trunk

 Attachments: patch.diff, patch2.diff, rasterized.pcl, softfonts.pcl


 Currently all fonts (except a limited set of native fonts) are rastered for 
 PCL output. This has the problem of the documents being large in size and 
 should FOP be used in the cloud, rendering to PCL would not be possible as 
 it's using AWT.
 This patch in part resolves this problem by converting TrueType fonts to PCL 
 soft fonts. This allows the size to be much smaller and has been a standard 
 feature since PCL 5.
 [EDIT] For all other fonts which are not TrueType it will still revert back 
 to being rasterized. It will currently default to using soft fonts for 
 TrueType fonts but this can overriden by using 
 text-renderingbitmap/text-rendering.



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

[jira] [Closed] (FOP-2486) [PATCH] Soft font support for TrueType fonts in PCL

[Robert Meyer (JIRA)]

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

Robert Meyer closed FOP-2486.
-
Resolution: Fixed

 [PATCH] Soft font support for TrueType fonts in PCL
 ---

 Key: FOP-2486
 URL: https://issues.apache.org/jira/browse/FOP-2486
 Project: FOP
  Issue Type: Improvement
  Components: renderer/pcl
Affects Versions: trunk
Reporter: Robert Meyer
 Fix For: trunk

 Attachments: patch.diff, patch2.diff, rasterized.pcl, softfonts.pcl


 Currently all fonts (except a limited set of native fonts) are rastered for 
 PCL output. This has the problem of the documents being large in size and 
 should FOP be used in the cloud, rendering to PCL would not be possible as 
 it's using AWT.
 This patch in part resolves this problem by converting TrueType fonts to PCL 
 soft fonts. This allows the size to be much smaller and has been a standard 
 feature since PCL 5.
 [EDIT] For all other fonts which are not TrueType it will still revert back 
 to being rasterized. It will currently default to using soft fonts for 
 TrueType fonts but this can overriden by using 
 text-renderingbitmap/text-rendering.



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

RE: SingleByteFont Patch

[Robert Meyer]

Hi,

I have had dealings with this when I was implementing open-type font support as 
that and Type-1 fonts share similar CharString data. Initially I thought the 
bounding box was a necessary part of getting the font to work and as such put 
forward two patches to FontBox. The first fixed their CharStringRenderer which 
renders each character and returns the width:

https://issues.apache.org/jira/browse/PDFBOX-1505

Once that was approved, I put forward a second patch which calculated an 
accurate bounding box for the given character using the same renderer:

https://issues.apache.org/jira/browse/PDFBOX-1645

Unfortunately doing this takes a fair amount of processing power and after 
reading some of their concerns, while also realising that in the end I didn't 
need the bounding box, I gave up on my attempt and the issue was closed. From 
my testing it was certainly possible to get very accurate bounding boxes for 
Type 1 font missing metrics. Whether it would be worth the effort implementing 
this is doubtful though considering firstly the fact that we lack much of the 
infrastructure to implement this, but more importantly having a detrimental 
impact upon performance for these limited cases.

If Jeremias's approximation is anywhere near accurate I'd certainly suggest 
giving that a go.

Robert

 Date: Thu, 6 Aug 2015 09:42:12 -0300
 From: matthias8...@gmx.at
 To: fop-dev@xmlgraphics.apache.org
 Subject: Re: SingleByteFont Patch
 
 Hi Team,
 
 the same issue described below, came up today on my side. I did a debug
 session and what I have found out so far is, that this only happens for
 Type1 fonts, that don't have a AFM file. The PFM file doesn't contain
 the char metrics so the bounding boxes can't be initialized.
 When transcoding SVGs to PDF, the code seems to rely on those bounding
 boxes (see FOPGVTGlyphVector), so I'm wondering what a correct fix would
 be. The PFMFile class contains a getFontBBox method, which, as its
 JavaDoc says, returns an approximation of the bounding box. I guess
 returning the approximation is better than nothing, so what I've come up
 so far code-wise is:
 
 returnFont.setLastChar(pfm.getLastChar());
 for (short i = pfm.getFirstChar(); i = pfm.getLastChar(); i++) {
 int cw = pfm.getCharWidth(i);
 singleFont.setWidth(i, cw);
 // start of my code change
 int[] bbox = pfm.getFontBBox();
 singleFont.setBoundingBox(i, new Rectangle(bbox[0], bbox[1], cw,
 bbox[3]));
 // end of my code change
 }
 
 Basically I'm using the approximation plus the current char width to
 build a rectangle.
 
 Any thoughts? Or ideas for a better fix?
 
 Thanks  Best regards,
 Matthias
 
 On 01.07.2014 08:43, Pascal Sancho wrote:
  Hi,
  can you file in entries in Jira, please?
  see our HowTo [1] submitting patches.
  
  [1] http://xmlgraphics.apache.org/fop/dev/#patches
  
  2014-07-01 12:36 GMT+02:00 Kai Hofmann powers...@web.de:
 
  Dear all,
 
  looks like there is another bug based on the before mentioned problem:
 
  FOPGVTGlyphVector:
 
 private void buildBoundingBoxes() {
  boundingBoxes = new Rectangle2D[glyphs.length];
  for (int i = 0; i  glyphs.length; i++) {
  Rectangle bbox = fontMetrics.getBoundingBox(glyphs[i], 
  fontSize);
  boundingBoxes[i] = new Rectangle2D.Float(bbox.x / 100f, 
  -(bbox.y + bbox.height) / 100f,
  bbox.width / 100f, bbox.height / 100f);
  }
  }
 
 
  Here the result of the patched getBoundingBox seems to be used without a 
  null pointer check. Please keep attention on getBoundingBox which 
  explizitly returns null 
  Looks like it would help to have complete javadocs which describe the 
  possible return values to avoid such mistakes.
 
 
  Gesendet: Dienstag, 01. Juli 2014 um 10:52 Uhr
  Von: Kai Hofmann powers...@web.de
  An: fop-us...@xmlgraphics.apache.org
  Betreff: SingleByteFont Patch
  Dear all,
 
  I found a small bug in SingleByteFont - please see attached patch - in 
  getBoundingBox:
 
  if (idx = 0  idx  boundingBoxes.length)
 
  might result in a null pointer exception, when getBoundingBox is called 
  before setBoudning box.
  So repleace with:
 
  if (boundingBoxes != null  idx = 0  idx  boundingBoxes.length)
  
  
  

[jira] [Updated] (FOP-2486) [PATCH] Soft font support for TrueType fonts in PCL

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2486:
--
Attachment: patch2.diff

I've added a new patch and will commit this shortly to the temp_pclsoftfonts 
branch. I will start a vote shortly on merging in this functionality.

 [PATCH] Soft font support for TrueType fonts in PCL
 ---

 Key: FOP-2486
 URL: https://issues.apache.org/jira/browse/FOP-2486
 Project: FOP
  Issue Type: Improvement
  Components: renderer/pcl
Affects Versions: trunk
Reporter: Robert Meyer
 Fix For: trunk

 Attachments: patch.diff, patch2.diff, rasterized.pcl, softfonts.pcl


 Currently all fonts (except a limited set of native fonts) are rastered for 
 PCL output. This has the problem of the documents being large in size and 
 should FOP be used in the cloud, rendering to PCL would not be possible as 
 it's using AWT.
 This patch in part resolves this problem by converting TrueType fonts to PCL 
 soft fonts. This allows the size to be much smaller and has been a standard 
 feature since PCL 5.
 [EDIT] For all other fonts which are not TrueType it will still revert back 
 to being rasterized. It will currently default to using soft fonts for 
 TrueType fonts but this can overriden by using 
 text-renderingbitmap/text-rendering.



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

[jira] [Comment Edited] (FOP-2486) [PATCH] Soft font support for TrueType fonts in PCL

[Robert Meyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14653773#comment-14653773
 ] 

Robert Meyer edited comment on FOP-2486 at 8/4/15 3:03 PM:
---

I've added a new patch with improvements and bug fixes to my original patch. I 
will commit this shortly to the temp_pclsoftfonts branch and will start a vote 
shortly on merging in this functionality.


was (Author: rmeyer):
I've added a new patch and will commit this shortly to the temp_pclsoftfonts 
branch. I will start a vote shortly on merging in this functionality.

 [PATCH] Soft font support for TrueType fonts in PCL
 ---

 Key: FOP-2486
 URL: https://issues.apache.org/jira/browse/FOP-2486
 Project: FOP
  Issue Type: Improvement
  Components: renderer/pcl
Affects Versions: trunk
Reporter: Robert Meyer
 Fix For: trunk

 Attachments: patch.diff, patch2.diff, rasterized.pcl, softfonts.pcl


 Currently all fonts (except a limited set of native fonts) are rastered for 
 PCL output. This has the problem of the documents being large in size and 
 should FOP be used in the cloud, rendering to PCL would not be possible as 
 it's using AWT.
 This patch in part resolves this problem by converting TrueType fonts to PCL 
 soft fonts. This allows the size to be much smaller and has been a standard 
 feature since PCL 5.
 [EDIT] For all other fonts which are not TrueType it will still revert back 
 to being rasterized. It will currently default to using soft fonts for 
 TrueType fonts but this can overriden by using 
 text-renderingbitmap/text-rendering.



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

[VOTE] Merge Temp_PCLSoftFont branch with trunk

[Robert Meyer]

Hi All,

This is a vote to merge the temporary branch for adding PCL soft font support 
to FOP trunk.

What this allows for are TrueType fonts to be converted into a PCL native font 
format. This moves FOP away from using AWT and rasterized characters allowing 
for PCL output to potentially be generated over a cloud, better rendering 
quality and smaller documents. Other font formats will still be rasterized but 
TrueType will now default to being converted for PCL output.

If you want to give it a try please do. The branch can be found here:

http://svn.eu.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_PCLSoftFonts

This vote wll last 6 days (as I'm unavailable this weekend) and will conclude 
next Monday. 

Here is my +1.

Thanks,

Robert
  

[jira] [Commented] (FOP-2494) Unable to use Ubuntu Mono Font

[Robert Meyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14650397#comment-14650397
 ] 

Robert Meyer commented on FOP-2494:
---

Fixed in http://svn.apache.org/viewvc?view=revisionrevision=1693719

 Unable to use Ubuntu Mono Font
 --

 Key: FOP-2494
 URL: https://issues.apache.org/jira/browse/FOP-2494
 Project: FOP
  Issue Type: Bug
  Components: font/opentype
Affects Versions: 2.0
 Environment: Ubuntu 14.04, Java 8u45
Reporter: Harshad
Assignee: Robert Meyer
 Attachments: output.pdf, patch.diff


 I want to use the Ubuntu Mono font, which is installed on my system. But FOP 
 throws an exception when it is auto-detecting the fonts:
 {code}
 Unable to load font file: 
 file:/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-R.ttf
 java.lang.ArrayIndexOutOfBoundsException: 1047

   at org.apache.fop.fonts.truetype.OpenFont.readPostScript(OpenFont.java:1320)
   at org.apache.fop.fonts.truetype.OpenFont.readFont(OpenFont.java:736)
   at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:109)
   at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:93)
   at org.apache.fop.fonts.FontLoader.getFont(FontLoader.java:124)
   at org.apache.fop.fonts.FontLoader.loadFont(FontLoader.java:108)
   at 
 org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:254)
   at org.apache.fop.fonts.FontAdder.add(FontAdder.java:63)
   at 
 org.apache.fop.fonts.FontDetectorFactory$DefaultFontDetector.detect(FontDetectorFactory.java:97)
   at org.apache.fop.fonts.FontManager.autoDetectFonts(FontManager.java:229)
   at 
 org.apache.fop.fonts.DefaultFontConfigurator.configure(DefaultFontConfigurator.java:82)
   at 
 org.apache.fop.render.PrintRendererConfigurator.getCustomFontCollection(PrintRendererConfigurator.java:147)
   at 
 org.apache.fop.render.PrintRendererConfigurator.setupFontInfo(PrintRendererConfigurator.java:127)
   at org.apache.fop.render.intermediate.IFUtil.setupFonts(IFUtil.java:170)
   at 
 org.apache.fop.render.intermediate.IFRenderer.setupFontInfo(IFRenderer.java:187)
   at org.apache.fop.area.RenderPagesModel.init(RenderPagesModel.java:75)
   at org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:135)
   at org.apache.fop.area.AreaTreeHandler.init(AreaTreeHandler.java:105)
   at 
 org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:350)
   at org.apache.fop.fo.FOTreeBuilder.init(FOTreeBuilder.java:107)
   at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:104)
   at org.apache.fop.apps.Fop.init(Fop.java:78)
   at org.apache.fop.apps.FOUserAgent.newFop(FOUserAgent.java:179)
   at org.apache.fop.apps.FopFactory.newFop(FopFactory.java:240)
 {code}
 The same exception is thrown for other variants of the font (bold, italic, 
 etc).
 Note that this font can be downloaded freely from http://font.ubuntu.com/
 The latest version of the font is 0.80, and that is what I have installed on 
 my system.



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

[jira] [Updated] (FOP-2494) Unable to use Ubuntu Mono Font

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2494:
--
Attachment: output.pdf
patch.diff

I've attached the patch and will apply this shortly. I've also attached a 
document showing all the ubuntu fonts embedded in a document to show they're 
working.

 Unable to use Ubuntu Mono Font
 --

 Key: FOP-2494
 URL: https://issues.apache.org/jira/browse/FOP-2494
 Project: FOP
  Issue Type: Bug
  Components: font/opentype
Affects Versions: 2.0
 Environment: Ubuntu 14.04, Java 8u45
Reporter: Harshad
Assignee: Robert Meyer
 Attachments: output.pdf, patch.diff


 I want to use the Ubuntu Mono font, which is installed on my system. But FOP 
 throws an exception when it is auto-detecting the fonts:
 {code}
 Unable to load font file: 
 file:/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-R.ttf
 java.lang.ArrayIndexOutOfBoundsException: 1047

   at org.apache.fop.fonts.truetype.OpenFont.readPostScript(OpenFont.java:1320)
   at org.apache.fop.fonts.truetype.OpenFont.readFont(OpenFont.java:736)
   at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:109)
   at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:93)
   at org.apache.fop.fonts.FontLoader.getFont(FontLoader.java:124)
   at org.apache.fop.fonts.FontLoader.loadFont(FontLoader.java:108)
   at 
 org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:254)
   at org.apache.fop.fonts.FontAdder.add(FontAdder.java:63)
   at 
 org.apache.fop.fonts.FontDetectorFactory$DefaultFontDetector.detect(FontDetectorFactory.java:97)
   at org.apache.fop.fonts.FontManager.autoDetectFonts(FontManager.java:229)
   at 
 org.apache.fop.fonts.DefaultFontConfigurator.configure(DefaultFontConfigurator.java:82)
   at 
 org.apache.fop.render.PrintRendererConfigurator.getCustomFontCollection(PrintRendererConfigurator.java:147)
   at 
 org.apache.fop.render.PrintRendererConfigurator.setupFontInfo(PrintRendererConfigurator.java:127)
   at org.apache.fop.render.intermediate.IFUtil.setupFonts(IFUtil.java:170)
   at 
 org.apache.fop.render.intermediate.IFRenderer.setupFontInfo(IFRenderer.java:187)
   at org.apache.fop.area.RenderPagesModel.init(RenderPagesModel.java:75)
   at org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:135)
   at org.apache.fop.area.AreaTreeHandler.init(AreaTreeHandler.java:105)
   at 
 org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:350)
   at org.apache.fop.fo.FOTreeBuilder.init(FOTreeBuilder.java:107)
   at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:104)
   at org.apache.fop.apps.Fop.init(Fop.java:78)
   at org.apache.fop.apps.FOUserAgent.newFop(FOUserAgent.java:179)
   at org.apache.fop.apps.FopFactory.newFop(FopFactory.java:240)
 {code}
 The same exception is thrown for other variants of the font (bold, italic, 
 etc).
 Note that this font can be downloaded freely from http://font.ubuntu.com/
 The latest version of the font is 0.80, and that is what I have installed on 
 my system.



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

[jira] [Commented] (FOP-2494) Unable to use Ubuntu Mono Font

[Robert Meyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649983#comment-14649983
 ] 

Robert Meyer commented on FOP-2494:
---

I've been investigating this and have found the method we were using to 
identify the number of character names in the post table was flawed. In the 
case of the UbuntuMono-R.ttf font there are 1296 characters. 258 of these come 
under the standard encoding whereas everything else should have an associated 
name in the table. Unfortunately what we were doing was to read the post table 
and use the glyph ID array to determine how many of those are greater than 258 
by looping through them. The problem here is the fact that the indexes aren't 
necessarily in a complete order. Therefore although we may count only 1046 
characters that are greater than 258, the index array may do the following:

1,2,3,5,6,7,9,10,11,12...etc

The maximum glyph ID in this case is 1315, which minus 258 is 1057. As such a 
fix for this will be to set the size of the Strings array (and subsequently 
read) upon the maximum glyph index taken from that set. It's a fairly simple 
fix and will post a patch and commit after I've done some further testing 
tomorrow.

 Unable to use Ubuntu Mono Font
 --

 Key: FOP-2494
 URL: https://issues.apache.org/jira/browse/FOP-2494
 Project: FOP
  Issue Type: Bug
  Components: font/opentype
Affects Versions: 2.0
 Environment: Ubuntu 14.04, Java 8u45
Reporter: Harshad
Assignee: Robert Meyer

 I want to use the Ubuntu Mono font, which is installed on my system. But FOP 
 throws an exception when it is auto-detecting the fonts:
 {code}
 Unable to load font file: 
 file:/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-R.ttf
 java.lang.ArrayIndexOutOfBoundsException: 1047

   at org.apache.fop.fonts.truetype.OpenFont.readPostScript(OpenFont.java:1320)
   at org.apache.fop.fonts.truetype.OpenFont.readFont(OpenFont.java:736)
   at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:109)
   at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:93)
   at org.apache.fop.fonts.FontLoader.getFont(FontLoader.java:124)
   at org.apache.fop.fonts.FontLoader.loadFont(FontLoader.java:108)
   at 
 org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:254)
   at org.apache.fop.fonts.FontAdder.add(FontAdder.java:63)
   at 
 org.apache.fop.fonts.FontDetectorFactory$DefaultFontDetector.detect(FontDetectorFactory.java:97)
   at org.apache.fop.fonts.FontManager.autoDetectFonts(FontManager.java:229)
   at 
 org.apache.fop.fonts.DefaultFontConfigurator.configure(DefaultFontConfigurator.java:82)
   at 
 org.apache.fop.render.PrintRendererConfigurator.getCustomFontCollection(PrintRendererConfigurator.java:147)
   at 
 org.apache.fop.render.PrintRendererConfigurator.setupFontInfo(PrintRendererConfigurator.java:127)
   at org.apache.fop.render.intermediate.IFUtil.setupFonts(IFUtil.java:170)
   at 
 org.apache.fop.render.intermediate.IFRenderer.setupFontInfo(IFRenderer.java:187)
   at org.apache.fop.area.RenderPagesModel.init(RenderPagesModel.java:75)
   at org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:135)
   at org.apache.fop.area.AreaTreeHandler.init(AreaTreeHandler.java:105)
   at 
 org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:350)
   at org.apache.fop.fo.FOTreeBuilder.init(FOTreeBuilder.java:107)
   at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:104)
   at org.apache.fop.apps.Fop.init(Fop.java:78)
   at org.apache.fop.apps.FOUserAgent.newFop(FOUserAgent.java:179)
   at org.apache.fop.apps.FopFactory.newFop(FopFactory.java:240)
 {code}
 The same exception is thrown for other variants of the font (bold, italic, 
 etc).
 Note that this font can be downloaded freely from http://font.ubuntu.com/
 The latest version of the font is 0.80, and that is what I have installed on 
 my system.



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

[jira] [Commented] (FOP-2494) Unable to use Ubuntu Mono Font

[Robert Meyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649996#comment-14649996
 ] 

Robert Meyer commented on FOP-2494:
---

I've spent a bit of time looking at this and have found that the method by 
which we set the size of the glyph strings array is flawed. In the case of the 
UbuntuMono-R.ttf font there are 1296 glyphs. The post table which is used to 
store the names of the characters with their associated glyph index. What we 
were doing was looping through the index array (which precedes the name array) 
and counting the number of glyphs with ID's greater than 258 (the number of 
glyphs in the default encoding). This would work fine if the glyph index array 
was always complete but in this case it's not e.g.

1,2,3,5,6,9,10,11,12 etc...

The maximum glyph ID in this font is 1315 which, minus 258, equals 1057 which 
is the actual number of names in the array. Because we were only counting them 
we only got 1046, hence the error. As such to fix this it's simply a case of 
setting the character name array to the maximum glyph ID found minus 258. I'll 
post a patch tomorrow after I have done some further testing.

 Unable to use Ubuntu Mono Font
 --

 Key: FOP-2494
 URL: https://issues.apache.org/jira/browse/FOP-2494
 Project: FOP
  Issue Type: Bug
  Components: font/opentype
Affects Versions: 2.0
 Environment: Ubuntu 14.04, Java 8u45
Reporter: Harshad
Assignee: Robert Meyer

 I want to use the Ubuntu Mono font, which is installed on my system. But FOP 
 throws an exception when it is auto-detecting the fonts:
 {code}
 Unable to load font file: 
 file:/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-R.ttf
 java.lang.ArrayIndexOutOfBoundsException: 1047

   at org.apache.fop.fonts.truetype.OpenFont.readPostScript(OpenFont.java:1320)
   at org.apache.fop.fonts.truetype.OpenFont.readFont(OpenFont.java:736)
   at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:109)
   at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:93)
   at org.apache.fop.fonts.FontLoader.getFont(FontLoader.java:124)
   at org.apache.fop.fonts.FontLoader.loadFont(FontLoader.java:108)
   at 
 org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:254)
   at org.apache.fop.fonts.FontAdder.add(FontAdder.java:63)
   at 
 org.apache.fop.fonts.FontDetectorFactory$DefaultFontDetector.detect(FontDetectorFactory.java:97)
   at org.apache.fop.fonts.FontManager.autoDetectFonts(FontManager.java:229)
   at 
 org.apache.fop.fonts.DefaultFontConfigurator.configure(DefaultFontConfigurator.java:82)
   at 
 org.apache.fop.render.PrintRendererConfigurator.getCustomFontCollection(PrintRendererConfigurator.java:147)
   at 
 org.apache.fop.render.PrintRendererConfigurator.setupFontInfo(PrintRendererConfigurator.java:127)
   at org.apache.fop.render.intermediate.IFUtil.setupFonts(IFUtil.java:170)
   at 
 org.apache.fop.render.intermediate.IFRenderer.setupFontInfo(IFRenderer.java:187)
   at org.apache.fop.area.RenderPagesModel.init(RenderPagesModel.java:75)
   at org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:135)
   at org.apache.fop.area.AreaTreeHandler.init(AreaTreeHandler.java:105)
   at 
 org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:350)
   at org.apache.fop.fo.FOTreeBuilder.init(FOTreeBuilder.java:107)
   at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:104)
   at org.apache.fop.apps.Fop.init(Fop.java:78)
   at org.apache.fop.apps.FOUserAgent.newFop(FOUserAgent.java:179)
   at org.apache.fop.apps.FopFactory.newFop(FopFactory.java:240)
 {code}
 The same exception is thrown for other variants of the font (bold, italic, 
 etc).
 Note that this font can be downloaded freely from http://font.ubuntu.com/
 The latest version of the font is 0.80, and that is what I have installed on 
 my system.



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

[jira] [Issue Comment Deleted] (FOP-2494) Unable to use Ubuntu Mono Font

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2494:
--
Comment: was deleted

(was: I've been investigating this and have found the method we were using to 
identify the number of character names in the post table was flawed. In the 
case of the UbuntuMono-R.ttf font there are 1296 characters. 258 of these come 
under the standard encoding whereas everything else should have an associated 
name in the table. Unfortunately what we were doing was to read the post table 
and use the glyph ID array to determine how many of those are greater than 258 
by looping through them. The problem here is the fact that the indexes aren't 
necessarily in a complete order. Therefore although we may count only 1046 
characters that are greater than 258, the index array may do the following:

1,2,3,5,6,7,9,10,11,12...etc

The maximum glyph ID in this case is 1315, which minus 258 is 1057. As such a 
fix for this will be to set the size of the Strings array (and subsequently 
read) upon the maximum glyph index taken from that set. It's a fairly simple 
fix and will post a patch and commit after I've done some further testing 
tomorrow.)

 Unable to use Ubuntu Mono Font
 --

 Key: FOP-2494
 URL: https://issues.apache.org/jira/browse/FOP-2494
 Project: FOP
  Issue Type: Bug
  Components: font/opentype
Affects Versions: 2.0
 Environment: Ubuntu 14.04, Java 8u45
Reporter: Harshad
Assignee: Robert Meyer

 I want to use the Ubuntu Mono font, which is installed on my system. But FOP 
 throws an exception when it is auto-detecting the fonts:
 {code}
 Unable to load font file: 
 file:/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-R.ttf
 java.lang.ArrayIndexOutOfBoundsException: 1047

   at org.apache.fop.fonts.truetype.OpenFont.readPostScript(OpenFont.java:1320)
   at org.apache.fop.fonts.truetype.OpenFont.readFont(OpenFont.java:736)
   at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:109)
   at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:93)
   at org.apache.fop.fonts.FontLoader.getFont(FontLoader.java:124)
   at org.apache.fop.fonts.FontLoader.loadFont(FontLoader.java:108)
   at 
 org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:254)
   at org.apache.fop.fonts.FontAdder.add(FontAdder.java:63)
   at 
 org.apache.fop.fonts.FontDetectorFactory$DefaultFontDetector.detect(FontDetectorFactory.java:97)
   at org.apache.fop.fonts.FontManager.autoDetectFonts(FontManager.java:229)
   at 
 org.apache.fop.fonts.DefaultFontConfigurator.configure(DefaultFontConfigurator.java:82)
   at 
 org.apache.fop.render.PrintRendererConfigurator.getCustomFontCollection(PrintRendererConfigurator.java:147)
   at 
 org.apache.fop.render.PrintRendererConfigurator.setupFontInfo(PrintRendererConfigurator.java:127)
   at org.apache.fop.render.intermediate.IFUtil.setupFonts(IFUtil.java:170)
   at 
 org.apache.fop.render.intermediate.IFRenderer.setupFontInfo(IFRenderer.java:187)
   at org.apache.fop.area.RenderPagesModel.init(RenderPagesModel.java:75)
   at org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:135)
   at org.apache.fop.area.AreaTreeHandler.init(AreaTreeHandler.java:105)
   at 
 org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:350)
   at org.apache.fop.fo.FOTreeBuilder.init(FOTreeBuilder.java:107)
   at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:104)
   at org.apache.fop.apps.Fop.init(Fop.java:78)
   at org.apache.fop.apps.FOUserAgent.newFop(FOUserAgent.java:179)
   at org.apache.fop.apps.FopFactory.newFop(FopFactory.java:240)
 {code}
 The same exception is thrown for other variants of the font (bold, italic, 
 etc).
 Note that this font can be downloaded freely from http://font.ubuntu.com/
 The latest version of the font is 0.80, and that is what I have installed on 
 my system.



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

[jira] [Updated] (FOP-2499) [PATCH] PDF/UA warnings for nested elements

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2499:
--
Summary: [PATCH] PDF/UA warnings for nested elements  (was: PDF/UA warnings 
for nested elements)

 [PATCH] PDF/UA warnings for nested elements
 ---

 Key: FOP-2499
 URL: https://issues.apache.org/jira/browse/FOP-2499
 Project: FOP
  Issue Type: Bug
Affects Versions: trunk
Reporter: Thanasis Giannimaras
 Attachments: after.pdf, before.pdf, fop.xconf, pdfua.patch, test.fo


 PDF with nested elements (and PDF/UA mode enabled) are giving out warnings 
 when validated by 
 http://www.access-for-all.ch/en/pdf-lab/pdf-accessibility-checker-pac.html 
 (Inappropriate use of a type structure element warnings). This approach 
 tries to solve the issue, by renaming the outermost structure element into a 
 grouping element of type DIV.
 To notice the warning try to validate before pdf with accessibility checker 
 mentioned above



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

[jira] [Updated] (FOP-2486) Soft font support for TrueType fonts in PCL

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2486:
--
Attachment: softfonts.pcl
rasterized.pcl

Attached two examples of before and after the changes. 

 Soft font support for TrueType fonts in PCL
 ---

 Key: FOP-2486
 URL: https://issues.apache.org/jira/browse/FOP-2486
 Project: FOP
  Issue Type: Improvement
  Components: renderer/pcl
Affects Versions: trunk
Reporter: Robert Meyer
 Fix For: trunk

 Attachments: patch.diff, rasterized.pcl, softfonts.pcl


 Currently all fonts (except a limited set of native fonts) are rastered for 
 PCL output. This has the problem of the documents being large in size and 
 should FOP be used in the cloud, rendering to PCL would not be possible as 
 it's using AWT.
 This patch in part resolves this problem by converting TrueType fonts to PCL 
 soft fonts. This allows the size to be much smaller and has been a standard 
 feature since PCL 5.



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

[jira] [Updated] (FOP-2486) [PATCH] Soft font support for TrueType fonts in PCL

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2486:
--
Description: 
Currently all fonts (except a limited set of native fonts) are rastered for PCL 
output. This has the problem of the documents being large in size and should 
FOP be used in the cloud, rendering to PCL would not be possible as it's using 
AWT.

This patch in part resolves this problem by converting TrueType fonts to PCL 
soft fonts. This allows the size to be much smaller and has been a standard 
feature since PCL 5.

[EDIT] For all other fonts which are not TrueType it will still revert back to 
being rasterized. It will currently default to using soft fonts for TrueType 
fonts but this can overriden by using text-renderingbitmap/text-rendering.

  was:
Currently all fonts (except a limited set of native fonts) are rastered for PCL 
output. This has the problem of the documents being large in size and should 
FOP be used in the cloud, rendering to PCL would not be possible as it's using 
AWT.

This patch in part resolves this problem by converting TrueType fonts to PCL 
soft fonts. This allows the size to be much smaller and has been a standard 
feature since PCL 5.


 [PATCH] Soft font support for TrueType fonts in PCL
 ---

 Key: FOP-2486
 URL: https://issues.apache.org/jira/browse/FOP-2486
 Project: FOP
  Issue Type: Improvement
  Components: renderer/pcl
Affects Versions: trunk
Reporter: Robert Meyer
 Fix For: trunk

 Attachments: patch.diff, rasterized.pcl, softfonts.pcl


 Currently all fonts (except a limited set of native fonts) are rastered for 
 PCL output. This has the problem of the documents being large in size and 
 should FOP be used in the cloud, rendering to PCL would not be possible as 
 it's using AWT.
 This patch in part resolves this problem by converting TrueType fonts to PCL 
 soft fonts. This allows the size to be much smaller and has been a standard 
 feature since PCL 5.
 [EDIT] For all other fonts which are not TrueType it will still revert back 
 to being rasterized. It will currently default to using soft fonts for 
 TrueType fonts but this can overriden by using 
 text-renderingbitmap/text-rendering.



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

RE: [VOTE] Merge Temp_MergeTaggedPDF to trunk

[Robert Meyer]

Bit late but +1

 Date: Wed, 3 Jun 2015 09:22:18 +0200
 Subject: Re: [VOTE] Merge Temp_MergeTaggedPDF to trunk
 From: psancho@gmail.com
 To: fop-dev@xmlgraphics.apache.org
 
 Hi,
 
 +1
 
 2015-06-02 17:12 GMT+02:00 Simon Steiner simonsteiner1...@gmail.com:
  Hi,
 
 
 
  Vote to merge branch to pdf-plugin trunk.
 
 
 
  Allows the merging of Tagged PDF. In order to use this feature,
  accessibility must be enabled in the configuration file and the source pdf
  must be accessible (tagged).
 
 
 
  The vote will last 5 working days, ending 9/2/2015.
 
 
 
  https://issues.apache.org/jira/browse/FOP-2436
 
  http://svn.apache.org/viewvc/xmlgraphics/fop-pdf-images/branches/Temp_MergeTaggedPDF/
 
 
 
  Here is my vote: +1
 
 
 
  Thanks
 
 
 
 -- 
 pascal
  

RE: [VOTE] Release XML Graphics FOP 2.0

[Robert Meyer]

+1

 Date: Thu, 21 May 2015 15:23:22 +0100
 From: bowditch_ch...@hotmail.com
 To: gene...@xmlgraphics.apache.org
 CC: fop-dev@xmlgraphics.apache.org
 Subject: Re: [VOTE] Release XML Graphics FOP 2.0
 
 +1. Thanks Simon
 
 On 21/05/2015 14:21, Simon Steiner wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Hi,
 
  This is a vote to release XML Graphics FOP 2.0.
 
  Artifacts can be found there:
  https://people.apache.org/~ssteiner/fop-2.0
 
  The release is signed with the key:
  https://people.apache.org/~ssteiner/KEYS
 
  The vote will end on 28/5/2015
 
  +1 from me.
 
  Thanks
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1
 
  iQIcBAEBAgAGBQJVXduFAAoJEFuT8d98223qUtYP/3NaJGfuElP3RyKQFW71J7Fz
  M/RXeiHQrsxrEg0MW9HXnzGLDnqlmUiFHIs3EHU1vVBy2kBVD0OO42Eh68FqcwWS
  maqzGQHGKtyKhxS52X3mb/nSv8N/php1PlvqJbbNYl4KqMhT9GhOhilhtIXKD+Z5
  KMIkDFkFPcN++H65CSMn3ynmR3XzUZffzrGwpjIBIj7gP2zW6ZJ5qM/E05k/90rd
  QsRT/UYBN3bGolZp3oOHLnB/H6KwGsHOfVmrxaFwhLGJnqpaBgYe2+dQ6I50Twx9
  tlJhtv0/7nAq/Py/vPQj2kTDC7XV0pQhTFbhnhlJ4smk21G9XRV12nKlQtRmiLqp
  Yrmn8HPqSia6UZ2zl5ObDMVLjc+vnsUzkqa8ONkSmUW23XziF3anojaf4Hb8ENNg
  8k8KpVQU1z1uOrPYxQDK9ajJPmlUocOpfVTBWyzyL39bhmJmx479TSViYGy2j29v
  9JXN3r36tKfxxepT2u0npLPdqPi1MrOhUdMdFNuxZdIG9W2KgYDNqvaK4dTmYBT+
  kghoQzM8Ega8bKPe+mMmoYsAEPo9iftnellcLKk7dBp6SRBVOdPLa8K+OKF1UAqW
  OrOS4ahlkRk3k0cl/SdSBfnEQcclVD6WenNZA2T09RELx8riWnVuRjmu+GSLhgzx
  Vs3s8aMGH8xBEN0SEv+l
  =t6hJ
  -END PGP SIGNATURE-
 
 
 
 
  

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

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2460:
--
Description: 
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

  was:
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. The font has been 
attached.

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.


 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] [Issue Comment Deleted] (FOP-2460) Subsetting OTF font leads to PDF errors when viewing / incorrect characters

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2460:
--
Comment: was deleted

(was: Attached the font in question.)

 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] [Updated] (FOP-2460) Subsetting OTF font leads to PDF errors when viewing / incorrect characters

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2460:
--
Attachment: (was: VilleroyBoch-Regular.otf)

 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. The font has 
 been attached.
 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.



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

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

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2460:
--
Attachment: VilleroyBoch-Regular.otf

Attached the font in question.

 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
 Attachments: VilleroyBoch-Regular.otf


 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. The font has 
 been attached.
 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.



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

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

[Robert Meyer (JIRA)]

Robert Meyer created FOP-2460:
-

 Summary: 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. The font has been 
attached.

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.



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

Re: Problem with FOP configuration auto detect

[Robert Meyer]

I'm guessing the omission of the starting fonts tag was a mistake when 
writing your message? If so do you get any messages going to the standard 
output? Usually something like “Font not found ‘font’, Substituting with …”. 
How are you referencing the font from your FO file?


Robert





From: Fabrice MAUPIN
Sent: ‎Friday‎, ‎3‎ ‎April‎ ‎2015 ‎11‎:‎01
To: fop-dev@xmlgraphics.apache.org






Hello everybody,

I use the FOP engine to generate PDF File in my JavaFX program, ok.

This is my FOP configuration file :

?xml version=1.0 encoding=UTF-8?

 

fop version=1.0

   renderers

 renderer mime=application/pdf

   auto-detect /

/fonts

 /renderer

   /renderers

/fop

For information I use the Calibri Font (a system Font) to generate the PDF File.

When I execute my program with Eclipse, no problem the PDF file is correctly 
generated and  the Calibri Font is embedded into this file.

I build and package my program  : what generates one executable application.

When I execute my application, there is a problem : the PDF file is generated 
but the Calibri Font is not embedded into this file !

Any ideas ?

Thank you in advance.

Regards,

Fabrice

 

 

 





  
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast. 
www.avast.com

RE: [VOTE] Merge Temp_MergeTaggedPDF to trunk

[Robert Meyer]

+1

 Date: Tue, 10 Feb 2015 12:14:32 +
 From: bowditch_ch...@hotmail.com
 To: fop-dev@xmlgraphics.apache.org
 Subject: Re: [VOTE] Merge Temp_MergeTaggedPDF to trunk
 
 +1
 
 Chris
 
 On 10/02/2015 11:04, Simon Steiner wrote:
 
  Hi,
 
  Thanasis Giannimaras provided patch to merge Tagged PDF for pdf plugin 
  and small patch for fop.
 
  Known Limitations :
 
  - Only PDF with marked-content sequences in the page content stream 
  are supported. Marked-content sequences in content stream other than 
  the content stream of the page are not supported.
 
  - Repeated headers and footers are not completely supported. Example: 
  2-page pdf including table that spans both pages with repeated header. 
  If you merge the second page, the table header will be visible in the 
  pdf but the reader will ignore it (same principle applies for repeated 
  footers).
 
  In order to use this feature, accessibility must be enabled in the 
  configuration file and the source pdf must be accessible (tagged).
 
  The vote will last 5 working days, ending next Tuesday.
 
  https://issues.apache.org/jira/browse/FOP-2436
 
  https://svn.apache.org/repos/asf/xmlgraphics/fop-pdf-images/branches/Temp_MergeTaggedPDF
 
  Here is my vote: +1
 
  Thanks
 
 
  

RE: [VOTE] merge branches/Temp_BasicSideFloats to trunk

[Robert Meyer]

Really nice work Luis. I think this feature has been asked for quite a few 
times so it's excellent to have this and from your examples seems to work 
really well.
+1
Robert

 Date: Thu, 27 Nov 2014 12:22:15 +
 From: bowditch_ch...@hotmail.com
 To: fop-dev@xmlgraphics.apache.org
 Subject: Re: [VOTE] merge branches/Temp_BasicSideFloats to trunk
 
 Hi Luis,
 
 Great work. +1 from me.
 
 Thanks,
 
 Chris
 
 On 25/11/2014 14:41, Luis Bernardo wrote:
 
  I would like to merge the branch branches/Temp_BasicSideFloats to 
  trunk. The branch has a implementation of side floats that uses the 
  same approach used when handling change in IPD across pages.
 
  These are the known limitations:
  -- the clear fo:float attribute is ignored; only the float attribute 
  (left or right) is used
  -- overlapping of floats in the Y is not handled (even in the case 
  there would not be overlap in the X direction)
  -- floats that extend beyond the body region are not properly handled 
  and will overflow past the edge of the region
  -- if a float extends to bottom of the body region and there are 
  footnotes in the page the float may overlap with the footnote region
  -- floats next to a table are not supported unless the start and end 
  of the table happens in between the start and end of the float
 
  Examples can be found in the thread with subject RFC: basic side 
  floats in this mailing list.
 
  To follow due process and since this will be a new major feature I am 
  launching a vote.
 
  Please vote or report a bug before the end of Monday UTC, December 1st.
 
 
  

RE: FOP Release Automation

[Robert Meyer]

To use this utility it will require modification of our own Perl modules found 
on the FOP SVN site. Whether that requires just a change to the patterns 
(path.pm file) or the more complicated requirement of writing our own pattern 
subroutine (in the view.pm) I am not yet sure. Unfortunately though I'll have 
to park this as I currently have no more time I can spend on it but as I said 
will keep my eye on it and let you know if anything progresses.

In the meantime I am guessing there will be a vote to release fairly soon which 
will result in the documentation needing to be updated.

 Subject: Re: FOP Release Automation
 From: the.webmaes...@gmail.com
 Date: Tue, 15 Jul 2014 07:53:19 -0700
 To: fop-dev@xmlgraphics.apache.org
 
 On Jul 15, 2014, at 7:46 AM, Glenn Adams gl...@skynav.com wrote:
  I suppose it depends on whether or not we need to hack perl to use the 
  facility. If there is any alternative that doesn't use perl, then that 
  would be preferable.
  
  Frankly, I've never been happy with the new MD based documentation, though 
  Clay has spent an inordinate amount of time tweaking it.
 
 Yeah... It's not my favorite either, but at least edits are pretty quick, 
 saved to SVN and we've got a solution to incorporate javadoc, etc. 
 
 In the meantime, please let me know when we're ready to update the 
 documentation for the Release. It doesn't take me very long to go through the 
 code to make these types of batch edits. I'm good at this, and who knows, I 
 might even spend the time to write some bash script to help us with the 
 deployment! (you don't have anything against BASH, do ya Glenn?) :-p) (I 
 think that's how to write a smiley with a tongue-in-cheek? :-D)
  

RE: [VOTE] Merge Temp_FontMerging to trunk

[Robert Meyer]

+1

Thanks,

Robert Meyer

Date: Fri, 27 Jun 2014 00:12:30 +0100
From: lmpmberna...@gmail.com
To: fop-dev@xmlgraphics.apache.org
Subject: Re: [VOTE] Merge Temp_FontMerging to trunk


  

  
  


  

  I tested the code with some examples from a weekly newsletter that
  I receive -- this is a good example because the newsletter is
  always created using the same template and the same set of fonts
  (with a few exceptions).

  

  The code worked mostly well but the output was not perfect with
  some of the fonts, where some glyphs were missing of misplaced
  (causing overlap). So there is still work to be done.
  Nevertheless, and since the feature is disabled by default, I
  think there is value in merging this to trunk because it does work
  in many situations. Besides I don't know if the problem is due to
  this patch or to PDFBox. Hence +1.

  

  Note: I will send the examples directly to Simon.

  

  On 6/20/14, 12:23 PM, Simon Steiner wrote:



  
  
  
  
Hi,
 
I have been working on merging fonts inside
  pdf external graphic using the pdf-plugin. The feature is
  disabled by default and can be enabled using fop.xconf:
fop version=1.0
  renderers
renderer mime=application/pdf
 
  merge-fontstrue/merge-fonts
/renderer
  /renderers
/fop
 
It is using pdfbox 2.0 snapshot which
  requires Java 6 or later so you vote needs to agree to end
  support for Java 5 on trunk.
 
It is supporting fonts of type CFF,
  Truetype, CID and Type1.
 
The vote will last 5 working days, ending
  next Friday.
 
https://issues.apache.org/jira/browse/FOP-2302

https://svn.apache.org/repos/asf/xmlgraphics/fop-pdf-images/branches/Temp_FontMerging

https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_FontMerging
 
Here is my vote: +1
 
Thanks
  


  

RE: PDFBox

[Robert Meyer]

Hi,

I managed to find Chris' original comment:

http://mail-archives.apache.org/mod_mbox/xmlgraphics-general/201310.mbox/%3cblu0-smtp152f66b6dfcfd8695df00eefb...@phx.gbl%3E

I think as you say having two versions makes sense. I would be in favour of 
that as I think FOP should be able to look to the future. Who knows, maybe we 
should just skip 1.6 and head straight to 1.8 ;-)

Regards,

Robert Meyer

 Date: Wed, 18 Jun 2014 17:17:17 +0200
 Subject: Re: PDFBox
 From: psancho@gmail.com
 To: fop-dev@xmlgraphics.apache.org
 
 IIRC, Chris arged that it was hard to upgrade JVM on certain Unix 
 environments.
 I didn't found the discussion, but probably was on this list, 2 or 3
 monthes ago.
 
 That said, you bring some new arguments that have to be taken into account.
 IMHO, that means that we should provide 2 FOP versions:
 
  - fop 1.x, keeping 1.5 Java support,
  - new fop 2.x, with 1.6 (or earlier?) Java support
 
 Note that today we provide 2 FOP versions (current -- 1.1, and previous -- 
 1.0)
 I think there is no reason to keep both current and previous version
 materials on the website. But this will make sense if we have to
 provide wider range platform support. (thought a little out of topic
 here...)
 
 2014-06-18 15:20 GMT+02:00 Simon Steiner simonsteiner1...@gmail.com:
  Hi,
 
 
 
  As part of the work on merging fonts in PDFs:
 
  https://issues.apache.org/jira/browse/FOP-2302
 
 
 
  I am using PDFBox 2.0 instead of 1.8 since that version has switched from
  AWT to its own fontfile parser/renderer to give better support for different
  fonts.
 
 
 
  This version requires Java 6 but FOP is currently supporting Java 5, does
  Java 5 still need to be supported?
 
 
 
  Thanks
 
 
 
 
 
 -- 
 pascal
  

RE: FOP Release Automation

[Robert Meyer]

Hi,

After investigating your suggestions Clay I have found that svn-hooks can't be 
used for the purpose we require unfortunately as it may lead to problems with 
how SVN operates and also may have some unexpected results with files being 
committed. This is stated in the documentation under Creating Repository 
Hooks highlighted in the warning red box further down:

http://www-inst.eecs.berkeley.edu/~cs61b/fa09/docs/svn-book-html-chunk/svn.reposadmin.create.html

Pascal, I agree that the process is fairly straightforward, but I have been 
asked to automate this further so am just looking into ideas presently.

I think a possible way forward then would be to use your suggestion Pascal of 
placing the versioned docs for the site inside the FOP repository for their 
associated version. These can then be referenced using the svn-externals from 
the main site repository.

In addition to this, the main site files (which would need to be updated) could 
contain tags for the last three versions which would be replaced using Clay's 
markdown pre-processor suggestion. The pre-processor would replace the tags 
with values stored in a properties file in the main site repository.

To create a release, the user would need to update the svn-external references 
to account for the new version and update the properties file for tag 
replacement. When the properties file is pushed it will be read by the custom 
markdown pre-processor and display the new version when rendered.

Those two stages could be done using a single script to simplify things 
further, but the main complication is getting the markdown pre-processor 
working. From looking at this page:

http://www.apache.org/dev/cmsref.html#markdown

I am guessing we use PyPy (Python Markdown) which supports extensions, so I 
will look at this shortly to try out a small example and investigate the 
feasibility of doing this. There is also the matter of updating the versioned 
documents for each FOP when a new version is released, but maybe this could be 
done with the pre-processor as well.

Anyway, let me know what you think.

Regards,

Robert
  

RE: FOP Release Automation

[Robert Meyer]

I'll definitely look into those. I'm going to be away on holiday now for a week 
or so but will continue once I get back.

Many thanks!

Robert

From: Clay Leedsmailto:the.webmaes...@gmail.com
Sent: ‎5/‎30/‎2014 17:24
To: Apache FOPmailto:fop-dev@xmlgraphics.apache.org
Subject: Re: FOP Release Automation

Agreed, ‘some’ people wouldn’t be happy with that. ;-)

I wonder if the CMS Web interface could be extended to allow for a few keywords 
like FOP_VERSION, FOP_REVISION, FOP_BRANCH, etc.

The CMS tool's WYSIWYG interface indicates it uses the Wysiwym MarkDown Editor, 
which is extensible:

https://web.archive.org/web/20110121060932/http://wmd-editor.com/

(site’s down  hasn’t been updated since 2011)...

or

https://code.google.com/p/wmd/

We might still need to do some ANT hanky panky, but at least if we could 
leverage WMD’s extensibility it would help us get where we’re trying to go?

Clay

On May 30, 2014, at 7:19 AM, Robert Meyer rme...@hotmail.co.uk wrote:
 Hi,

 I like the simplicity of your idea, but the web interface is not so easy to 
 dismiss unfortunately.

 If you do have a copy with those tags in, if any changes are made on the web 
 interface then that copy would become out of date.

 We could always shutdown the web interface, but I don't think too many people 
 would be happy with that ;-)

 Regards,

 Robert

 From: simonsteiner1...@gmail.com
 To: fop-dev@xmlgraphics.apache.org
 Subject: RE: FOP Release Automation
 Date: Fri, 30 May 2014 14:48:15 +0100

 Hi,

 Simple way is to store docs inside fop repo:

 Fop/docs/index.markdown

 Inside markdown file you reference ant properties eg:
 ${version}

 Then you call which does ant expandproperties and calls markdown to html tool:
 ant docs

 Then you call which does a zip, scp and unzip of html files to web server:
 ant upload-docs

 This method doesn’t support web interface of editing files but I don’t see 
 how this is really needed.
 If I submit a patch to fop it should also contain doc changes rather than 
 having separate repo and patch for that.

 Thanks

 From: Robert Meyer [mailto:rme...@hotmail.co.uk]
 Sent: 30 May 2014 14:05
 To: fop-dev@xmlgraphics.apache.org
 Subject: RE: FOP Release Automation

 Hi,

 After investigating your suggestions Clay I have found that svn-hooks can't 
 be used for the purpose we require unfortunately as it may lead to problems 
 with how SVN operates and also may have some unexpected results with files 
 being committed. This is stated in the documentation under Creating 
 Repository Hooks highlighted in the warning red box further down:

 http://www-inst.eecs.berkeley.edu/~cs61b/fa09/docs/svn-book-html-chunk/svn.reposadmin.create.html

 Pascal, I agree that the process is fairly straightforward, but I have been 
 asked to automate this further so am just looking into ideas presently.

 I think a possible way forward then would be to use your suggestion Pascal of 
 placing the versioned docs for the site inside the FOP repository for their 
 associated version. These can then be referenced using the svn-externals from 
 the main site repository.

 In addition to this, the main site files (which would need to be updated) 
 could contain tags for the last three versions which would be replaced using 
 Clay's markdown pre-processor suggestion. The pre-processor would replace the 
 tags with values stored in a properties file in the main site repository.

 To create a release, the user would need to update the svn-external 
 references to account for the new version and update the properties file for 
 tag replacement. When the properties file is pushed it will be read by the 
 custom markdown pre-processor and display the new version when rendered.

 Those two stages could be done using a single script to simplify things 
 further, but the main complication is getting the markdown pre-processor 
 working. From looking at this page:

 http://www.apache.org/dev/cmsref.html#markdown

 I am guessing we use PyPy (Python Markdown) which supports extensions, so I 
 will look at this shortly to try out a small example and investigate the 
 feasibility of doing this. There is also the matter of updating the versioned 
 documents for each FOP when a new version is released, but maybe this could 
 be done with the pre-processor as well.

 Anyway, let me know what you think.

 Regards,

 Robert

[jira] [Commented] (FOP-2354) [PATCH] Subset support for Type 1 fonts

[Robert Meyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14007217#comment-14007217
 ] 

Robert Meyer commented on FOP-2354:
---

Patch applied: http://svn.apache.org/viewvc?view=revisionrevision=1597112

 [PATCH] Subset support for Type 1 fonts
 ---

 Key: FOP-2354
 URL: https://issues.apache.org/jira/browse/FOP-2354
 Project: Fop
  Issue Type: New Feature
  Components: fonts
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
 Fix For: trunk

 Attachments: c0419bt_.pfb, fop.xconf, patch.diff, patch.diff, test.fo


 This patch adds subsetting support to Type 1 fonts. Currently the only two 
 supported output formats for this are PDF and Postscript.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (FOP-2354) [PATCH] Subset support for Type 1 fonts

[Robert Meyer (JIRA)]

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

Robert Meyer resolved FOP-2354.
---

Resolution: Fixed

 [PATCH] Subset support for Type 1 fonts
 ---

 Key: FOP-2354
 URL: https://issues.apache.org/jira/browse/FOP-2354
 Project: Fop
  Issue Type: New Feature
  Components: fonts
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
 Fix For: trunk

 Attachments: c0419bt_.pfb, fop.xconf, patch.diff, patch.diff, test.fo


 This patch adds subsetting support to Type 1 fonts. Currently the only two 
 supported output formats for this are PDF and Postscript.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

FOP Release Automation

[Robert Meyer]

Hi All,

I've been asked to look at a way to automate the FOP release process with 
regards the website documentation. At the moment every new release requires the 
following:

1) Download the site from SVN
2) Copy the folder containing the latest version's markdown files (1.1 for 
example) and rename to the new version
3) Go through all the files manually and update all the references from the old 
to the new version
4) Update any markdown files in the main directory with regard to the current 
and previous versions.
5) Delete the oldest version folder as we need only mantain the last 3.
6) Check and resubmit all files back to SVN

My initial thought would to have a master copy in a separate directory. That 
copy would contain a tag in place where the version is given which could be 
substituted by a script of some kind (ant has a facility to do this). The ant 
script would also perform all of the above tasks so the only thing left to the 
user will be to check the output and push the new files. The problem I have 
with this is that SVN is not the only way in which the files can be edited as 
there is the web interface. If someone were to edit the files from there, the 
master copies would become out of date and worse, if someone were to perform a 
release it would overwrite all those changes.

I've been recommended to look at markdown extensions but if anyone else has any 
ideas on the best way to go about this it would be much appreciated.

Thanks,

Robert Meyer
  

RE: [VOTE] Add Type 1 subset support

[Robert Meyer]

Hi,

Thanks all for voting. The vote has now concluded and has passed with 6 +1 
votes.

I will look at merging this patch with trunk and update the necessary 
documentation soon.

To reiterate, the default for Type 1 fonts will be to fully embed unless 
explicitly stated otherwise in the configuration.

Regards,

Robert Meyer

 Date: Tue, 20 May 2014 11:26:23 +0100
 From: vhenneb...@gmail.com
 To: fop-dev@xmlgraphics.apache.org
 Subject: Re: [VOTE] Add Type 1 subset support
 
 The code has certainly improved since last time. Now glyph names are
 being used directly, without any round-trip to Unicode code point and
 back to character code. This is great as it simplifies the code quite
 a bit and makes it more robust.
 
 The PostScript parser hasn’t changed so my concerns about its resilience
 against ill-formed fonts remain. Also, while memory usage has improved
 a bit, there still seems to be unwarranted copying of byte arrays here
 and there. For example, the creation of the encrypted portion could be
 made on the fly by wrapping the output stream into a FilterOutputStream.
 
 Overall there is room for further streamlining and simplifying the code.
 But since it’s an optional feature I suppose there is no harm in letting
 interested users experiment with it. So I’ll vote +1.
 
 Thanks,
 Vincent
 
 
 On 14/05/14 10:22, Robert Meyer wrote:
  Hi All,
 
  Following on from the last failed vote for adding Type 1 subset support, I 
  have now put forward a modified patch and am ready to try this again. The 
  patch went up on Monday to address the issues and comments made by Vincent 
  and Luis. This vote will last 5 working days and will finish next Wednesday 
  at the same time.
 
  As always if you have any concerns or find anything please let me know. If 
  they are small I will try and address the issue before the vote is 
  finalized in order to avoid repeating this again. Please note that all type 
  1 fonts will default to full embedding unless you use the 
  embedding-mode=subset as per one of the recommendations from the last 
  vote.
 
  Here is my vote: +1
 
  Best Regards,
 
  Robert Meyer
  
 
  

[VOTE] Add Type 1 subset support

[Robert Meyer]

Hi All,

Following on from the last failed vote for adding Type 1 subset support, I have 
now put forward a modified patch and am ready to try this again. The patch went 
up on Monday to address the issues and comments made by Vincent and Luis. This 
vote will last 5 working days and will finish next Wednesday at the same time.

As always if you have any concerns or find anything please let me know. If they 
are small I will try and address the issue before the vote is finalized in 
order to avoid repeating this again. Please note that all type 1 fonts will 
default to full embedding unless you use the embedding-mode=subset as per one 
of the recommendations from the last vote.

Here is my vote: +1

Best Regards,

Robert Meyer
  

[jira] [Updated] (FOP-2354) [PATCH] Subset support for Type 1 fonts

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2354:
--

Attachment: patch.diff

New patch for adding Type 1 subset support. Various changes include:
- Name resolution improvements
- Memory efficiency improvements
- Some re-factoring
- Default is now not to subset

I'll start a vote in a couple of days to give everyone a chance to look at it 
if they get a chance.

 [PATCH] Subset support for Type 1 fonts
 ---

 Key: FOP-2354
 URL: https://issues.apache.org/jira/browse/FOP-2354
 Project: Fop
  Issue Type: New Feature
  Components: fonts
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
 Fix For: trunk

 Attachments: c0419bt_.pfb, fop.xconf, patch.diff, patch.diff, test.fo


 This patch adds subsetting support to Type 1 fonts. Currently the only two 
 supported output formats for this are PDF and Postscript.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FOP-2354) [PATCH] Subset support for Type 1 fonts

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2354:
--

Attachment: patch.diff

 [PATCH] Subset support for Type 1 fonts
 ---

 Key: FOP-2354
 URL: https://issues.apache.org/jira/browse/FOP-2354
 Project: Fop
  Issue Type: New Feature
  Components: fonts
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
 Fix For: trunk

 Attachments: c0419bt_.pfb, fop.xconf, patch.diff, patch.diff, test.fo


 This patch adds subsetting support to Type 1 fonts. Currently the only two 
 supported output formats for this are PDF and Postscript.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FOP-2354) [PATCH] Subset support for Type 1 fonts

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2354:
--

Attachment: (was: patch.diff)

 [PATCH] Subset support for Type 1 fonts
 ---

 Key: FOP-2354
 URL: https://issues.apache.org/jira/browse/FOP-2354
 Project: Fop
  Issue Type: New Feature
  Components: fonts
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
 Fix For: trunk

 Attachments: c0419bt_.pfb, fop.xconf, patch.diff, patch.diff, test.fo


 This patch adds subsetting support to Type 1 fonts. Currently the only two 
 supported output formats for this are PDF and Postscript.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

RE: [VOTE] Applying the Type 1 subset patch

[Robert]

Hi All,

Thanks for your votes and testing the code. From reading the feedback I don't 
think it would be the right option to simply modify and push it through as a 
disabled by default feature and so will register Vincent's vote as a -1 and 
look to address his and Luis's concerns.

Regarding one of the points Vincent made about the Postscript Parser, the 
matter is complicated by the nature of the code being parsed. A traditional 
method of parsing a file would be to scan for tokens (using maybe a String 
Tokenizer) and then send those to the interpreter. Unfortunately Postscript 
Type 1 fonts have a mixture of regular code and binary data (Subroutines / 
CharString data). If a traditional Tokenizer were to be used the data would 
inevitably become corrupted. The alternative I chose balances the need to keep 
these sections intact and accessible whilst providing the means to parse tokens 
and interpret them as part of an expandable solution. There may be other 
solutions but any parser which would be written would need to do so on a byte 
by byte basis as opposed to feeding it in and expecting a list of tokens. I am 
going to leave the current implementation as it is but will look to address the 
Bakoma font problem Luis found and perform more extensive testing with other 
Type 1 fonts to try and prevent any further issues.

I will look to address the other issues you both raised in the coming weeks.

Thanks for your input.

Robert Meyer

Date: Mon, 17 Mar 2014 00:19:18 +
From: lmpmberna...@gmail.com
To: fop-dev@xmlgraphics.apache.org
Subject: Re: [VOTE] Applying the Type 1 subset patch


  

  
  


  I performed some further tests, still on Mac, but with a couple of
  ghostscript type1 fonts, which are probably the same one finds in
  Linux.

  

  The test was successful in that the output looked good (for the
  record I has some unpredictable output between different runs
  which I could not reliably reproduce so I attribute that to an
  environment issue, maybe the .fop directory).

  

  My example included characters not present in the font. Instead of
  # for the missing glyph I got z (see example attached), which
  probably is not intended (i.e., looks like a bug). I was also
  expecting that Adobe would indicate that the fonts are subset but
  it doesn't but this could be a wrong expectation (the subset file
  is nevertheless considerably smaller -- 64KB versus 219 KB).

  

  Finally I ran a simple performance test. With the patched code
  (that produces subset) the time was 175 msecs. With the current
  trunk 83 msecs.

  

  So I think the suggestion that Vincent put forward to not make
  subset the default for type1 makes sense for now. I think this
  requires a new vote with a new patch.

  

  On 3/12/14, 12:06 AM, Luis Bernardo wrote:



  
  

Since apparently Macs have no type1 fonts I had to look for some
and I tried the first one from 
http://www.ctan.org/tex-archive/fonts/cm/ps-type1/bakoma
(cmb10) which gave a problem:



java.util.NoSuchElementException

at java.util.Scanner.throwFor(Scanner.java:907)

at java.util.Scanner.next(Scanner.java:1530)

at java.util.Scanner.nextInt(Scanner.java:2160)

at java.util.Scanner.nextInt(Scanner.java:2119)

at
org.apache.fop.fonts.type1.PostscriptParser$PSFixedArray.addEntry(PostscriptParser.java:379)

at
org.apache.fop.fonts.type1.PostscriptParser$PSFixedArray.parseToken(PostscriptParser.java:329)

.



So it seems this needs to be tested with more fonts. But I will
test next in with the default Linux type1 fonts.



On 3/7/14, 11:23 AM, Robert wrote:

  
  

Hi All,

  

  About a week ago I posted a patch to add Type 1 subset support
  to FOP. All referenced Type 1 fonts (unless set to
  embedding-mode=full) will now be subset by default much like
  the behaviour exhibited by TrueType and OpenType. As this is a
  big feature and quite involved I think it is necessary to vote
  on whether to add this feature in it's current state to FOP.
  I'm not sure if anyone has taken a look at what has gone into
  this or tried it out yet, but it might be worth doing so
  before making your decision.

  

  I am going to be away for the next week or so but will tally
  up the votes and post the result once I am back.

  

  Here is a link to the patch and issue:

  https://issues.apache.org/jira/browse/FOP-2354

  

  Regards,

  

  Robert Meyer


  
  



  

[VOTE] Applying the Type 1 subset patch

[Robert]

Hi All,

About a week ago I posted a patch to add Type 1 subset support to FOP. All 
referenced Type 1 fonts (unless set to embedding-mode=full) will now be 
subset by default much like the behaviour exhibited by TrueType and OpenType. 
As this is a big feature and quite involved I think it is necessary to vote on 
whether to add this feature in it's current state to FOP. I'm not sure if 
anyone has taken a look at what has gone into this or tried it out yet, but it 
might be worth doing so before making your decision.

I am going to be away for the next week or so but will tally up the votes and 
post the result once I am back.

Here is a link to the patch and issue:
https://issues.apache.org/jira/browse/FOP-2354

Regards,

Robert Meyer
  

RE: [VOTE] Applying the Type 1 subset patch

[Robert]

The (optional) fontbox library dependency was added for the OpenType font / 
subset support which is already in trunk. This patch for subsetting Type 1 
fonts adds no new dependencies and does not use fontbox.
 
From: gl...@skynav.com
Date: Fri, 7 Mar 2014 10:23:18 -0700
Subject: Re: [VOTE] Applying the Type 1 subset patch
To: fop-dev@xmlgraphics.apache.org


On Fri, Mar 7, 2014 at 4:23 AM, Robert rme...@hotmail.co.uk wrote:





Hi All,

About a week ago I posted a patch to add Type 1 subset support to FOP. All 
referenced Type 1 fonts (unless set to embedding-mode=full) will now be 
subset by default much like the behaviour exhibited by TrueType and OpenType. 
As this is a big feature and quite involved I think it is necessary to vote on 
whether to add this feature in it's current state to FOP. I'm not sure if 
anyone has taken a look at what has gone into this or tried it out yet, but it 
might be worth doing so before making your decision.



I am going to be away for the next week or so but will tally up the votes and 
post the result once I am back.

Here is a link to the patch and issue:
https://issues.apache.org/jira/browse/FOP-2354


Just to remind me, what new (external) library dependencies does this entail? 
FontBox? 



Regards,

Robert Meyer
  

  

[jira] [Created] (FOP-2354) Subset support for Type 1 fonts

[Robert Meyer (JIRA)]

Robert Meyer created FOP-2354:
-

 Summary: Subset support for Type 1 fonts
 Key: FOP-2354
 URL: https://issues.apache.org/jira/browse/FOP-2354
 Project: Fop
  Issue Type: New Feature
  Components: fonts
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
 Fix For: trunk


This patch adds subsetting support to Type 1 fonts. Currently the only two 
supported output formats for this are PDF and Postscript.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FOP-2354) [PATCH] Subset support for Type 1 fonts

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2354:
--

Summary: [PATCH] Subset support for Type 1 fonts  (was: Subset support for 
Type 1 fonts)

 [PATCH] Subset support for Type 1 fonts
 ---

 Key: FOP-2354
 URL: https://issues.apache.org/jira/browse/FOP-2354
 Project: Fop
  Issue Type: New Feature
  Components: fonts
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
 Fix For: trunk

 Attachments: c0419bt_.pfb, patch.diff


 This patch adds subsetting support to Type 1 fonts. Currently the only two 
 supported output formats for this are PDF and Postscript.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FOP-2354) [PATCH] Subset support for Type 1 fonts

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2354:
--

Attachment: (was: patch.diff)

 [PATCH] Subset support for Type 1 fonts
 ---

 Key: FOP-2354
 URL: https://issues.apache.org/jira/browse/FOP-2354
 Project: Fop
  Issue Type: New Feature
  Components: fonts
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
 Fix For: trunk

 Attachments: c0419bt_.pfb


 This patch adds subsetting support to Type 1 fonts. Currently the only two 
 supported output formats for this are PDF and Postscript.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FOP-2354) [PATCH] Subset support for Type 1 fonts

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2354:
--

Attachment: patch.diff

Re-uploaded patch as the existing version had a mis-placed apache license 
section.

 [PATCH] Subset support for Type 1 fonts
 ---

 Key: FOP-2354
 URL: https://issues.apache.org/jira/browse/FOP-2354
 Project: Fop
  Issue Type: New Feature
  Components: fonts
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
 Fix For: trunk

 Attachments: c0419bt_.pfb, patch.diff


 This patch adds subsetting support to Type 1 fonts. Currently the only two 
 supported output formats for this are PDF and Postscript.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (FOP-2260) [PATCH] Smart quotes broken in RTF if at start of text

[Robert Meyer (JIRA)]

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

Robert Meyer reassigned FOP-2260:
-

Assignee: Robert Meyer

 [PATCH] Smart quotes broken in RTF if at start of text
 --

 Key: FOP-2260
 URL: https://issues.apache.org/jira/browse/FOP-2260
 Project: Fop
  Issue Type: Bug
  Components: rtf
Affects Versions: 1.1
Reporter: Christopher Lowdon
Assignee: Robert Meyer
Priority: Minor
  Labels: patch
 Attachments: mypatch.diff


 When you have a quote at the start of your string, it is transformed into a 
 smart quote incorrectly.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (FOP-2260) [PATCH] Smart quotes broken in RTF if at start of text

[Robert Meyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912744#comment-13912744
 ] 

Robert Meyer commented on FOP-2260:
---

Sorry in the delay getting to this. The patch has been applied: 
http://svn.apache.org/viewvc?view=revisionrevision=1571989

Thanks for your contribution!

 [PATCH] Smart quotes broken in RTF if at start of text
 --

 Key: FOP-2260
 URL: https://issues.apache.org/jira/browse/FOP-2260
 Project: Fop
  Issue Type: Bug
  Components: rtf
Affects Versions: 1.1
Reporter: Christopher Lowdon
Assignee: Robert Meyer
Priority: Minor
  Labels: patch
 Attachments: mypatch.diff


 When you have a quote at the start of your string, it is transformed into a 
 smart quote incorrectly.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (FOP-2260) [PATCH] Smart quotes broken in RTF if at start of text

[Robert Meyer (JIRA)]

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

Robert Meyer resolved FOP-2260.
---

Resolution: Fixed

 [PATCH] Smart quotes broken in RTF if at start of text
 --

 Key: FOP-2260
 URL: https://issues.apache.org/jira/browse/FOP-2260
 Project: Fop
  Issue Type: Bug
  Components: rtf
Affects Versions: 1.1
Reporter: Christopher Lowdon
Assignee: Robert Meyer
Priority: Minor
  Labels: patch
 Attachments: mypatch.diff


 When you have a quote at the start of your string, it is transformed into a 
 smart quote incorrectly.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (FOP-2350) Implement support for page-master types other than the simple variant for RTF output

[Robert Meyer (JIRA)]

Robert Meyer created FOP-2350:
-

 Summary: Implement support for page-master types other than the 
simple variant for RTF output
 Key: FOP-2350
 URL: https://issues.apache.org/jira/browse/FOP-2350
 Project: Fop
  Issue Type: New Feature
  Components: rtf
Affects Versions: trunk
Reporter: Robert Meyer


RTF currently only supports simple-page-masters. The RTF specification has 
support for different page sizes and orientations per page so this feature 
should be possible to support and implement.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (FOP-2321) Latest fop snapshot crashes when processing rindolf-spec.fo

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2321:
--

Attachment: patch.diff

After investigating this issue, it stems from the fact that the RTF code cannot 
handle anything other than a simple-page-master reference. This is due to the 
limitation of the RTF implementation we have and without adding this feature 
will unfortunately remain like that. In the case of the original FO 
specification file, the page-sequence is referencing a page-sequence-master 
with a repeatable-page-master. The null pointer exception occurs because it 
tries to read the flow object after looking up and failing to find a 
simple-page-master with the master-reference provided.

I originally created a patch to warn the user if the flow was null and 
recommend to changing the FO to using a simple-page-master reference in the 
page-sequence-master. A side effect of this though was that it bypassed trying 
to read the flow and continued to create the document successfully without it! 
As such I've simply removed the warning from the patch to only create the 
page-master if the flow is not null which seems to work fine. I'll apply this 
patch shortly.

I've created another issue for the missing feature in RTF to support other 
page-master types:

https://issues.apache.org/jira/browse/FOP-2350

 Latest fop snapshot crashes when processing rindolf-spec.fo
 ---

 Key: FOP-2321
 URL: https://issues.apache.org/jira/browse/FOP-2321
 Project: Fop
  Issue Type: Bug
Affects Versions: trunk
 Environment: Mageia Linux Cauldron (what will become Mageia Linux 4) 
 x86-64 with java-1.7.0-openjdk-headless-1.7.0.60-2.4.3.2.mga4 .
Reporter: Shlomi Fish
 Attachments: patch.diff, rindolf-spec.fo.xz


 When I run this command I get this output (I will attach rindolf-spec.fo 
 soon). I am using /home/shlomif/apps/fop/fop-20131126/fop :
 shlomif[homepage@default]:$trunk$ fop -fo lib/docbook/4/fo/rindolf-spec.fo 
 -rtf lib/docbook/4/rtf/rindolf-spec.rtf
 Nov 27, 2013 10:10:24 AM org.apache.fop.events.LoggingEventListener 
 processEvent
 WARNING: Only simple-page-masters are supported on page-sequences. Using 
 default simple-page-master from page-sequence-master body. (See position 
 2:26400)
 Nov 27, 2013 10:10:24 AM org.apache.fop.cli.Main startFOP
 SEVERE: Exception
 org.apache.fop.apps.FOPException
 java.lang.NullPointerException
 at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288)
 at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115)
 at org.apache.fop.cli.Main.startFOP(Main.java:177)
 at org.apache.fop.cli.Main.main(Main.java:208)
 Caused by: java.lang.NullPointerException
 at 
 org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221)
 at 
 org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:121)
 at 
 org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:335)
 at 
 org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:178)
 at 
 org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072)
 at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
 Source)
 at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown 
 Source)
 at 
 org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown 
 Source)
 at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
  Source)
 at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
 Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
 at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
 at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
 Source)
 at 
 org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484)
 at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285)
 ... 3 more
 -
 java.lang.NullPointerException
 at 
 org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221)
 at 
 org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:121)
 at 
 org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:335)
 at 
 org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:178)
 at 
 org.apache.xalan.transformer.TransformerIdentityImpl.startElement

[jira] [Assigned] (FOP-2321) Latest fop snapshot crashes when processing rindolf-spec.fo

[Robert Meyer (JIRA)]

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

Robert Meyer reassigned FOP-2321:
-

Assignee: Robert Meyer

 Latest fop snapshot crashes when processing rindolf-spec.fo
 ---

 Key: FOP-2321
 URL: https://issues.apache.org/jira/browse/FOP-2321
 Project: Fop
  Issue Type: Bug
Affects Versions: trunk
 Environment: Mageia Linux Cauldron (what will become Mageia Linux 4) 
 x86-64 with java-1.7.0-openjdk-headless-1.7.0.60-2.4.3.2.mga4 .
Reporter: Shlomi Fish
Assignee: Robert Meyer
 Attachments: patch.diff, rindolf-spec.fo.xz


 When I run this command I get this output (I will attach rindolf-spec.fo 
 soon). I am using /home/shlomif/apps/fop/fop-20131126/fop :
 shlomif[homepage@default]:$trunk$ fop -fo lib/docbook/4/fo/rindolf-spec.fo 
 -rtf lib/docbook/4/rtf/rindolf-spec.rtf
 Nov 27, 2013 10:10:24 AM org.apache.fop.events.LoggingEventListener 
 processEvent
 WARNING: Only simple-page-masters are supported on page-sequences. Using 
 default simple-page-master from page-sequence-master body. (See position 
 2:26400)
 Nov 27, 2013 10:10:24 AM org.apache.fop.cli.Main startFOP
 SEVERE: Exception
 org.apache.fop.apps.FOPException
 java.lang.NullPointerException
 at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288)
 at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115)
 at org.apache.fop.cli.Main.startFOP(Main.java:177)
 at org.apache.fop.cli.Main.main(Main.java:208)
 Caused by: java.lang.NullPointerException
 at 
 org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221)
 at 
 org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:121)
 at 
 org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:335)
 at 
 org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:178)
 at 
 org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072)
 at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
 Source)
 at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown 
 Source)
 at 
 org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown 
 Source)
 at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
  Source)
 at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
 Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
 at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
 at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
 Source)
 at 
 org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484)
 at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285)
 ... 3 more
 -
 java.lang.NullPointerException
 at 
 org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221)
 at 
 org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:121)
 at 
 org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:335)
 at 
 org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:178)
 at 
 org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072)
 at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
 Source)
 at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown 
 Source)
 at 
 org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown 
 Source)
 at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
  Source)
 at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
 Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
 at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
 at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
 Source)
 at 
 org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484)
 at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285)
 at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115

[jira] [Commented] (FOP-2321) Latest fop snapshot crashes when processing rindolf-spec.fo

[Robert Meyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13913049#comment-13913049
 ] 

Robert Meyer commented on FOP-2321:
---

Patch applied http://svn.apache.org/viewvc?view=revisionrevision=1572109

I'll set this issue to resolved as it fixes the exception. The other issue I 
created is there should support for other page-masters be added in future.

 Latest fop snapshot crashes when processing rindolf-spec.fo
 ---

 Key: FOP-2321
 URL: https://issues.apache.org/jira/browse/FOP-2321
 Project: Fop
  Issue Type: Bug
Affects Versions: trunk
 Environment: Mageia Linux Cauldron (what will become Mageia Linux 4) 
 x86-64 with java-1.7.0-openjdk-headless-1.7.0.60-2.4.3.2.mga4 .
Reporter: Shlomi Fish
Assignee: Robert Meyer
 Attachments: patch.diff, rindolf-spec.fo.xz


 When I run this command I get this output (I will attach rindolf-spec.fo 
 soon). I am using /home/shlomif/apps/fop/fop-20131126/fop :
 shlomif[homepage@default]:$trunk$ fop -fo lib/docbook/4/fo/rindolf-spec.fo 
 -rtf lib/docbook/4/rtf/rindolf-spec.rtf
 Nov 27, 2013 10:10:24 AM org.apache.fop.events.LoggingEventListener 
 processEvent
 WARNING: Only simple-page-masters are supported on page-sequences. Using 
 default simple-page-master from page-sequence-master body. (See position 
 2:26400)
 Nov 27, 2013 10:10:24 AM org.apache.fop.cli.Main startFOP
 SEVERE: Exception
 org.apache.fop.apps.FOPException
 java.lang.NullPointerException
 at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288)
 at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115)
 at org.apache.fop.cli.Main.startFOP(Main.java:177)
 at org.apache.fop.cli.Main.main(Main.java:208)
 Caused by: java.lang.NullPointerException
 at 
 org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221)
 at 
 org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:121)
 at 
 org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:335)
 at 
 org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:178)
 at 
 org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072)
 at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
 Source)
 at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown 
 Source)
 at 
 org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown 
 Source)
 at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
  Source)
 at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
 Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
 at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
 at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
 Source)
 at 
 org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484)
 at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285)
 ... 3 more
 -
 java.lang.NullPointerException
 at 
 org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221)
 at 
 org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:121)
 at 
 org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:335)
 at 
 org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:178)
 at 
 org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072)
 at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
 Source)
 at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown 
 Source)
 at 
 org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown 
 Source)
 at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
  Source)
 at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
 Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
 at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
 at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
 Source

[jira] [Updated] (FOP-2321) [PATCH] Latest fop snapshot crashes when processing rindolf-spec.fo

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2321:
--

Summary: [PATCH] Latest fop snapshot crashes when processing 
rindolf-spec.fo  (was: Latest fop snapshot crashes when processing 
rindolf-spec.fo)

 [PATCH] Latest fop snapshot crashes when processing rindolf-spec.fo
 ---

 Key: FOP-2321
 URL: https://issues.apache.org/jira/browse/FOP-2321
 Project: Fop
  Issue Type: Bug
Affects Versions: trunk
 Environment: Mageia Linux Cauldron (what will become Mageia Linux 4) 
 x86-64 with java-1.7.0-openjdk-headless-1.7.0.60-2.4.3.2.mga4 .
Reporter: Shlomi Fish
Assignee: Robert Meyer
 Attachments: patch.diff, rindolf-spec.fo.xz


 When I run this command I get this output (I will attach rindolf-spec.fo 
 soon). I am using /home/shlomif/apps/fop/fop-20131126/fop :
 shlomif[homepage@default]:$trunk$ fop -fo lib/docbook/4/fo/rindolf-spec.fo 
 -rtf lib/docbook/4/rtf/rindolf-spec.rtf
 Nov 27, 2013 10:10:24 AM org.apache.fop.events.LoggingEventListener 
 processEvent
 WARNING: Only simple-page-masters are supported on page-sequences. Using 
 default simple-page-master from page-sequence-master body. (See position 
 2:26400)
 Nov 27, 2013 10:10:24 AM org.apache.fop.cli.Main startFOP
 SEVERE: Exception
 org.apache.fop.apps.FOPException
 java.lang.NullPointerException
 at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288)
 at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115)
 at org.apache.fop.cli.Main.startFOP(Main.java:177)
 at org.apache.fop.cli.Main.main(Main.java:208)
 Caused by: java.lang.NullPointerException
 at 
 org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221)
 at 
 org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:121)
 at 
 org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:335)
 at 
 org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:178)
 at 
 org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072)
 at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
 Source)
 at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown 
 Source)
 at 
 org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown 
 Source)
 at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
  Source)
 at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
 Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
 at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
 at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
 Source)
 at 
 org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484)
 at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285)
 ... 3 more
 -
 java.lang.NullPointerException
 at 
 org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221)
 at 
 org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:121)
 at 
 org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:335)
 at 
 org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:178)
 at 
 org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072)
 at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
 Source)
 at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown 
 Source)
 at 
 org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown 
 Source)
 at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
  Source)
 at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
 Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
 at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
 at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
 Source)
 at 
 org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484

[jira] [Resolved] (FOP-2321) [PATCH] Latest fop snapshot crashes when processing rindolf-spec.fo

[Robert Meyer (JIRA)]

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

Robert Meyer resolved FOP-2321.
---

Resolution: Fixed

 [PATCH] Latest fop snapshot crashes when processing rindolf-spec.fo
 ---

 Key: FOP-2321
 URL: https://issues.apache.org/jira/browse/FOP-2321
 Project: Fop
  Issue Type: Bug
Affects Versions: trunk
 Environment: Mageia Linux Cauldron (what will become Mageia Linux 4) 
 x86-64 with java-1.7.0-openjdk-headless-1.7.0.60-2.4.3.2.mga4 .
Reporter: Shlomi Fish
Assignee: Robert Meyer
 Attachments: patch.diff, rindolf-spec.fo.xz


 When I run this command I get this output (I will attach rindolf-spec.fo 
 soon). I am using /home/shlomif/apps/fop/fop-20131126/fop :
 shlomif[homepage@default]:$trunk$ fop -fo lib/docbook/4/fo/rindolf-spec.fo 
 -rtf lib/docbook/4/rtf/rindolf-spec.rtf
 Nov 27, 2013 10:10:24 AM org.apache.fop.events.LoggingEventListener 
 processEvent
 WARNING: Only simple-page-masters are supported on page-sequences. Using 
 default simple-page-master from page-sequence-master body. (See position 
 2:26400)
 Nov 27, 2013 10:10:24 AM org.apache.fop.cli.Main startFOP
 SEVERE: Exception
 org.apache.fop.apps.FOPException
 java.lang.NullPointerException
 at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288)
 at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115)
 at org.apache.fop.cli.Main.startFOP(Main.java:177)
 at org.apache.fop.cli.Main.main(Main.java:208)
 Caused by: java.lang.NullPointerException
 at 
 org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221)
 at 
 org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:121)
 at 
 org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:335)
 at 
 org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:178)
 at 
 org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072)
 at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
 Source)
 at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown 
 Source)
 at 
 org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown 
 Source)
 at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
  Source)
 at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
 Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
 at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
 at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
 Source)
 at 
 org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484)
 at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285)
 ... 3 more
 -
 java.lang.NullPointerException
 at 
 org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221)
 at 
 org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:121)
 at 
 org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:335)
 at 
 org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:178)
 at 
 org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072)
 at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
 Source)
 at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown 
 Source)
 at 
 org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown 
 Source)
 at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
  Source)
 at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
 Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
 at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
 at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
 Source)
 at 
 org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484)
 at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285)
 at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115

[jira] [Updated] (FOP-2339) [PATCH] GIF to PS transparency is black

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2339:
--

Attachment: test.fo
asf-logo-nt.tif

After applying the change I get the following exception with another image when 
generating postscript:

Caused by: java.lang.ClassCastException: 
org.apache.xmlgraphics.image.codec.tiff.TIFFImage cannot be cast to 
java.awt.image.BufferedImage

I've attached a test.fo with the asf-logo-nt.tif to reproduce.

 [PATCH] GIF to PS transparency is black
 ---

 Key: FOP-2339
 URL: https://issues.apache.org/jira/browse/FOP-2339
 Project: Fop
  Issue Type: Bug
Reporter: simon steiner
 Attachments: asf-logo-nt.tif, fop-gif-scaling-bug.gif, 
 giftrans.patch, test.fo, test.fo


 fop test.fo -ps out.ps



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Comment Edited] (FOP-2339) [PATCH] GIF to PS transparency is black

[Robert Meyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13913127#comment-13913127
 ] 

Robert Meyer edited comment on FOP-2339 at 2/26/14 4:45 PM:


Hi Simon,

After applying the patch I get the following exception with another image when 
generating postscript:

Caused by: java.lang.ClassCastException: 
org.apache.xmlgraphics.image.codec.tiff.TIFFImage cannot be cast to 
java.awt.image.BufferedImage

I've attached a test.fo with the asf-logo-nt.tif to reproduce.


was (Author: rmeyer):
After applying the change I get the following exception with another image when 
generating postscript:

Caused by: java.lang.ClassCastException: 
org.apache.xmlgraphics.image.codec.tiff.TIFFImage cannot be cast to 
java.awt.image.BufferedImage

I've attached a test.fo with the asf-logo-nt.tif to reproduce.

 [PATCH] GIF to PS transparency is black
 ---

 Key: FOP-2339
 URL: https://issues.apache.org/jira/browse/FOP-2339
 Project: Fop
  Issue Type: Bug
Reporter: simon steiner
 Attachments: asf-logo-nt.tif, fop-gif-scaling-bug.gif, 
 giftrans.patch, test.fo, test.fo


 fop test.fo -ps out.ps



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (FOP-2344) AFP issue

[Robert Meyer (JIRA)]

Robert Meyer created FOP-2344:
-

 Summary: AFP issue
 Key: FOP-2344
 URL: https://issues.apache.org/jira/browse/FOP-2344
 Project: Fop
  Issue Type: Bug
  Components: general
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
 Fix For: trunk


When you have an FO which contains various SVG elements of different colors, 
certain elements such as text and boxes do not have their respective colors set 
correctly and instead are left at the color of the last element. This causes a 
problem if for example you have a grey box and black text on top. FOP will draw 
the box using the grey color and then use the same color for the text, 
rendering it invisible.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (FOP-2344) [PATCH] SVG elements bleed colour between elements when outputting to AFP

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2344:
--

Summary: [PATCH] SVG elements bleed colour between elements when outputting 
to AFP  (was: AFP issue)

 [PATCH] SVG elements bleed colour between elements when outputting to AFP
 -

 Key: FOP-2344
 URL: https://issues.apache.org/jira/browse/FOP-2344
 Project: Fop
  Issue Type: Bug
  Components: general
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
 Fix For: trunk

 Attachments: afp-test.fo, output-after.afp, output-before.afp, 
 patch.diff


 When you have an FO which contains various SVG elements of different colors, 
 certain elements such as text and boxes do not have their respective colors 
 set correctly and instead are left at the color of the last element. This 
 causes a problem if for example you have a grey box and black text on top. 
 FOP will draw the box using the grey color and then use the same color for 
 the text, rendering it invisible.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (FOP-2344) AFP issue

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2344:
--

Attachment: patch.diff
output-before.afp
output-after.afp
afp-test.fo

Attached example FO, patch and two AFP's showing before and after patch.

 AFP issue
 -

 Key: FOP-2344
 URL: https://issues.apache.org/jira/browse/FOP-2344
 Project: Fop
  Issue Type: Bug
  Components: general
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
 Fix For: trunk

 Attachments: afp-test.fo, output-after.afp, output-before.afp, 
 patch.diff


 When you have an FO which contains various SVG elements of different colors, 
 certain elements such as text and boxes do not have their respective colors 
 set correctly and instead are left at the color of the last element. This 
 causes a problem if for example you have a grey box and black text on top. 
 FOP will draw the box using the grey color and then use the same color for 
 the text, rendering it invisible.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (FOP-2344) [PATCH] SVG bleeds color between elements when outputting to AFP

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2344:
--

Summary: [PATCH] SVG bleeds color between elements when outputting to AFP  
(was: [PATCH] SVG elements bleed colour between elements when outputting to AFP)

 [PATCH] SVG bleeds color between elements when outputting to AFP
 

 Key: FOP-2344
 URL: https://issues.apache.org/jira/browse/FOP-2344
 Project: Fop
  Issue Type: Bug
  Components: general
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
 Fix For: trunk

 Attachments: afp-test.fo, output-after.afp, output-before.afp, 
 patch.diff


 When you have an FO which contains various SVG elements of different colors, 
 certain elements such as text and boxes do not have their respective colors 
 set correctly and instead are left at the color of the last element. This 
 causes a problem if for example you have a grey box and black text on top. 
 FOP will draw the box using the grey color and then use the same color for 
 the text, rendering it invisible.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (FOP-2344) [PATCH] SVG bleeds color between elements when outputting to AFP

[Robert Meyer (JIRA)]

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

Robert Meyer resolved FOP-2344.
---

Resolution: Fixed

 [PATCH] SVG bleeds color between elements when outputting to AFP
 

 Key: FOP-2344
 URL: https://issues.apache.org/jira/browse/FOP-2344
 Project: Fop
  Issue Type: Bug
  Components: general
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
 Fix For: trunk

 Attachments: afp-test.fo, output-after.afp, output-before.afp, 
 patch.diff


 When you have an FO which contains various SVG elements of different colors, 
 certain elements such as text and boxes do not have their respective colors 
 set correctly and instead are left at the color of the last element. This 
 causes a problem if for example you have a grey box and black text on top. 
 FOP will draw the box using the grey color and then use the same color for 
 the text, rendering it invisible.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (FOP-2344) [PATCH] SVG bleeds color between elements when outputting to AFP

[Robert Meyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13904138#comment-13904138
 ] 

Robert Meyer commented on FOP-2344:
---

Patch applied: http://svn.apache.org/viewvc?view=revisionrevision=1569381

 [PATCH] SVG bleeds color between elements when outputting to AFP
 

 Key: FOP-2344
 URL: https://issues.apache.org/jira/browse/FOP-2344
 Project: Fop
  Issue Type: Bug
  Components: general
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
 Fix For: trunk

 Attachments: afp-test.fo, output-after.afp, output-before.afp, 
 patch.diff


 When you have an FO which contains various SVG elements of different colors, 
 certain elements such as text and boxes do not have their respective colors 
 set correctly and instead are left at the color of the last element. This 
 causes a problem if for example you have a grey box and black text on top. 
 FOP will draw the box using the grey color and then use the same color for 
 the text, rendering it invisible.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (FOP-2341) [PATCH] Infinite loop when smaller used with a zero length font-size

[Robert Meyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13903116#comment-13903116
 ] 

Robert Meyer commented on FOP-2341:
---

Patch applied http://svn.apache.org/viewvc?view=revisionrevision=1568925

 [PATCH] Infinite loop when smaller used with a zero length font-size 
 ---

 Key: FOP-2341
 URL: https://issues.apache.org/jira/browse/FOP-2341
 Project: Fop
  Issue Type: Bug
  Components: general
Affects Versions: 0.95, trunk
Reporter: MOHD
Priority: Critical
  Labels: font-size, infinite-loop, smaller
 Attachments: _test.fo, patch.diff

   Original Estimate: 1m
  Remaining Estimate: 1m

 My local FOP engine is hang when below scenario was occur.
  fo:block font-style=normal font-size=10mmpt role=html:div
 fo:inline baseline-shift=super font-size=smaller 
 role=html:supth/fo:inlineof each month. 
   /fo:block
 Please give some suggestion if any one has solution for this issue.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (FOP-2341) [PATCH] Infinite loop when smaller used with a zero length font-size

[Robert Meyer (JIRA)]

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

Robert Meyer resolved FOP-2341.
---

Resolution: Fixed

 [PATCH] Infinite loop when smaller used with a zero length font-size 
 ---

 Key: FOP-2341
 URL: https://issues.apache.org/jira/browse/FOP-2341
 Project: Fop
  Issue Type: Bug
  Components: general
Affects Versions: 0.95, trunk
Reporter: MOHD
Priority: Critical
  Labels: font-size, infinite-loop, smaller
 Attachments: _test.fo, patch.diff

   Original Estimate: 1m
  Remaining Estimate: 1m

 My local FOP engine is hang when below scenario was occur.
  fo:block font-style=normal font-size=10mmpt role=html:div
 fo:inline baseline-shift=super font-size=smaller 
 role=html:supth/fo:inlineof each month. 
   /fo:block
 Please give some suggestion if any one has solution for this issue.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (FOP-2341) Infinite loop when smaller used with a zero length font-size

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2341:
--

Attachment: patch.diff

I've uploaded a patch of a potential fix. It simply ensures that the previous 
step font size is not the same as the current to prevent it endlessly cycling. 
Alternatively I think this check could be placed in the while(..) definition. 
I've tested it and it seems to work fine.

 Infinite loop when smaller used with a zero length font-size 
 ---

 Key: FOP-2341
 URL: https://issues.apache.org/jira/browse/FOP-2341
 Project: Fop
  Issue Type: Bug
  Components: general
Affects Versions: 0.95, trunk
Reporter: MOHD
Priority: Critical
  Labels: font-size, infinite-loop, smaller
 Attachments: _test.fo, patch.diff

   Original Estimate: 1m
  Remaining Estimate: 1m

 My local FOP engine is hang when below scenario was occur.
  fo:block font-style=normal font-size=10mmpt role=html:div
 fo:inline baseline-shift=super font-size=smaller 
 role=html:supth/fo:inlineof each month. 
   /fo:block
 Please give some suggestion if any one has solution for this issue.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (FOP-2341) [PATCH] Infinite loop when smaller used with a zero length font-size

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2341:
--

Summary: [PATCH] Infinite loop when smaller used with a zero length 
font-size   (was: Infinite loop when smaller used with a zero length 
font-size )

 [PATCH] Infinite loop when smaller used with a zero length font-size 
 ---

 Key: FOP-2341
 URL: https://issues.apache.org/jira/browse/FOP-2341
 Project: Fop
  Issue Type: Bug
  Components: general
Affects Versions: 0.95, trunk
Reporter: MOHD
Priority: Critical
  Labels: font-size, infinite-loop, smaller
 Attachments: _test.fo, patch.diff

   Original Estimate: 1m
  Remaining Estimate: 1m

 My local FOP engine is hang when below scenario was occur.
  fo:block font-style=normal font-size=10mmpt role=html:div
 fo:inline baseline-shift=super font-size=smaller 
 role=html:supth/fo:inlineof each month. 
   /fo:block
 Please give some suggestion if any one has solution for this issue.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (FOP-2252) [PATCH] OpenType CFF support for FOP

[Robert Meyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896733#comment-13896733
 ] 

Robert Meyer commented on FOP-2252:
---

I have made some changes to the OTF patch to remove the need for patching 
fontbox. This will allow FOP to now use the latest version of fontbox and not a 
patched custom version.

http://svn.apache.org/viewvc?view=revisionrevision=1566674

 [PATCH] OpenType CFF support for FOP
 

 Key: FOP-2252
 URL: https://issues.apache.org/jira/browse/FOP-2252
 Project: Fop
  Issue Type: New Feature
  Components: fonts
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
 Fix For: trunk

 Attachments: AlexBrushRegular.otf, SourceSansProBold.otf, 
 fontbox-1.8.0-SNAPSHOT.jar, fop.xconf, output.pdf, patch-240713.diff, 
 test.fo, test.pdf






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Assigned] (FOP-2322) [PATCH] Type1 Font with Custom Encoding not visible in Postscript output

[Robert Meyer (JIRA)]

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

Robert Meyer reassigned FOP-2322:
-

Assignee: Robert Meyer

 [PATCH] Type1 Font with Custom Encoding not visible in Postscript output
 

 Key: FOP-2322
 URL: https://issues.apache.org/jira/browse/FOP-2322
 Project: Fop
  Issue Type: Bug
Reporter: simon steiner
Assignee: Robert Meyer
 Attachments: fop.xconf, test.fo, trunktype1customenc.patch


 fop test.fo -c fop.xconf -ps out.ps
 No afm is given so fop writes out standard encoding which postscript doesnt 
 like
 I cant share our customer fonts



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (FOP-2322) [PATCH] Type1 Font with Custom Encoding not visible in Postscript output

[Robert Meyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839984#comment-13839984
 ] 

Robert Meyer commented on FOP-2322:
---

After being able to test this with the font in question I was able to verify 
this patch and am able to confirm it resolves the issue.

Patch applied http://svn.apache.org/viewvc?view=revisionrevision=1548054
Thanks for your contribution!

 [PATCH] Type1 Font with Custom Encoding not visible in Postscript output
 

 Key: FOP-2322
 URL: https://issues.apache.org/jira/browse/FOP-2322
 Project: Fop
  Issue Type: Bug
Reporter: simon steiner
Assignee: Robert Meyer
 Attachments: fop.xconf, test.fo, trunktype1customenc.patch


 fop test.fo -c fop.xconf -ps out.ps
 No afm is given so fop writes out standard encoding which postscript doesnt 
 like
 I cant share our customer fonts



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (FOP-2322) [PATCH] Type1 Font with Custom Encoding not visible in Postscript output

[Robert Meyer (JIRA)]

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

Robert Meyer resolved FOP-2322.
---

Resolution: Fixed

 [PATCH] Type1 Font with Custom Encoding not visible in Postscript output
 

 Key: FOP-2322
 URL: https://issues.apache.org/jira/browse/FOP-2322
 Project: Fop
  Issue Type: Bug
Reporter: simon steiner
Assignee: Robert Meyer
 Attachments: fop.xconf, test.fo, trunktype1customenc.patch


 fop test.fo -c fop.xconf -ps out.ps
 No afm is given so fop writes out standard encoding which postscript doesnt 
 like
 I cant share our customer fonts



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (FOP-1069) No error message on illegal/unknown values on a property

[Robert Meyer (JIRA)]

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

Robert Meyer resolved FOP-1069.
---

Resolution: Fixed

 No error message on illegal/unknown values on a property
 

 Key: FOP-1069
 URL: https://issues.apache.org/jira/browse/FOP-1069
 Project: Fop
  Issue Type: Bug
  Components: fo tree
Affects Versions: trunk
 Environment: Operating System: All
 Platform: All
Reporter: Jeremias Maerki
Assignee: Robert Meyer
 Attachments: fix-20131203.diff, patch.diff, test2.fo


 I've written border=solit 1pt into an FO file. When I realized my typo I 
 went
 looking for an error message but didn't find one. I looked around to fix this
 myself but didn't find the right spot in reasonable time as I'm concentrating 
 on
 other stuff right now. I'm posting it here so it doesn't get lost.
 FOP should notify the user that it has found a value it cannot deal with,
 especially if this is an enum value.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (FOP-1069) No error message on illegal/unknown values on a property

[Robert Meyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839053#comment-13839053
 ] 

Robert Meyer commented on FOP-1069:
---

Patch applied http://svn.apache.org/viewvc?view=revisionrevision=1547838

 No error message on illegal/unknown values on a property
 

 Key: FOP-1069
 URL: https://issues.apache.org/jira/browse/FOP-1069
 Project: Fop
  Issue Type: Bug
  Components: fo tree
Affects Versions: trunk
 Environment: Operating System: All
 Platform: All
Reporter: Jeremias Maerki
Assignee: Robert Meyer
 Attachments: fix-20131203.diff, patch.diff, test2.fo


 I've written border=solit 1pt into an FO file. When I realized my typo I 
 went
 looking for an error message but didn't find one. I looked around to fix this
 myself but didn't find the right spot in reasonable time as I'm concentrating 
 on
 other stuff right now. I'm posting it here so it doesn't get lost.
 FOP should notify the user that it has found a value it cannot deal with,
 especially if this is an enum value.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (FOP-2323) NPE caused by missing local subroutine index in private dictonary of OTF font

[Robert Meyer (JIRA)]

Robert Meyer created FOP-2323:
-

 Summary: NPE caused by missing local subroutine index in private 
dictonary of OTF font
 Key: FOP-2323
 URL: https://issues.apache.org/jira/browse/FOP-2323
 Project: Fop
  Issue Type: Bug
  Components: fonts
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
 Fix For: trunk


This issue was found by using a font which did not have a local subroutine 
index which is normally located in the private dictionary. A check has now been 
added to handle this eventuality and use a blank subroutine index instead. The 
font in question which triggered this was called RebusScript.otf



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (FOP-2323) NPE caused by missing local subroutine index in private dictonary of OTF font

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2323:
--

Attachment: patch.diff

Attached patch for this issue

 NPE caused by missing local subroutine index in private dictonary of OTF font
 -

 Key: FOP-2323
 URL: https://issues.apache.org/jira/browse/FOP-2323
 Project: Fop
  Issue Type: Bug
  Components: fonts
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
 Fix For: trunk

 Attachments: patch.diff


 This issue was found by using a font which did not have a local subroutine 
 index which is normally located in the private dictionary. A check has now 
 been added to handle this eventuality and use a blank subroutine index 
 instead. The font in question which triggered this was called RebusScript.otf



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (FOP-2323) NPE caused by missing local subroutine index in private dictonary of OTF font

[Robert Meyer (JIRA)]

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

Robert Meyer resolved FOP-2323.
---

Resolution: Fixed

 NPE caused by missing local subroutine index in private dictonary of OTF font
 -

 Key: FOP-2323
 URL: https://issues.apache.org/jira/browse/FOP-2323
 Project: Fop
  Issue Type: Bug
  Components: fonts
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
 Fix For: trunk

 Attachments: patch.diff


 This issue was found by using a font which did not have a local subroutine 
 index which is normally located in the private dictionary. A check has now 
 been added to handle this eventuality and use a blank subroutine index 
 instead. The font in question which triggered this was called RebusScript.otf



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (FOP-2323) NPE caused by missing local subroutine index in private dictonary of OTF font

[Robert Meyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13837520#comment-13837520
 ] 

Robert Meyer commented on FOP-2323:
---

Patch applied http://svn.apache.org/viewvc?view=revisionrevision=1547330

 NPE caused by missing local subroutine index in private dictonary of OTF font
 -

 Key: FOP-2323
 URL: https://issues.apache.org/jira/browse/FOP-2323
 Project: Fop
  Issue Type: Bug
  Components: fonts
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
 Fix For: trunk

 Attachments: patch.diff


 This issue was found by using a font which did not have a local subroutine 
 index which is normally located in the private dictionary. A check has now 
 been added to handle this eventuality and use a blank subroutine index 
 instead. The font in question which triggered this was called RebusScript.otf



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (FOP-1069) No error message on illegal/unknown values on a property

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-1069:
--

Attachment: fix-20131203.diff

Sorry for my lateness with getting back to this issue. I looked at this briefly 
but didn't manage to update it before I went on an extended holiday to the US. 

The issue was caused by the validation line being placed within the loop for 
each property value component. For instance, the word black on border will 
result in a null property result, but the other parts may result in a property 
being returned. Because of this a warning was being displayed even if the 
property was found to be valid. As such, I have moved the line for validation 
outside of the loop and the check is now done after each component part has 
been processed rather than individually. A slight change is that using this 
method makes it impossible to identify which part of the property is at fault 
and so the values which can be read are added to a string and used in the 
warning e.g.

WARNING: Invalid property value encountered in border=black solit (See 
position 11:46)

It should provide ample enough information to look at the line and fix the 
issue. On your original example it now works fine. I'll go ahead and commit 
this tomorrow unless you have any other comments.

 No error message on illegal/unknown values on a property
 

 Key: FOP-1069
 URL: https://issues.apache.org/jira/browse/FOP-1069
 Project: Fop
  Issue Type: Bug
  Components: fo tree
Affects Versions: trunk
 Environment: Operating System: All
 Platform: All
Reporter: Jeremias Maerki
Assignee: Robert Meyer
 Attachments: fix-20131203.diff, patch.diff, test2.fo


 I've written border=solit 1pt into an FO file. When I realized my typo I 
 went
 looking for an error message but didn't find one. I looked around to fix this
 myself but didn't find the right spot in reasonable time as I'm concentrating 
 on
 other stuff right now. I'm posting it here so it doesn't get lost.
 FOP should notify the user that it has found a value it cannot deal with,
 especially if this is an enum value.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (FOP-1069) No error message on illegal/unknown values on a property

[Robert Meyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812877#comment-13812877
 ] 

Robert Meyer commented on FOP-1069:
---

Thanks Glenn. I will take a look at this tomorrow.

 No error message on illegal/unknown values on a property
 

 Key: FOP-1069
 URL: https://issues.apache.org/jira/browse/FOP-1069
 Project: Fop
  Issue Type: Bug
  Components: fo tree
Affects Versions: trunk
 Environment: Operating System: All
 Platform: All
Reporter: Jeremias Maerki
Assignee: Robert Meyer
 Attachments: patch.diff, test2.fo


 I've written border=solit 1pt into an FO file. When I realized my typo I 
 went
 looking for an error message but didn't find one. I looked around to fix this
 myself but didn't find the right spot in reasonable time as I'm concentrating 
 on
 other stuff right now. I'm posting it here so it doesn't get lost.
 FOP should notify the user that it has found a value it cannot deal with,
 especially if this is an enum value.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (FOP-2260) [PATCH] Smart quotes broken in RTF if at start of text

[Robert Meyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801634#comment-13801634
 ] 

Robert Meyer commented on FOP-2260:
---

Hi Christopher,

I have taken a quick look at this and am unable to reproduce the issue using 
the default font. Which font are you using where this effect occurs? Also, 
would it be possible to post up a couple of simple examples showing this issue?

Thanks

 [PATCH] Smart quotes broken in RTF if at start of text
 --

 Key: FOP-2260
 URL: https://issues.apache.org/jira/browse/FOP-2260
 Project: Fop
  Issue Type: Bug
  Components: rtf
Affects Versions: 1.1
Reporter: Christopher Lowdon
Priority: Minor
  Labels: patch
 Attachments: mypatch.diff


 When you have a quote at the start of your string, it is transformed into a 
 smart quote incorrectly.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (FOP-2104) [PATCH] RTF renderer barfs when fo:table-row is missing inside fo-table-header

[Robert Meyer (JIRA)]

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

Robert Meyer resolved FOP-2104.
---

Resolution: Fixed
  Assignee: Robert Meyer

Patch applied: http://svn.apache.org/viewvc?view=revisionrevision=1534582

 [PATCH] RTF renderer barfs when fo:table-row is missing inside fo-table-header
 --

 Key: FOP-2104
 URL: https://issues.apache.org/jira/browse/FOP-2104
 Project: Fop
  Issue Type: Bug
  Components: rtf
Affects Versions: trunk
 Environment: Operating System: All
 Platform: PC
Reporter: Gisbert
Assignee: Robert Meyer
 Attachments: patch.diff, patch.diff, t1.zip


 In RTF, using fo:table-cell as direct children of fo:table-header (without
 intervening fo:table-row) causes the FOPException ... RTFHandler: startCell
 null. In PDF, it works flawlessly (which it should, as far as I understand 
 the FO
 specs).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (FOP-2299) [PATCH] Non Unicode named glyphs not loaded for Type1 fonts

[Robert Meyer (JIRA)]

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

Robert Meyer reassigned FOP-2299:
-

Assignee: Robert Meyer

 [PATCH] Non Unicode named glyphs not loaded for Type1 fonts
 ---

 Key: FOP-2299
 URL: https://issues.apache.org/jira/browse/FOP-2299
 Project: Fop
  Issue Type: Bug
Reporter: simon steiner
Assignee: Robert Meyer
 Attachments: 8731X___.AFM, 8731X___.INF, 8731X___.PFB, 8731X___.PFM, 
 fop.xconf, test.fo, unicodemissing.patch


 Glyphs without unicode name are not loaded
 fop test.fo -c fop.xconf out.pdf



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (FOP-2299) [PATCH] Non Unicode named glyphs not loaded for Type1 fonts

[Robert Meyer (JIRA)]

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

Robert Meyer resolved FOP-2299.
---

Resolution: Fixed

Thanks for your contribution.

Patch applied: http://svn.apache.org/viewvc?view=revisionrevision=1534195

 [PATCH] Non Unicode named glyphs not loaded for Type1 fonts
 ---

 Key: FOP-2299
 URL: https://issues.apache.org/jira/browse/FOP-2299
 Project: Fop
  Issue Type: Bug
Reporter: simon steiner
Assignee: Robert Meyer
 Attachments: 8731X___.AFM, 8731X___.INF, 8731X___.PFB, 8731X___.PFM, 
 fop.xconf, test.fo, unicodemissing.patch


 Glyphs without unicode name are not loaded
 fop test.fo -c fop.xconf out.pdf



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (FOP-2304) SVG line clipping not correct when outputting to Postscript

[Robert Meyer (JIRA)]

Robert Meyer created FOP-2304:
-

 Summary: SVG line clipping not correct when outputting to 
Postscript
 Key: FOP-2304
 URL: https://issues.apache.org/jira/browse/FOP-2304
 Project: Fop
  Issue Type: Bug
  Components: ps
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
Priority: Minor


Lines that should be clipped are being drawn. This is because an intersect of 
two shapes are being used to determine if clipping needs to occur, but with 
lines this always returns false. I will add examples and a patch shortly.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (FOP-2304) SVG line clipping not correct when outputting to Postscript

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2304:
--

Attachment: output.ps

 SVG line clipping not correct when outputting to Postscript
 ---

 Key: FOP-2304
 URL: https://issues.apache.org/jira/browse/FOP-2304
 Project: Fop
  Issue Type: Bug
  Components: ps
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
Priority: Minor
 Attachments: output.pdf, output.ps


 Lines that should be clipped are being drawn. This is because an intersect of 
 two shapes are being used to determine if clipping needs to occur, but with 
 lines this always returns false. I will add examples and a patch shortly.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (FOP-2304) SVG line clipping not correct when outputting to Postscript

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2304:
--

Attachment: (was: output.ps)

 SVG line clipping not correct when outputting to Postscript
 ---

 Key: FOP-2304
 URL: https://issues.apache.org/jira/browse/FOP-2304
 Project: Fop
  Issue Type: Bug
  Components: ps
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
Priority: Minor
 Attachments: output.pdf, output.ps


 Lines that should be clipped are being drawn. This is because an intersect of 
 two shapes are being used to determine if clipping needs to occur, but with 
 lines this always returns false. I will add examples and a patch shortly.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (FOP-2304) SVG line clipping not correct when outputting to Postscript

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2304:
--

Attachment: output.pdf
output2.ps
output.ps

Attached are several examples. Output1.pdf shows that it is working correctly 
to PDF. It is expected that the gradient is not being drawn correctly in 
Postscript hence it is black, however the white lines exceed the limit of 
circle when instead they should have been clipped. The correct output for 
Postscript without the current radial shading support should be that of 
output2.ps. I have a fix and will post it shortly.

 SVG line clipping not correct when outputting to Postscript
 ---

 Key: FOP-2304
 URL: https://issues.apache.org/jira/browse/FOP-2304
 Project: Fop
  Issue Type: Bug
  Components: ps
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
Priority: Minor
 Attachments: output.pdf, output.ps


 Lines that should be clipped are being drawn. This is because an intersect of 
 two shapes are being used to determine if clipping needs to occur, but with 
 lines this always returns false. I will add examples and a patch shortly.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (FOP-2304) SVG line clipping not correct when outputting to Postscript

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2304:
--

Attachment: (was: output2.ps)

 SVG line clipping not correct when outputting to Postscript
 ---

 Key: FOP-2304
 URL: https://issues.apache.org/jira/browse/FOP-2304
 Project: Fop
  Issue Type: Bug
  Components: ps
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
Priority: Minor
 Attachments: output.pdf, output.ps


 Lines that should be clipped are being drawn. This is because an intersect of 
 two shapes are being used to determine if clipping needs to occur, but with 
 lines this always returns false. I will add examples and a patch shortly.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (FOP-2304) SVG line clipping not correct when outputting to Postscript

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2304:
--

Attachment: output2.ps

 SVG line clipping not correct when outputting to Postscript
 ---

 Key: FOP-2304
 URL: https://issues.apache.org/jira/browse/FOP-2304
 Project: Fop
  Issue Type: Bug
  Components: ps
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
Priority: Minor
 Attachments: output2.ps, output.pdf, output.ps


 Lines that should be clipped are being drawn. This is because an intersect of 
 two shapes are being used to determine if clipping needs to occur, but with 
 lines this always returns false. I will add examples and a patch shortly.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (FOP-2304) SVG line clipping not correct when outputting to Postscript

[Robert Meyer (JIRA)]

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

Robert Meyer updated FOP-2304:
--

Attachment: patch.diff

Patch file has been attached which includes the adding of an intersecting line 
test case.

 SVG line clipping not correct when outputting to Postscript
 ---

 Key: FOP-2304
 URL: https://issues.apache.org/jira/browse/FOP-2304
 Project: Fop
  Issue Type: Bug
  Components: ps
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
Priority: Minor
 Attachments: output2.ps, output.pdf, output.ps, patch.diff


 Lines that should be clipped are being drawn. This is because an intersect of 
 two shapes are being used to determine if clipping needs to occur, but with 
 lines this always returns false. I will add examples and a patch shortly.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (FOP-2304) SVG line clipping not correct when outputting to Postscript

[Robert Meyer (JIRA)]

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

Robert Meyer resolved FOP-2304.
---

   Resolution: Fixed
Fix Version/s: trunk

Patched applied http://svn.apache.org/viewvc?view=revisionrevision=1533516

 SVG line clipping not correct when outputting to Postscript
 ---

 Key: FOP-2304
 URL: https://issues.apache.org/jira/browse/FOP-2304
 Project: Fop
  Issue Type: Bug
  Components: ps
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
Priority: Minor
 Fix For: trunk

 Attachments: output2.ps, output.pdf, output.ps, patch.diff


 Lines that should be clipped are being drawn. This is because an intersect of 
 two shapes are being used to determine if clipping needs to occur, but with 
 lines this always returns false. I will add examples and a patch shortly.



--
This message was sent by Atlassian JIRA
(v6.1#6144)