6.0 Default DITA Map Collapse topicmeta

[BrettMcCorkle]

Hello,

We're testing 6.0, hopfully implementing soon. There's one thing that bugs me that I can't find a setting for. By default, Arbortext is now collapsing the metadata tag and its sub tags for DITA maps and bookmaps, <topicmeta> and <bookmeta>.

Does anyone know how I can disable this? My users need to fill in several metadata tags, making them expand all of these tags each time they need to change something will be a headache for them, and will probably cause them to forget or not bother.

Thanks.

[ebenton]

You could try using some ACL. This might work:
i = arr[1];
if (oid_find_children(i, arr, "metadata"))
{
for (i in arr) { oid_expose(arr[i], 0); oid_expose(arr[i], 1); }
}
I haven't tried it, so no guarantees.

oid_expose(oid[, newval[, descend]])
This function returns 1 (True) if the content for the element identified by oid are displayed
in the Document Map window. Otherwise, it returns 0.
If newval is specified, it changes the state of the content display for oid. If 0, the content is
collapsed. If non-zero, the content lines for the element are displayed.
If descend is specified and non-zero, then oid_expose changes the exposed state of all
children of oid, recursively.
Note, the effect of this function is visible in the Document Map and Column view only.
The expose bit is independent of detailing, which is shown only in non-Document Map or
Column views.

[BrettMcCorkle]

Thanks, Ed. I'll have to try getting that ACL to work. My first attempt wasn't successful, but I haven't had a lot of time for it so far today. I forgot to mention this is for the tag view.

I was hoping this was a configurable item since 5.4 didn't behave this way. Oh well, hopefully I can get the behavior I want through the ACL.

In Reply to Ed Benton:

You could try using some ACL. This might work:
i = arr[1];
if (oid_find_children(i, arr, "metadata"))
{
for (i in arr) { oid_expose(arr[i], 0); oid_expose(arr[i], 1); }
}
I haven't tried it, so no guarantees.

oid_expose(oid[, newval[, descend]])
This function returns 1 (True) if the content for the element identified by oid are displayed
in the Document Map window. Otherwise, it returns 0.
If newval is specified, it changes the state of the content display for oid. If 0, the content is
collapsed. If non-zero, the content lines for the element are displayed.
If descend is specified and non-zero, then oid_expose changes the exposed state of all
children of oid, recursively.
Note, the effect of this function is visible in the Document Map and Column view only.
The expose bit is independent of detailing, which is shown only in non-Document Map or
Column views.

[ebenton]

You might also try setting up your DCF file to define the tags you want to expand as divisions. Then the view-collapse/expand divisions menu selection could toggle between expanding and collapsing them.

[DavidA.Helfinst]

Greetings,

To correct this in the edit view, you can change the preference "docmapsync" to off. This can be done in the command line via "set docmapsync=off" or in the Preference?View panel. This setting will be saved when you save the configuration.

Note that this only happens if you have a column-view, or docmap view and an edit view in the same window. If you just have an edit view, then the edit view does not have the collapsed tags by default.

As you noticed the oid_expose() function is for column-view and for docmap view. That was the intent of the change that was made, but with the preference docmapsync=on set, this "leaks" over into the edit view when the edit view for the ditamap is set up initially.

Unfortunately with docmapsync=off, there is a side-effect of this is that if you move the cursor around in the Edit view, the docmap or column-vie cursor will not warp to the location you are going to in the edit view.

I have filed an SPR to fix this "leakage" into the Edit view without having to change the preference setting above.

Thanks.

- Dave H.

Dave Helfinstine
-

[BrettMcCorkle]

Thanks, Dave. That fixed it. Though, it does seem more like a bug than an expected behavior that it does that when the sync is turned on. Is there an SPR to address this?

[DavidA.Helfinst]

Greetings,

I agree that this is a bug. I filed SPR 2152546 for this issue. The SPR is slated to be fixed in the next maintenance release of 6.0. you can contact PTC Technical Support if you need more detailed information.

Thanks.

- Dave H.

Dave Helfinstine
-