gmane.text.xml.fop.user

Re: break-before in list-item-body: missing following content

Andreas Delmelle — 2008-08-29T16:33:01

Hi No immediate idea on what the problem is, but for a possible (untested) workaround: could you try putting the text in question in its own list-item and specify the break-before on that? Should work, in theory, if for that item you use an empty label (or one containing only a no-break space) the result should look exactly like what you're trying to achieve. HTH! Cheers Andreas

Re: FOP 0.95: Code lines that no longer wrap

Andreas Delmelle — 2008-08-29T16:19:34

Hi AFAIU, this is a known 'issue'. (see also: https://issues.apache.org/ bugzilla/show_bug.cgi?id=43474) Issue-between-quotes because, in spite of the default value for wrap- option being "wrap", strictly speaking, this only indicates that the formatter MAY (not MUST) insert implicit line-breaks. The method by which those are determined is left up to the implementation. FOP uses Unicode TR#14 (see: http://unicode.org/reports/tr14/) as a reference, and there, a break between two arbitrary alphanumeric characters is not considered, unless the two are separated by a space (which can also be a zero-width space). As long as no one finds the time/energy to implement real line- wrapping on top of that, the workaround is to customize the stylesheet to insert zero-width spaces at strategic positions in the uninterrupted strings that would not fit on a single line. FOP will then gladly use these as additional break-possibilities. HTH! Cheers Andreas

Re: FOP 0.95: Code lines that no longer wrap

Cheri Dennison — 2008-08-29T15:52:31

Attached is the FO file ( http://www.nabble.com/file/p19222600/book.xml_fo_with_problem.xml book.xml_fo_with_problem.xml ) and a PDF showing the two offending lines that used to wrap correctly with the old FOP and DB stylesheets ( http://www.nabble.com/file/p19222600/fop_testing_wrap_test.pdf fop_testing_wrap_test.pdf ). The first line is on Adobe page 19, and the second is on Adobe page 34. Much appreciated! cheri Jeremias Maerki-2 wrote:

break-before in list-item-body: missing following content

2008-08-29T13:39:53

Hello I have a problem with a "break-before" in a list-item-body: content following this attribute inside the list-item-body has disappeared "continue2/2 end" I have replace with a "space-before" but result is surprising: I have an overflow log message and 2 page-breaks instead of one unexpected page-break between "continue2/2" and "end" Same result with FOP-0.95 and FOP-trunk_svn689406 Regards Patrice ----------------------------------------

body1 continue1/2 continue2/2

Type 1 font encoding problems?

Joerg von Frantzius — 2008-08-29T13:39:04

Hi, I can't get FOP to render ▶ correctly in PDF (see e.g. http://en.wikipedia.org/wiki/Unicode_Geometric_Shapes). It should show up in font "Courier". I checked the PDF generated, and "Courier" is substituted with the Type 1 font "CourierStd" on my system, telling from Acrobat Reader properties for the PDF file. I verified using kfontview that indeed "CourierStd" has that glyph (in Unicode block "Geometric Shapes"). The font's encoding is reported as Ansi, though, and I guess that's where the problem is. In some related bug (https://issues.apache.org/bugzilla/show_bug.cgi?id=6237) it was recommended to "use a Unicode user font". Now I wonder how I can get FOP to use or embed a Type 1 font with Unicode encoding? Bug https://issues.apache.org/bugzilla/show_bug.cgi?id=17828 lets me think that embedding a TrueType Font could solve the problem, as it seems TTF is treated as Unicode. Here is a simple self-contained example to show the glyph in question:

Re: ErrorListener [0.95]

bonekrusher — 2008-08-29T12:27:55

My pleasure. I've been playing with this all morning. This has a lot of possibilities. The framework is very flexible. Since I am able to catch all the messages rather then sending them to the gui app or std.out in real time, the process speeds up. HTH, Phil Jeremias Maerki-2 wrote:

Re: Glyph "black right-pointing triangle" not correctly rendered in PDF

Jeremias Maerki — 2008-08-29T12:13:27

I'm afraid it's not that simple. While that "CourierStd" font might have the glyph you're looking for, the "Courier" Base14 font is used when you look at it from FOP's perspective. And that font is an old Type 1 font which doesn't have this glyph. "CourierStd" is only a substitution on the target platform. You'll need to register the CourierStd (or another font with this glyph) with FOP and adjust everything so this font is used instead. Then you'll get your geometric shapes. HTH On 29.08.2008 12:16:06 Joerg von Frantzius wrote: Jeremias Maerki

Re: ErrorListener [0.95]

Jeremias Maerki — 2008-08-29T12:07:40

Thanks a lot for your feedback, Phil! Much appreciated. I'm sure there's room for improvement still. On 29.08.2008 13:28:18 bonekrusher wrote: Jeremias Maerki

RE: Glyph "black right-pointing triangle" not correctly rendered in PDF

Pascal Sancho — 2008-08-29T11:36:14

Hi, IIRC, the standard Courier font doesn't contain the glyph x25B6; This is why FOP replaces it with '#' Font substitution in acrobat Reader cannot retrive the original glyph. If you want this glyph, you have to ensure that the font used at the FOP stage: 1/ contains the relevant glyph, and 2/ is embeded in your PDF (see [1] and [2] for further details). [1] http://xmlgraphics.apache.org/fop/0.95/fonts.html#embedding [2] http://xmlgraphics.apache.org/fop/0.95/fonts.html#register Pascal

Re: ErrorListener [0.95]

bonekrusher — 2008-08-29T11:28:18

Jeremias, This is perfect I just finished running this in a sandbox swing app. This allows control over what gets spit out by all events. Nice work. In the sandbox, I just piped all the messages to an Arraylist, which can either be sent to the app, out to a text file, or ignored for the end user. Nice! Regards, Phil

Glyph "black right-pointing triangle" not correctly rendered in PDF

Joerg von Frantzius — 2008-08-29T10:16:06

Hi, I can't get FOP to render ▶ correctly in PDF (see e.g. http://en.wikipedia.org/wiki/Unicode_Geometric_Shapes). Before I file a bug report, I thought I better ask whether someone is able to render it using the following example. It should show up in font "Courier". I checked the PDF generated, and "Courier" is substituted with the Type 1 font "CourierStd" on my system, telling from Acrobat Reader properties for the PDF file. I verified using kfontview that indeed "CourierStd" has that glyph (in Unicode block "Geometric Shapes"). I tried with both FOP 0.94 and 0.95. Maybe someone could feed the following example into FOP to verify that it neither works for him/her while it should?

Re: Referenced pattern not applied when PDF is encrypted

Jeremias Maerki — 2008-08-29T06:36:16

Please file a bug in Bugzilla for this and add all the information here to the issue. Thanks. Encryption is always a bit tricky and our PDF library has still a few messy parts which can lead to certain corner cases not to be handled correctly when encryption is present. Someone will have to fix it. Not sure if I'll have time and energy very soon. At least, with the Bugzilla entry it won't get forgotten. On 28.08.2008 11:59:23 Lea Thurman wrote: Jeremias Maerki

Re: Problem with inserting a PNG file

Jeremias Maerki — 2008-08-29T06:33:04

Another idea is to upgrade to FOP 0.95 final since there's at least one bug fixed in this area. If that doesn't help, please make the PNG (and the JPEG generated by GIMP you mentioned) available so we can find out what the problem is. It's a good idea to check that you check with a Sun JVM if that's not already the case. In the latest release we rely on ImageIO to load PNG images. Some non-Sun JVMs might not be totally bug-free when it comes to PNG loading. On 28.08.2008 15:34:44 Jubal Kessler wrote: Jeremias Maerki

Re: Print Italics over an Image

Jeremias Maerki — 2008-08-29T06:27:07

Can you please post (or send me) an FO file demonstrating the problem? I'd like to reproduce that here. Thanks. On 26.08.2008 18:44:23 Steffanina, Jeff wrote: Jeremias Maerki

Re: FOP 0.95: Code lines that no longer wrap

Jeremias Maerki — 2008-08-29T06:28:28

If you post an FO file (not DocBook) that demonstrates a problem I'll gladly take a look. On 27.08.2008 05:09:08 Cheri Dennison wrote: Jeremias Maerki

Referenced pattern not applied when PDF is encrypted

Lea Thurman — 2008-08-28T09:59:23

Hi, We are using FOP.0.95Beta on XP Pro and Mac OS X 10.5 and have encountered the following problem when we encrypt our PDF's on both OS's. We are generating the following SVG and then using FOP to convert this into a PDF. The PDF is rendered correctly and the referenced pattern applied if we do not encrypt the PDF. As soon as we encrypt the PDF the pattern is not applied. In both cases the SVG is identical. The code being used to encrypt the pdf is as follows: userAgent.getRende

Re: left and right padding lost on fo:inline in table header when repeated beyond one page

JonathanHeard — 2008-08-28T09:28:34

Thank you so much Andreas!! I had no idea that the .conditionality property existed. Once I added this to my FO, all is well. Does it not seem a little pointless for this value to defaul to 'discard'? Surely most people would expect padding to remain on subsequent pages? :-) I keep discovering more and more of these ".something" properties, most seem pretty useful and then I don't even understand why this one exists... But it does and setting it to "retain" and my problem is fixed.. Many Thanks Jonathan Andreas Delmelle-2 wrote:

AW: AW: keep-together problem

Preuss, Jacqueline - ENCOWAY — 2008-08-28T08:23:18

Hi again! You are right, Chris. Integer keeps work with FOP Trunk. Thanks... So I suppose that the integer support won't be released soon? :-( Regards, Jacqueline.