Re: [docbook-apps] Removing newlines between <para>s

[dick@rlhamilton.net]

Hi Emily,

the <sbr> element is valid only when it’s inside the <arg>,  <cmdsynopsis>, <group>, or <rhs> elements. So, using it where you did causes the error message.

The stylesheets often handle invalid instances (depending on the XSL processor), and you’ve found a case where the stylesheets process <sbr>, even though it’s invalid in that context.

There are several possible ways to get around this, but most of them depend on customizing the stylesheets, and the details will differ depending on whether you’re generating html or print output.

Here is one thing to try that might do the job without customizing the stylesheets:

Use <bridgehead> with the renderas attribute, e.g., <bridgehead renderas=“sect4”>. The appearance will depend on how the different section level titles are set up in your stylesheets. I suggest you test with different values of the renderas attribute (you can use sect1 through sect5). You might get lucky and find that one of the section levels gives you a workable result.

Other possibilities include using <formalpara>, which is a paragraph with a title or, if you have a whole string of these paragraphs, <variablelist>. Both of these will require some amount of parameter setting and stylesheet customization because they both use run-in titles by default.

Any of these solutions would be better than what you have. Even though the stylesheets work, since you have invalid code, you can’t be sure that they always will give you a reasonable result. And, having invalid instances can cause other problems in your tool chain plus make it harder to find other errors.

I hope that helps,
Dick Hamilton
-------
XML Press
XML for Technical Communicators
http://xmlpress.net
hamilton@xmlpress.net



> On Oct 13, 2016, at 10:57, Forsyth, Emily B. <emily.forsyth@swri.org> wrote:
> 
> I am having an issue with lines between para.I need the line starting with Inserts the string....to be on the line right under the bolded para.  This is functions.
> Here is my example:
> <para><emphasis role="bold"><literal>void insertByName</literal> </emphasis><para>
> <para>Inserts the string strToInsert offset places
>          from the the string anchor. A zero offset inserts the string just
>          ahead of the anchor string. A negative offset inserts further
>          towards to start of the array. No value is deleted and the order of
>          the values following the inserted one does not change.</para>
> 
> I can get it to work by using the following:
> 
> <para><emphasis role="bold"><literal>void insertByName</literal> </emphasis><sbr/>
> Inserts the string strToInsert offset places
>          from the the string anchor. A zero offset inserts the string just
>          ahead of the anchor string. A negative offset inserts further
>          towards to start of the array. No value is deleted and the order of
>          the values following the inserted one does not change.</para>
> 
> However, I get the validity of element "sbr" from namespace not allowed in this context, but it works for me.  Will there be problems in the future.
> 
> I tried the linegroup, however it indents, but works the way I would want it to but don’t want the indention.
> 
> Thank you,
> 
> Emily Forsyth
> Fluids & Machinery Engineering Department 
> Propulsion & Energy Machinery
> Southwest Research Institute
> Tel:  210.522.2045
> Email:  emily.forsyth@swri.org
> 
> 
> -----Original Message-----
> From: Shikareva, Ekaterina [mailto:EShikareva@luxoft.com] 
> Sent: Wednesday, August 24, 2016 3:04 AM
> To: Stefan Knorr <sknorr@suse.de>
> Cc: Bob Stayton <bobs@sagehill.net>; docbook-apps@lists.oasis-open.org
> Subject: RE: [docbook-apps] Removing newlines between <para>s
> 
> Hello Stefan!
> 
> For me, this empty line appears even before any conversion, I can see it in XMLMind: see the same file in
> Notepad++ - https://i.imgur.com/MmacVZc.png
> XMLMind DocBook Editor v. 7.0 - https://i.imgur.com/zTjEdSw.png Also visible in XMLMind 5.3.0.
> 
> And btw, if you create an informaltable with XMLMind, the paras inside will be saved on the same line, as in the first row. For these screenshots, I had to manually insert a line break in the second row to reproduce the problem.
> 
> For conversion, I use stylesheets 1.78.1, FOP 1.1, not sure which version of xsltproc.exe with xslt 1.0.
> 
> As suggested by Bob, I will send him my stylesheets to check them. But if this is already visible before any conversion, I'm not sure it can help...
> 
> Anyway, the problem in our system is being solved with scripting, so this investigation is just to know if this additional empty line is the expected behavior.
> 
> --
> Ekaterina Shikareva.
> 
> 
> -----Original Message-----
> From: Stefan Knorr [mailto:sknorr@suse.de]
> Sent: Dienstag, 23. August 2016 17:54
> To: Shikareva, Ekaterina
> Cc: Bob Stayton; docbook-apps@lists.oasis-open.org
> Subject: RE: [docbook-apps] Removing newlines between <para>s
> 
> Hi Ekaterina,
> 
> from your response to Bob, I finally understood your problem...
> this sounds like a bug. However, I can't reproduce this here; not with HTML and not with FO output. Spacing is exactly the same in between same-line paras and para with a line break in between.
> 
> However, the space between the paras is indeed a bit large but that should be easy to fix with FO attributes/CSS.
> 
> Screenshot from my PDF: https://i.imgur.com/Y1hHwYC.png (Input paras on the left as a screen, output on the right.)
> 
> I used the following tools: Upstream XSLT 1.0 DocBook 5.0 Stylesheets 1.78.1, xsltproc/libxml 2.9.4, and FOP 2.1. I also verified that our profiling scripting does not interfere by reformatting XML.
> 
> So, not sure what happens in your toolchain, but I guess something is different.
> 
> Stefan.
> 
> ---                                                                    .
> SUSE Linux GmbH. Geschäftsführer: Felix Imendörffer, Jane Smithard, Graham Norton. HRB 21284 (AG Nürnberg).
> 
> 
> ________________________________
> 
> This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.