[Framers] ANN: Bottlenecks

Wed Jun 6 01:07:40 PDT 2018

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>
This has
<codeph>multiple</codeph>
instances of inline
<codeph>markup</codeph>
for your reading pleasure.

</li>
</ul>
<ol>
<li>
This has
<codeph>multiple</codeph>
instances of inline
<codeph>markup</codeph>
for your reading pleasure.

</li>
<li>
This has
<codeph>one</codeph>
instance for your reading pleasure.

</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) 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 (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 causes
the same error to occur in the <ul> as in the <ol>. Similarly, applying
Body_indent to a 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
 within the <ol> because that operation does not cause FM to reformat
the adjacent text segment. Reformatting the or any of its ancestors by
changing the element to itself (e.g., changing the to a , 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 <rick at 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.
>
> rick at frameexpert.com
>
> 585-729-6746 NEW!
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> This message is from the Framers mailing list
>
> Send messages to framers at 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 listadmin at frameusers.com
>