Mathieu, in a short test I can't reproduce the behaviour you're reporting. Can you provide a self-containing boiled-down example (FO file) that demonstrates the problem? Whitespace and linefeed treatments depends on a whole bunch of properties and their values which cannot be seen in your snippet.
On 19.06.2010 09:50:36 Mathieu Malaterre wrote: > Hi, > > I am forwarding this issue from the docbook mailing list, if anyone > would like to comment if this could be a bug in fop or not. > > In the following example, it seems fop does not discard the leading > whitespace in a fo:block: > > <fo:block><fo:inline/>[linebreak] > <fo:inline>Definition 1 > ... > > > Is this something known ? > > Thanks, > > ---------- Forwarded message ---------- > From: Bob Stayton <> > Date: Fri, Jun 18, 2010 at 6:48 PM > Subject: Re: [docbook-apps] fop: anchors generating spaces > To: Mathieu Malaterre <>, DocBook Apps <> > > > I think this is an effect of FOP's handling of white spaces. In both > of your examples, you introduce white space at the beginning of the > para. In the first case, the white space (line feed and indent > spaces) occurs after the <anchor>, and in the second case the white > space (line feed and indent spaces) occurs before the <anchor> tag. > In DocBook's FO output, the anchor becomes an empty <fo:inline/>, and > emphasis also produces an fo:inline. So your FO output looks like: > > <fo:block><fo:inline/>[linebreak] > <fo:inline>Definition 1 > ... > > <fo:block>[linebreak] > <fo:inline/><fo:inline>Definition 2 > ... > > > I'm not sure what the XSL-FO spec says about this situation, but other > XSL-FO processors ignore leading whitespace in an fo:block. I'm pretty > sure HTML browsers do the same in <p> tags. It seems FOP does in one > case but not the other. in The first case it treats the empty > <fo:inline/> as "content" that turns on preservation of white space > after it. In the second case, all the white space occurs before the > empty fo:inline. You might ask the FOP mailing list about it. > > Since <para> is a mixed content element (which means it can contain > both text and other elements), white space is considered significant > in the XML. The best practice is to avoid leading whitespace in para, > although that's often hard to do. > > Bob Stayton > Sagehill Enterprises > [email protected] > > > ----- Original Message ----- From: "Mathieu Malaterre" > <[email protected]> > To: "DocBook Apps" <[email protected]> > Sent: Wednesday, June 16, 2010 12:28 AM > Subject: [docbook-apps] fop: anchors generating spaces > > > > Hi, > > > > Did anyone notice that <anchor/> generate spaces depending on what > > they are next to, eg.: > > > > <?xml version="1.0" encoding="UTF-8"?> > > <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" > > "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"> > > <article> > > <section> > > <title/> > > <para><anchor id="a1"/> > > <emphasis role="bold">Definition:</emphasis> This is def #1</para> > > <para> > > <anchor id="a2"/><emphasis role="bold">Definition:</emphasis> This > > is def #2</para> > > </section> > > </article> > > > > Using fop it generates the attached pdf file. > > > > Comments on whether this is expected, or is this something I should > > report to fop team ? > > > > Thanks, > > -- > > Mathieu > > > > > -------------------------------------------------------------------------------- > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > -- > Mathieu > Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
