Is there some way to use character formatting in an EDD to underline the title text for elements such as Para0, Subpara1, etc. but not underline the autonumber characters that appear at the left end of each title?
The autonumber prefix can have it's own formatting. Set the autonumber to not have underline, and set the formatting of the "title" para to have an underline property. Should work.
Thanks. I see that under PropertiesNumbering where I declared my AutonumberFormat, there is also AutonumCharFormat. Is there syntax I can enter here that means "no underline"?
The AutonumCharFormat is a character tag name. You'd have to define the character tag in your template, and make sure the Underline property is deselected in that tag definition.
Not sure if you're doing this, but it's really best to have as much of the formatting and properties defined in the template rather than the EDD. Instead of setting an "Underline" property in the EDD for your paragraph format, just apply a para tag that's defined in the template. You can set the properties for that tag to include Underline or whatever you want without needing to edit the EDD.
Thanks for your advice. I have been doing everything in the EDD and importing element definitions. I'll try doing more in the template itself.
Yeah .. way easier to manage formatting in the template than in EDD context rules.
I beg to differ. There are certainly some things that must be defined in the template, such as the one you noted--a character format that is used for an autonumber. And there are environments when using a template is helpful or even necessary. If, for instance, you have a follow-on process based on paragraph formats, you need individual paragraph formats.
Nevertheless, if you have a set of closely related paragraph formats, progress modification of a base format can greatly simplify development and testing. Suppose for instance that formatting of <Note>, <Paragraph> and <ListItem> elements differs only in the autonumber and indentation properties. I've worked on projects where it would take hundreds of paragraph formats to account for all the combinations of nesting but only a few rules to set the relevant properties. Furthermore, using the EDD often lets the developer think about one element at a time without having to plan for various combinations. For example, suppose <ListItem> is progressively indented for nested lists and <Note> is indented relative to the previous list item. Then the EDD developer can merely specify the additional indentation for the <Note> and not even have to consider whether or not the <Note> is in a <List> (let alone how many levels of containing <Lists> there are). Suppose, however, individual paragraph formats are used and there are 7 levels of nesting involved; there are then 8 possible <Note> formats; one for a <Note> within a <List> at each level and one for a <Note> outside of a <List>. And now imagine a new book design that adds 2 more levels, changes the font and hence the incremental indent change. That's 8 <Note> formats that must be updated and who knows how many others. If the indent increment is the same for every level, it might be possible instead to handle most of the work just by changing the value of a variable that is used repeatedly in the EDD.
As usual, the real answer is .. "it depends". Of course, there are reasons to define properties in the EDD. I'm not saying that you should *never* do that. It may depend on the structure of the EDD (does it have insets for example), and who is doing the maintenance of the formatting. Many things to consider when deciding where to define the formatting. I do think that "in general" for a typical structure application (if there is such a beast), it's best to keep the formatting in the template where possible. Editing the template requires touching fewer files than does editing the EDD, that's not in question.
Based on Mongo-man's messages, I was getting the impression that he might not have been aware of the fact that the properties don't all need to be in the EDD, so was just pointing out the alternative.
Good morning, Scott.
As usual, you and I are mostly in agreement; certainly your comments on AutonumCharFormat were very appropriate.
I do find that whatever a typical application is, it probably involves one or more clusters of pgf fmts that differ only by a very few properties and for those both the effort and the chance of human error are much less if the EDD simply codes the differences. This is especially true if the structures can nest. For example, suppose notes are italicized and lists are indented. If the EDD specifies the angle in the rule for note and the indentation in the rule for list, then if a note happens to occur in a list or the other way around, the result is both italicized and indented. If you are working solely with pgf fmts, you need to define fmts and write rules for all the possible combinations. Yuck.
Lynne and Scott,
I appreciate all of your comments. Scott is correct that the option of formatting in the template (when appropriate) had not occurred to me. I had only been exposed to doing all formatting in the EDD. Based on the discussion here, I created an "autonumber" character tag in my template and declared that as my AutonumCharFormat for the desired Elements in my EDD. Now my Para0 and Subpara(x) title text is underlined but the associated numbering is not - and I learned some good things. Thanks to both of you for your help.
I find that it can depend on the expertise of the person working with the app. I think that more people feel more comfortable editing tag definitions in the template than working with EDD context rules. Some things clearly require the EDD, and if the person creating the app is the same person who will maintain it, then by all means go with the possibly more efficient coding in the EDD. But if this is to be handed off to someone else who may need to make future adjustments to the formatting, it is often better (IMHO) to go with the possibly excessive number of para tags than to force that person to dive into the EDD.
As with all of these things, there is no "right" way for all, and may need a better understanding of the future use of the app to know which direction not go.