Here's an example of a line from one of my DITA topics:
Code: Select all
<p outputclass="equation">f = 18/√(δ) </p>
Code: Select all
<p>f = 18/√(δ) </p>
Code: Select all
<p outputclass="equation">f = 18/√(δ) </p>
Code: Select all
<p>f = 18/√(δ) </p>
For better (rather than worse) MadCap isn't using Open Toolkit (it's the whole reason I'm using Flare, a serious bug prevented me from generating my books, but Flare with a little coaxing worked fine).super-structure wrote:I'm using Flare v6.1.0 to import a DITAMAP (and associated .xml files) into a project for producing a .PDF deliverable. I've noticed that my outputclass attributes on various elements seem to be ignored. This is surprising, as these are generally used to generate element classes in transformed output from the DITA-OT.
I don't see DITA becoming a passing trend in the next few years.wbrisett wrote:For better (rather than worse) MadCap isn't using Open Toolkit (it's the whole reason I'm using Flare, a serious bug prevented me from generating my books, but Flare with a little coaxing worked fine).super-structure wrote:I'm using Flare v6.1.0 to import a DITAMAP (and associated .xml files) into a project for producing a .PDF deliverable. I've noticed that my outputclass attributes on various elements seem to be ignored. This is surprising, as these are generally used to generate element classes in transformed output from the DITA-OT.
That being said, you're correct, the output class should be honored somehow. Thus the bug in MadCap's database. I have several outstanding bugs regarding DITA imports, and whenever I've asked in the past on this forum about DITA, few if any people were actually using DITA, so it didn't sound like it was going to be a high priority for MadCap, but I'm very happy to see other DITA users because I suspect as they grow in that space, we'll start seeing some additional effort in that area for MadCap. They are after all on the OASIS committee.