http://blog.gmane.org/gmane.text.xml.fop.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.text.xml.fop.devel/31796 <pre>Hello, I'm new to the Apache FOP project and I would like to help fixing this bug https://issues.apache.org/jira/browse/FOP-2230 &lt;https://issues.apache.org/jira/browse/FOP-2230&gt; . Considering the huge code base of FOP, I feel kind of lost, so I need some help from people who are familiar with the code and the rendering pipeline in general. So if you can give me some pointers regarding table rendering in FOP, I'd be very grateful. Regards Seifeddine -- View this message in context: http://apache-fop.1065347.n5.nabble.com/Rendering-issue-table-with-multiple-cell-spans-tp38341.html Sent from the FOP - Dev mailing list archive at Nabble.com. </pre> sdridi 2013-04-17T15:00:49 http://comments.gmane.org/gmane.text.xml.fop.devel/31768 <pre>Dear All, in my app I generate multipage PDFs from SVG sources. Currently I use Fop's PDF Transcoder and all individual PDF pages (byte streams) merge together using PDFBox. I am considering extending the org.apache.fop.svg.PDFTranscoder class to enable passing document array into the transcode method and to avoid another dependency or, better, inefficiency. protected void transcode(Document[] documents, String uri, TranscoderOutput output) { // my code } But analyzing the code I am not sure if something like this is even possible. E.g. this line is completely unclear to me (there is no transcode method in the AbstractFOPTranscoder): super.transcode(document, uri, output); To be honest, I don't understand well how the final PDF file is generated from input SVG nor the way how to intervene into this process and insert a page break followed by another page. Can be transcoder modified this way or it would be too complicated? Thanks for any hints, Jan </pre> honyk 2013-04-11T19:48:00 http://comments.gmane.org/gmane.text.xml.fop.devel/31766 <pre>Hi all, I'm using a peculiar archiving solution so I have to use single-byte encoded fonts; I'd like to reduce size and embed only a subset and not all fonts. I know that FOP doesn't support subset for single-byte at the moment but I was wondering if it would be feasible/reasonable to implement this feature. I saw that getTTCName and getUsedGlyphs methods are called inside PDFFactory class to create a subset and that those methods are implemented for MultiByteFont class only. Is fop going to support it at some point in the future? What do you think would be the shortest path to have subset for single-byte fonts? Thanks in advance, F. </pre> Francesco Nigro 2013-04-11T10:19:08 http://comments.gmane.org/gmane.text.xml.fop.devel/31735 <pre>Hi, I've got a strange behavior of list-items with more than one block inside. A bullet will be set for each fo:block inside a list-item-body. So how to fix it easily? Kind regards Markus Sticker Technik ZF-Konzern/Operations and Technology ZF Group Infrastruktur/Infrastructure (OTEP4) ZF Friedrichshafen AG 88038 Friedrichshafen, Deutschland/Germany Telefon/Phone +49 7541 77-7644, Telefax/Fax +49 7541 77-907644 Markus.Sticker.epos&lt; at &gt;zf.com&lt;mailto:Markus.Sticker.epos&lt; at &gt;zf.com&gt; Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Prof. Dr. Giorgio Behr Vorstand/Board of Management: Dr. Stefan Sommer (Vorsitzender/CEO), Dr. Konstantin Sauer, Dr. Peter Ottenbruch, Jürgen Holeksa, Dr. Gerhard Wagner, Reinhard Buhl, Rolf Lutz, Wilhelm Rehm Sitz/Headquarters: Friedrichshafen Handelsregistereintrag Amtsgericht Ulm HRB 630206/Trade register of the municipal court of Ulm HRB 630206 </pre> markus.sticker.epos< at >zf.com 2013-03-26T16:31:33 http://comments.gmane.org/gmane.text.xml.fop.devel/31691 <pre>Hi, I found this error. The inline background-color has been taken to the next cell. Mit freundlichen Grüßen/Kind regards Markus Sticker Technik ZF-Konzern/Operations and Technology ZF Group Infrastruktur/Infrastructure (OTEP4) ZF Friedrichshafen AG 88038 Friedrichshafen, Deutschland/Germany Telefon/Phone +49 7541 77-7644, Telefax/Fax +49 7541 77-907644 Markus.Sticker.epos&lt; at &gt;zf.com Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Prof. Dr. Giorgio Behr Vorstand/Board of Management: Dr. Stefan Sommer (Vorsitzender/CEO), Dr. Konstantin Sauer, Dr. Peter Ottenbruch, Jürgen Holeksa, Dr. Gerhard Wagner, Reinhard Buhl, Rolf Lutz, Wilhelm Rehm Sitz/Headquarters: Friedrichshafen Handelsregistereintrag Amtsgericht Ulm HRB 630206/Trade register of the municipal court of Ulm HRB 630206 </pre> markus.sticker.epos< at >zf.com 2013-03-15T10:56:55 http://comments.gmane.org/gmane.text.xml.fop.devel/31689 <pre>Hi, I found a bug at the RTF implementation. If I merge cells with the last column the border disappear. I guess that the border(start) of the (merged) last cell (which doesn't exists) will be set as border(end) for the result cell. Mit freundlichen Grüßen/Kind regards Markus Sticker Technik ZF-Konzern/Operations and Technology ZF Group Infrastruktur/Infrastructure (OTEP4) ZF Friedrichshafen AG 88038 Friedrichshafen, Deutschland/Germany Telefon/Phone +49 7541 77-7644, Telefax/Fax +49 7541 77-907644 Markus.Sticker.epos&lt; at &gt;zf.com Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Prof. Dr. Giorgio Behr Vorstand/Board of Management: Dr. Stefan Sommer (Vorsitzender/CEO), Dr. Konstantin Sauer, Dr. Peter Ottenbruch, Jürgen Holeksa, Dr. Gerhard Wagner, Reinhard Buhl, Rolf Lutz, Wilhelm Rehm Sitz/Headquarters: Friedrichshafen Handelsregistereintrag Amtsgericht Ulm HRB 630206/Trade register of the municipal court of Ulm HRB 630206 </pre> markus.sticker.epos< at >zf.com 2013-03-15T10:31:35 http://comments.gmane.org/gmane.text.xml.fop.devel/31681 <pre>Hi, this question is for Glenn I guess. What is the rationale behind storing glyph mappings on FOText (by a call to addMapping) rather than the instance of TextLM.AreaInfo that is about to be created? IIC that would avoid creating MapRange instances and increasing the mutability of FOText. Also, the natural processing flow if from FO tree to layout to area tree, and in this case it is inverted as TextLM modifies FOText. Thanks, Vincent </pre> Vincent Hennebert 2013-03-13T10:27:57 http://comments.gmane.org/gmane.text.xml.fop.devel/31656 <pre>Specifically: Code Warning EI2 org.apache.fop.complexscripts.fonts.GlyphPositioningState.reset(GlyphSequence, String, String, String, int, int[], int[][], ScriptContextTester) may expose internal representation by storing an externally mutable object into GlyphPositioningState.adjustments Bug type EI_EXPOSE_REP2 (click for details) &lt;#EI_EXPOSE_REP2&gt; In class org.apache.fop.complexscripts.fonts.GlyphPositioningState In method org.apache.fop.complexscripts.fonts.GlyphPositioningState.reset(GlyphSequence, String, String, String, int, int[], int[][], ScriptContextTester) Field org.apache.fop.complexscripts.fonts.GlyphPositioningState.adjustments Local variable named adjustments At GlyphPositioningState.java:[line 97] EI2 org.apache.fop.complexscripts.fonts.GlyphPositioningState.reset(GlyphSequence, String, String, String, int, int[], int[][], ScriptContextTester) may expose internal representation by storing an externally mutable object into GlyphPositioningState.widths I would appreciate it </pre> Chris Bowditch 2013-03-05T15:22:34 http://comments.gmane.org/gmane.text.xml.fop.devel/31631 <pre>Hi, I am working with FOP trunk, barcode4j trunk and source-resolution 300, instead of the default 72. The barcode size changed after committing the patch attached on FOP-2174 [1]. This has already been reported at [2]. Could anybody comment on which project this should be fixed ? [1] https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk&lt; at &gt;1428918 [2] https://sourceforge.net/tracker/?func=detail&amp;atid=615506&amp;aid=3600784&amp;group_id=96670 Alexios Giotis </pre> Alexios Giotis 2013-02-28T15:57:45 http://comments.gmane.org/gmane.text.xml.fop.devel/31602 <pre>Hello, I'm looking for Tables nested in Lists. I need some information about the process that lead to lists without nested tables. Mit freundlichen Grüßen/Kind regards Markus Sticker Technik ZF-Konzern/Operations and Technology ZF Group Infrastruktur/Infrastructure (OTEP4) ZF Friedrichshafen AG 88038 Friedrichshafen, Deutschland/Germany Telefon/Phone +49 7541 77-7644, Telefax/Fax +49 7541 77-907644 Markus.Sticker.epos&lt; at &gt;zf.com Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Prof. Dr. Giorgio Behr Vorstand/Board of Management: Dr. Stefan Sommer (Vorsitzender/CEO), Dr. Konstantin Sauer, Dr. Peter Ottenbruch, Jürgen Holeksa, Dr. Gerhard Wagner, Reinhard Buhl, Rolf Lutz, Wilhelm Rehm Sitz/Headquarters: Friedrichshafen Handelsregistereintrag Amtsgericht Ulm HRB 630206/Trade register of the municipal court of Ulm HRB 630206 </pre> markus.sticker.epos< at >zf.com 2013-02-21T13:19:09 http://comments.gmane.org/gmane.text.xml.fop.devel/31545 <pre>Hi, In certain cases FOP needs to write temporary files. For example org.apache.fop.afp.AFPStreamer needs to concatenate the AFP resources with the main document. After the vote and merge of the Temp_URI_Resolution branch (Sept 2012), the actual pattern of using temp files has changed from: File tmpFile = File.createTempFile(....); // Write and read from the file tmpFile.delete(); to: File tmpFile = new File(System.getProperty("java.io.tmpdir"), counterStartingFrom1AsString); tmpFile.deleteOnExit(); // Write and read from the file This introduces a number of bad side effects: 1. Different FOP processes can't be executed in parallel on the same system because creating the same temp file fails. 2. If the JVM is not normally terminated, the temp files are never deleted and the next invocation of the JVM fails to run. 3. deleteOnExit() keeps for the life of the JVM an unknown number of temp files both on disk and a reference in memory. I am volunteering to prepare a patch for both XGC and FOP to fix th</pre> Alexios Giotis 2013-02-07T17:36:15 http://comments.gmane.org/gmane.text.xml.fop.devel/31528 <pre>where do we edit documentation now? is fop/src/documentation now obsolete? if so, then why is it still in the tree? how will we do releases and still include documentation if it lives in another tree? </pre> Glenn Adams 2013-02-05T17:44:34 http://comments.gmane.org/gmane.text.xml.fop.devel/31480 <pre>While debugging FOP-2197 [1], I learned that: - junit-transcoder tests all end up performing auto font detection, which seems questionable [is this needed?] - auto font detection performs recursion on the font base directory even though the code comment in DefaultFontDetector.detect(...) says // search in font base if it is defined and // is a directory but don't recurse - multiple paths to consing TTFFontLoader sometimes result in complex script features being parsed (useAdvanced == true), even when the complex script features are disabled at a higher, configuration level As a result, the code that is actually executed when running junit-transcoder ends up being highly variable according to one's local file system and font configuration. This is probably not a good thing. I'd suggest we find a way endeavor to: 1. ensure that we aren't using auto font detection when running any junit tests unless we are specifically testing auto detection fun</pre> Glenn Adams 2013-01-22T19:30:13 http://comments.gmane.org/gmane.text.xml.fop.devel/31463 <pre>What is the practice regarding retention of RC binaries? Should we remove the fop1.1rc1 binaries from [1]? [1] http://mirror.reverse.net/pub/apache/xmlgraphics/fop/binaries/ </pre> Glenn Adams 2013-01-20T21:41:04 http://comments.gmane.org/gmane.text.xml.fop.devel/31434 <pre> Hi, Firstly, thanks all for voting. The result of the recent vote to add the new optional dependency to FOP has passed. In total there were seven +1 votes with no +0 or -1 submitted. I have already begun investigating the necessary changes to implement the feature and will look to start development shortly. I will post a patch to Jira when complete. Regards, Robert Meyer </pre> Robert Meyer 2013-01-16T10:56:37 http://comments.gmane.org/gmane.text.xml.fop.devel/31407 <pre>Hi all, I posted a message yesterday about getting opinions on either adding a dependency to fontbox to use their implementation or write our own for OTF CFF support. I personally think that using fontbox would be the better option due to: 1) Re-use of code rather than re-writing 2) Stability and subsequent bugfixes since the time it was released. 3) Will cut development time for implementing this feature. There is room for discussion about making the new dependency optional i.e. FOP working without the jar and only being called if a CFF font is used. At this stage though the dependency issue needs to be voted on. I would therefore like to start a vote. As a contributor, my vote will not count toward the result, therefore the decision is left up to the rest of you. Regards, Robert Meyer </pre> Robert Meyer 2013-01-10T12:07:32 http://comments.gmane.org/gmane.text.xml.fop.devel/31399 <pre>Hi All, Unless someone else has been developing this in secret, I am planning to make a start on adding support for OTF CFF (Open Type - Compact Font Format). There are two choices I can see which are available and would like to ask for your opinion. These are: 1) Using the implementation from fontbox and write adapter classes to allow it to work with FOP. 2) Write a dedicated FOP implementation. There are pro's and con's to each. Firstly, using fontbox will create another dependency to FOP which is generally never a good thing. It will also means if there is a problem with their implementation, we have to rely upon them to commit the patch (either written by us or by themselves). I don't know what their uptake is on committing patches, but unlike FOP the control would be taken out of our hands. Saying this however, using their implementation will cut the development time as the majority of work will already have been done. There is also the advantage that their implementation will have been around for a</pre> Robert Meyer 2013-01-09T16:39:29 http://comments.gmane.org/gmane.text.xml.fop.devel/31397 <pre>Hi For quite some times now, my company has been successfully using fop for rendering pdf. We are also in the process of evaluating using AFP renderer. In order to contribute to bug fixes or additional functionalities, my management is willing to sponsor some development works. What would be in your opinion the best way to do that? Are there available developers from the community looking for sponsorship? If we were to contract or hire someone instead, how long would it takes for someone new to the code base to be able to post its first patches (roughly as I guess it highly depends on the profile of the developer). Thanks in advance for any guidelines. </pre> franck FIMBEL 2013-01-08T16:15:14 http://comments.gmane.org/gmane.text.xml.fop.devel/31365 <pre>peter, your recent commit (below) introduced 7 new checkstyle warnings and 1 findbugs error; please fix and try to remember to check in future before committing, thanks, glenn commit c32a1a7eca7607b0570d5e3f68e81a5a768f5e10 Author: Peter Hancock &lt;phancock&lt; at &gt;apache.org&gt; Date: Thu Dec 13 11:41:49 2012 +0000 Bugzilla 37114: Implementation of changes necessary to warn of invalid property values. Contributed by Robert Meyer. git-svn-id: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk&lt; at &gt;142123813f79535-47bb-0310-9956-ffa450edef68 </pre> Glenn Adams 2012-12-29T16:49:03 http://comments.gmane.org/gmane.text.xml.fop.devel/31364 <pre>The Buildbot has detected a restored build on builder fop-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/fop-trunk/builds/832 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: ceres_ubuntu Build Reason: The Nightly scheduler named 'fopNightly' triggered this build Build Source Stamp: [branch xmlgraphics/fop/trunk] HEAD Blamelist: Build succeeded! sincerely, -The Buildbot </pre> buildbot< at >apache.org 2012-12-23T08:01:34 http://comments.gmane.org/gmane.text.xml.fop.devel/31363 <pre>The Buildbot has detected a new failure on builder fop-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/fop-trunk/builds/831 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: ceres_ubuntu Build Reason: The Nightly scheduler named 'fopNightly' triggered this build Build Source Stamp: [branch xmlgraphics/fop/trunk] HEAD Blamelist: BUILD FAILED: failed shell_2 sincerely, -The Buildbot </pre> buildbot< at >apache.org 2012-12-23T02:28:14 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.text.xml.fop.devel