I am using FrameMkaer 2019 and DITA. In some cases, I need to set the start of value of the ordered list to a different value than 1. How can I do that?
Copy link to clipboard
Do you have the ability (under DITA) to set the Number > Format in Paragraph Designer?
Here's an entry I'm using in a current project:
Although you can use an override to do this (in unstructured FM), I always use dedicated Paragraph tags to do it.
That would have worked, if I would have used fm file format rather than xml.
So I have checked it using fm file format. The WYSIWYG is perfect, as the list starts from the value I set o:<n=22>)\t
But in the pdf the list starts from 1 again!
Did you make similar changes in output template as well?
Hi Amitoj, you mean if I have changed the edd which is imported to the chapter output template?
You can either do in EDD but the easy way would be to do changes in your output template (fm file) similar to what you did for the WYSIWYG view.
maybe I understood you wrong. But the changes I would like to have are local. That is for a specific "ol", I would like to start the list numbering from 22 as an instance but not every time. To do this, in the fm file of that particular case under paragraph designer, I am setting o:<n=22>)\t. The list starts correctly from 22. Now, if I would set this in the template or the EDD, every list would start from 22. Or am I getting it wrong?
Ohh, I got your point:
You can do this in the following way :
Let me know how it went for you.
Moving ahead, We would be making it easier for the user to edit EDD by just importing its corresponding CSS with CSS3.0 support.
Of course the problem here is that the 22 is hardcoded. A useful enhancement would be an autonumber building block that would be based on a particular attribute's value. For example:
or something like that. I would favor enhancements like this over the ability to import CSS into an EDD.
I fully agree with you.
I hope this solves your current problem.
Thanks Pnagpal for the details,
this can possibly solve my current problem. The issue is that I have other lists that start from other values. That means I would need to redo this for every list which starts from an integer other than one; although, most of my lists start from one.
If most of your list starts with one and only few needs some edting in EDD then it won't take more than few min to edit EDD.
That is true. Out of curiosity, can I edit the EDD to create a new "ol" element, say "oln" that takes any integer value "n" as starting point fro the list?
Thanks for the suggestion, We may look into this suggestion in the upcoming release.
There are many opportunities to enhance the autonumber feature:
* A building block for picking up a particular attribute value (to solve the original poster's problem).
* A building block to allow padding on autonumbers (for example, leading zeros).
* Allow character format building blocks to be used in autonumber sequences (instead of just a single character format for the entire autonumber).
* Allow soft-returns in autonumbers.
* Allow End of Paragraph autonumbers to appear directly after the paragraph text instead of at the right margin.
Good point. Can one of you add a feature request and send it across via tracker.adobe.com.
Also please share some of the options that may be helpful for ol22 related request as well. Hopefully we can take it up in an upcoming update.
Hi Amitoj, I opened an issue (FRMAKER-7784). It is not elaborated though...
Hi Amitoj, I noticed that the feature request, I had created a year ago for this case as you recommended, is still open. see FRMAKER-7784 | Tracker (adobe.com) Would it be possible that it would be picked up in some of your next releases as well?
At this point we have added it in an upcoming update but not the one planned in few months time. Someone from engg team would reach out to you to let you know once they have picked this up.
Hi Amitoj, thank you very much.
As long as we're going to wish-list general autonumbering:
Current FM versions offer an impressive list of localized numbering systems, but it's not exhaustive, and probably can't chase every emerging feature request. A more general solution might make more sense.