[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: AW: AW: AW: [docbook] Some text after a section
I think that Aaron is on the right track here. Assuming that I've understood your goals correctly, my basic question would be: If you want to output the PI content, why not output the PI content? You don't need to duplicate it as content inside <para> elements. In fact, doing so is probably going to give you a headache, since you then have to maintain it in two places. From: markus.sticker.epos@zf.com [mailto:markus.sticker.epos@zf.com] Hi, the debugging mode is for end-users with less knowledge of docbook or fop. They build there template (or parts) with an wysiwyg-editor. Von: aarondamommio@gmail.com [mailto:aarondamommio@gmail.com] Im Auftrag von Aaron DaMommio Okay, so you want to make your processing instructions visible, and you are converting them to paragraphs to do that, but sometimes a para is not valid in the location where the processing instruction is? Are you doing XSLT customizations to help with this at all? I can imagine many template customizations that would help in this situation. Here are some ideas: - Customize titles so that if the topic contains a certain PI, it outputs the text of the PI as part of the title - It's not clear to me precisely how you are converting your PIs to paras, but if you post-processed the result with an XSLT, you could detect when the para is 1st child of a section, and then convert it to a subtitle in that case (since a subtitle is valid at section start) - Instead of trying to output a built-up document, why not write out your source? I assume that there is some reason why it is inconvenient to view the source files so that you want to display your PIs in the output. But maybe there is a convenient intermediate file that you could be looking at when you are debugging. In our system, for example, it is frequently helpful to look at files at the stage in our process where xinclusion has been done and a book has been converted to one big file, but before other transformations have happened. Maybe you could set up a situation where such a file becomes an output, and then inspect it as text to see where the PIs are. On Tue, Apr 9, 2013 at 10:07 AM, <markus.sticker.epos@zf.com> wrote: Hi, OK. We use processing-instructions (build by several preprocessors out of our tool-chain) These documents are generated on the server. If we need to debug the resulting document Sometimes the processing instruction are not in the very best node to add a para. Unfortunately. Currently I build a very dirty hack (using glossary) to get the instructions, but this is not my preferred way Best regards Markus Von: aarondamommio@gmail.com [mailto:aarondamommio@gmail.com] Im Auftrag von Aaron DaMommio Marcus, I'm reading what you've sent, and I still don't understand what you are trying to do. Can you try again to describe what you want, perhaps more generally, leaving out the processing instructions, and just describe the results you are trying to get? Then someone may be better able to suggest a solution that works with DocBook. --Aaron DaMommio On Tue, Apr 9, 2013 at 9:45 AM, Stefan Seefeld <stefan@seefeld.name> wrote: On 04/09/2013 10:25 AM, markus.sticker.epos@zf.com wrote: -- -- |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]