gmane.text.xml.fop.devel

FOP using ICU?

Glenn Adams — 2013-06-18T04:46:48

Is there a reason FOP doesn't use ICU for determining line break
boundaries? The FOP implementation of UAX14 (org.apache.fop.text.linebreak)
seems to be out of date and basically unmaintained. According to [1], a
number of Apache projects are using it, including PDFBox, Xalan, and Xerces.

[1] http://site.icu-project.org/#TOC-Apache-Projects

buildbot success in ASF Buildbot on fop-trunk

2013-06-08T08:01:32

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/1000

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

buildbot failure in ASF Buildbot on fop-trunk

2013-06-07T17:57:20

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/999

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_1

sincerely,
 -The Buildbot

Who authored the POM file for FOP 1.1 on Maven Central Repository?

Markus Karg — 2013-06-05T12:48:32

Dear Maven Developers,

 

I highly appreciate the work you do and love the fact that FOP 1.1 is so
easy to use by simply adding this to a Maven POM file:

 

<dependency>

  <groupId>org.apache.xmlgraphics</groupId>

  <artifactId>fop</artifactId>

  <version>[1.1]</version>

</dependency>

 

I expect that someone of the FOP development team actually uploaded the
needed POM file
(http://search.maven.org/remotecontent?filepath=org/apache/xmlgraphics/f
op/1.1/fop-1.1.pom) and the fop.jar
(http://search.maven.org/remotecontent?filepath=org/apache/xmlgraphics/f
op/1.1/fop-1.1.jar) to make this work. Thanks for that! J

 

Unfortunately, it will not *really* work, as that POM file has a bug
(the references to avalon-framework-api and -impl use a false groupID).
The bug is easy to fix (giving the right groupdID) and works well
locally on my site, and so I actually liked to post a patch. But as I
have seen, the POM file is not part of your source code repository. So I
wonder who actually wrote that POM file and whom to send the patch?

 

Thanks!

-Markus

Fontbox optional dependency

Robert Meyer — 2013-05-29T15:31:41

Hi All,

Quick question related to this fontbox optional dependency being added for OTF CFF. I am guessing that to allow this to work, FOP will require the fontbox jar to be compiled, but optional when run? If the user does not have fontbox when running, an error is shown if a reference is made to a CFF font. This is just to confirm that I don't need to make the OTF CFF code external to FOP as a separate jar plugin so that FOP can be compiled without it.

Thanks,

Robert Meyer

Rendering issue: table with multiple cell spans

sdridi — 2013-04-17T15:00:49

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
<https://issues.apache.org/jira/browse/FOP-2230>  . 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.

[OT] Multi-page support in PDFTranscoder

honyk — 2013-04-11T19:48:00

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

embedding fonts subset with single-byte encoding

Francesco Nigro — 2013-04-11T10:19:08

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.

RTF: Strange behavior of bullets

2013-03-26T16:31:33

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< at >zf.com<mailto:Markus.Sticker.epos< at >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

RTF: Inline background-color will be inherit to next cell

2013-03-15T10:56:55

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< at >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

RTF: Border disappear if cells are merged with last col

2013-03-15T10:31:35

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< at >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

Why store glyph mappings on FOText?

Vincent Hennebert — 2013-03-13T10:27:57

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

Revision 1435241 for FOP-2191 introduces a Findbugs warning

Chris Bowditch — 2013-03-05T15:22:34

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) <#EI_EXPOSE_REP2>
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 if the developer responsible could address this 
warning.

Thanks,

Chris

FOP-2174 breaks compatibility with barcode4j

Alexios Giotis — 2013-02-28T15:57:45

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< at >1428918
[2] https://sourceforge.net/tracker/?func=detail&atid=615506&aid=3600784&group_id=96670


Alexios Giotis

Help needed for RTF

2013-02-21T13:19:09

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< at >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

Trouble with temporary files after the merge of Temp_URI_Resolution branch

Alexios Giotis — 2013-02-07T17:36:15

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 those issues. I was thinking of adding a cleanup() method on org.apache.xmlgraphics.io.TempResourceResolver interface so it gets a notification to delete the temp files, moving there the isTempURI() and generate() methods of TempResourceURIGenerator class and then deleting it.

I am also tempted to delete the org.apache.xmlgraphics.io.Resource and change in ResourceResolver the 
Resource getResource(URI uri)
to 
InputStream getInputStream(URI uri)


Although in [1] there is a reason for having it, in practice the "type" is used nowhere. 


WDYT ?

Alexis Giotis




[1] http://wiki.apache.org/xmlgraphics-fop/URIResolution

documentation!???

Glenn Adams — 2013-02-05T17:44:34

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?

font loading vagaries

Glenn Adams — 2013-01-22T19:30:13

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 functionality;
   2. ensure that auto font detection, when it should and must run, does
   not search outside of its intended directories;
   3. ensure that all paths to TTFontLoader disable complex script feature
   parsing when disabled at a higher configuration layer;

Comments?

[1] https://issues.apache.org/jira/browse/FOP-2197

remove fop1.1rc1 binaries?

Glenn Adams — 2013-01-20T21:41:04

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/

[Vote][Result] Add dependency to fontbox for OTF CFF‏

Robert Meyer — 2013-01-16T10:56:37



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

[Vote] Add dependency to fontbox for OTF CFF

Robert Meyer — 2013-01-10T12:07:32

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