Hi Rick There is this very old FrameMaker bug where text is formatted incorrectly if there is inline markup in list items (ol/li or ul/li). It has been described at length here and Frame experts like Lynne Price and Scott Prentice have also been looking into it:
https://groups.yahoo.com/neo/groups/framemaker-dita/conversations/topics/3122?guccounter=1 So far, I haven't seen a good solution for this one, so my workaround is to specify the font "hard-coded" in the EDD, which I don't really like. Maybe a script could help to "retag" the text to apply the correct formatting? This was Lynne's "recap" of the problem: _________________________________________________________ Jon, Scott, et. al., Thanks, Jon, for the simple test file. A recap is that in your DITA application, text in a paragraph in an item in a bulleted list has the correct font even when it occurs between two inline elements. However, text between two inline elements uses the wrong font family in a paragraph in an item in a numbered list, although text at the beginning or end of such a paragraph uses the correct font. The incorrect formatting is EDD-specific; it does not appear with other format rules for the same structure. I believe I have isolated the problem. It does indeed seem to be an FM bug, which by the way also occurs in FM8 and FM7.2. I disabled the DITA API clients for my FM9 testing and thus have confirmed that the problem is not a DITA issue. The bug is that when applying first pgf rules, FM applies the default pgf font to a text segment at the beginning or end of a paragraph but not to medial text segments. In detail, the test data has the structure: <conbody> <ul> <li> <p>This has <codeph>multiple</codeph> instances of inline <codeph>markup</codeph> for your reading pleasure. </p> </li> </ul> <ol> <li> <p>This has <codeph>multiple</codeph> instances of inline <codeph>markup</codeph> for your reading pleasure. </p> </li> <li> <p>This has <codeph>one</codeph> instance for your reading pleasure. </p> </li> </ol> </conbody> The expected formatting is that text outside the <codeph> elements should use Calibri and text inside the <codeph> should use Courier New. The only incorrect formatting is that of "instances of inline" in the first <li> in the <ol> which appears in Minion Pro. Note that this <li> is identical to the one in the <ul> but that the entire <ul> is formatted correctly. The relevant format rules are: 1) <li> has a text fmt rule that applies pgf fmt ul.bullet.indent or ol.num.indent depending on whether it occurs in a <ul> or an <ol>. Both these pgf fmts use Minion Pro. 2) <li> has a first pgf rule that applies pgf fmt 1FStep, 2FStep, or Bullet respectively to the first child of an <ol>, elsewhere in an <ol>, and within a <ul>. These pgf fmts all use Calibri. 3) <p> has a text format rule that applies pgf fmt Body_indent which uses Calibri. When FM applies the format rules, it first applies the text fmt rules and then the first pgf rules. Within the <ul>, it therefore applies ul.bullet.indent to the <li> (applying Minion Pro) and then Body_indent to the <p> (applying Calibri). It then applies Bullet, applying the default font only to the initial and final text segments. Since Bullet uses the same font family as Body_indent, the fact that it does not reapply Calibri to the medial text segment doesn't matter. To format the <ol>, however, it applies ol.num.indent to the <li>, which applies Minion Pro to all text segments. Then it applies the first pgf rule to change the default pgf font to Calibri, but applies this change only to the edge text segments, leaving Minion Pro on the medial one. As this analysis suggests, removing the text format rule on <p> causes the same error to occur in the <ul> as in the <ol>. Similarly, applying Body_indent to a <p> in a <li> in an <ol> avoids the bug there just as it does in the <ul>. Jon did not see the problem when he inserted a new inline element in the <p> within the <ol> because that operation does not cause FM to reformat the adjacent text segment. Reformatting the <p> or any of its ancestors by changing the element to itself (e.g., changing the <p> to a <p>, the <li> to an <li>, etc.), or by importing element definitions while removing overrides, does cause FM to reformat the critical text segment, and to reformat it incorrectly. When FM opens the XML version of the document, however, it delays applying format rules until it has imported the entire document, thereby triggering the bug. By the way, the original EDD applies pgf fmts and char fmts rather than applying individual properties as needed. My tests included using specific properties but it did not change the results. I have reduced the EDD from the original 315 pages to a page and a half. Will keep a copy for a few days if anyone wants to see it. --Lynne _____________________________________________________ Kind regards Yves On 4 June 2018 at 15:57, Rick Quatro <r...@rickquatro.com> wrote: > Hi Framers, > > > > Occasionally I like to query the FrameMaker community to find out about > some > of their FrameMaker bottlenecks. What are the things that slow you down, > make your work tedious, and frustrate you about FrameMaker? Some of your > complaints and suggestions have lead to useful solutions in the past. Thank > you very much. > > > > Rick > > > > Rick Quatro > > Carmen Publishing Inc. > > r...@frameexpert.com > > 585-729-6746 NEW! > > > > > > > > > > _______________________________________________ > > This message is from the Framers mailing list > > Send messages to framers@lists.frameusers.com > Visit the list's homepage at http://www.frameusers.com > Archives located at http://www.mail-archive.com/ > framers%40lists.frameusers.com/ > Subscribe and unsubscribe at http://lists.frameusers.com/ > listinfo.cgi/framers-frameusers.com > Send administrative questions to listad...@frameusers.com > _______________________________________________ This message is from the Framers mailing list Send messages to framers@lists.frameusers.com Visit the list's homepage at http://www.frameusers.com Archives located at http://www.mail-archive.com/framers%40lists.frameusers.com/ Subscribe and unsubscribe at http://lists.frameusers.com/listinfo.cgi/framers-frameusers.com Send administrative questions to listad...@frameusers.com