With our custom structured application in FrameMaker 2017, insertion of an inline element, in this case a //defterm, followed by the entry of text, should result in the text being italicized. However it does not. If the //defterm element is selected, and then in the Element pod, changed to a //defterm, the text is italicized. Alternatively if the text is entered, selected, and then //defterm chosen in the element pod, the text is italicized as expected. The italicization in the EDD is provided by a Font Properties element (PropertiesFont). It looks to me like the EDD rules are being applied correctly if I look in the Show Element Context pod. However FrameMaker is not applying the Angle for the PropertiesFont. This image () shows the text where the italicization should occur but does not, and this image () shows the correct italicization.
I have tried to recreate the problem using the sample Business structured application by using a PropertiesFont to change the //Labels element to be italicized when inserted. This works every time. I will try with a more complex application like DITA later.
In FrameMaker 11 this works as expected either way.
Has anyone come across this?
It is difficult to diagnose formatting problems without a copy of the actual incorrect document. However, based on the information you provided, in FM 220.127.116.115, I created an EDD with the following element definitions:
I then imported element definitions from the EDD into a new portrait document and entered the following content,:
In my first test, I inserted the <defterm> element and typed the text "some definition" within it. As you can see, the formatting was correct, which seems to be inconsistent with the results you have obtained. I then unwrapped the <defterm> which removed the italics but left "some definition" selected. I wrapped <defterm> around the selection and the text once again was italicized. I also changed the existing <defterm> to a <defterm> which caused FM to reformat the element and it was still italicized. These steps seem to be consistent with the results you report.
Is your copy of FM 2017 fully updated? Have you rebooted your computer and tried again? Do different documents based on the same template behave the same way? If so, you might try MIF washing the problem document. If you still cannot find the problem, I would either start with a very simple EDD that works and gradually make it more complex until it fails or matches your actual EDD or simplify the actual EDD until you get something that works or can no longer be simplified. You might also use a template that is as much like a new portrait document as possible. Good luck.
As always your responses are helpful and I really appreciate the effort you put in to helping analyse the problem.
- My customer uses a very complex custom structured application which contains propriety information so it is not easy to share details. In the past I have tried to recreate the problem in a sample application, which is sometimes easy and sometimes not so easy.
- Your rather excellent little application mirrors what I tried with the letter template in the Business sample application. The //txt element has pages of rules in the custom structured application so it is no surprise both of our efforts did not result in the problem.
I will try and distil enough of the complexity until I have something I can share with Adobe.
Thanks again for your response.
I forgot to respond to your other suggestions:
- Frame 2017 has been updated to 18.104.22.1680 (Update 3).
- The problem happens on different computers in different documents and is easily reproducible.
- I will try the adding complexity approach.