Hi Chris.
Thanks very much. I look forward to reviewing.
Don
Sent from Yahoo Mail on Android
On Sat, Feb 5, 2022 at 9:50 AM, Chris Papademetrious
christopher(_dot_)papademetrious(_at_)synopsys(_dot_)com<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com>
wrote: #yiv4756972860 #yiv4756972860 -- _filtered {} _filtered {} _filtered
{} _filtered {}#yiv4756972860 #yiv4756972860 a:link, #yiv4756972860
span.yiv4756972860MsoHyperlink
{color:blue;text-decoration:underline;}#yiv4756972860
p.yiv4756972860MsoPlainText, #yiv4756972860 li.yiv4756972860MsoPlainText,
#yiv4756972860 div.yiv4756972860MsoPlainText
{margin:0in;font-size:11.0pt;font-family:sans-serif;}#yiv4756972860
span.yiv4756972860EmailStyle19
{font-family:sans-serif;color:windowtext;}#yiv4756972860
span.yiv4756972860PlainTextChar {font-family:sans-serif;}#yiv4756972860
.yiv4756972860MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv4756972860
div.yiv4756972860WordSection1 {}#yiv4756972860 _filtered {} _filtered {}
_filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {}
_filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {}
_filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered
{}#yiv4756972860 ol {margin-bottom:0in;}#yiv4756972860 ul
{margin-bottom:0in;}#yiv4756972860
Hi Don,
I recently had to solve the opposite problem – inline content in<li> *not*
being wrapped in <p>. But it’s a similar problem – wrap some stuff but not
other stuff. I’m attaching the code I used.
The basic approach is to use helper functions to identify elements as
block/inline, then<for-each-group group-adjacent=...> to wrap inline element
sequences in the current element but not block element sequences.
Note the following:
- My code has some heuristics to wrap<indexterm> elements only when they’re
along with real inline content; you might not need that.
- My code uses <xsl:next-match/> because it’s extracted from a larger XSLT
file that does other stuff; you might not need that.
- My helper functions use a series of [self::A or self::B or …] that is a
bit inelegant. I should rewrite it to use the template-based approach suggested
in the recent “Using node-set variables in predicates” discussion on this list,
as I now prefer that style for element-class helper functions.
- Because you’re solving the reverse problem (breaking content out of an
existing context rather than wrapping it in a new context), be sure to copy
any<p @props/@audience/@product/...> attributes to block elements you push out
of the<p> context.
My template matches like this:
<xsl:template match="*[mine:disallow-inline(.)][node()[mine:is-inline(.)]]">
...
</xsl:template>
which says, “match any element that contains inline content (is-inline()), but
*I* don’t want it to (disallow-inline()). The important distinction is,
disallow-inline() means *I* don’t want it to contain inline content; it has
nothing to do with what DITA itself allows.
So you’ll probably need something more like this:
<xsl:template match="*[mine:disallow-block(.)][node()[mine:is-block(.)]]">
...
</xsl:template>
As for what to include in the lists, I used the content_mode.pl script at
https://github.com/chrispy-snps/DITA-plugin-utilities
to dump out our content models, then did some analysis based on which elements
are permitted in<body>, which elements are permitted in<p>, and so on. That was
a manual effort; maybe some day I’ll script it up so I can regenerate the
element lists as adjust our specializations.
- Chris
XSL-List info and archiveEasyUnsubscribe(by email)
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--