Samples: Showing tag names in the Structure View

[Su-Laine Yeo]

The attached CSS files change the styling of the Structure View pane for DITA documents in XMetaL Author Enterprise, so that tag names are shown.

Here is how the Structure View appears by default for task topics in XMetaL 6.0:



Here is how the Structure View will appear after installing the attached CSS files:



Showing tag names in the Structure View pane can be helpful for "seeing where you are in the structure" when you are working in Normal View.

To install the revised Structure View CSS files:
1) Open your C:\Program Files\XMetaL x.x\Author\DITA\XACs folder. Back up the contents of this folder.
2) Download and unzip the attached XACs.zip file.
3) Copy all folders from the unzipped XACs folder into C:\Program Files\XMetaL x.x\Author\DITA\XACs folder
4) Open a DITA topic or map, then click View > Structure View.

[dcramer]

Is there a way to make the lines in Structure View wrap so that SV is exactly like the main pane in tags on view? That would let people have the best of both worlds, especially with the wide LCD screens people tend to have.

Another improvement would be to make the synching of the SV and main view optional (i.e. provide a button and API for toggling SV synching on and off and/or a "synchSV" button/method). Then you could scroll to different locations in the document in each view and compare things (something I've asked for and IIRC others have asked for too).

Thanks,
David

[Derek Read]

The CSS in structure view supports the same CSS properties that the main editing window does, plus the few extra Structure view only XMetaL CSS extension @statements for showing special icons before elements. So, yes, you can do this. If any parent element has white-space property set on it you will need to reset it for any children if you want it to be different, keeping in mind that Structure view inherits settings from the main editing view first.

By default the white-space property is not set, so line wrapping should occur unless that property is set for the same element in the main editing window, or one of the parent elements. If you do not want line wrapping to occur in Structure view but it does for the same element in the main editing view then the same CSS settings available for use in the main editing view for the white-space property (pre, nowrap, etc) can be used in Structure view to override that.

If you want Structure view to appear the same as it does in the main editing view the easiest thing to do is provide an empty (or no) dtdname_structure.css file with your customization. Structure view inherits all the CSS from the main view first then cascades the dtdname_structure.css file on top of that, overriding anything previously set when CSS selector specificity is greater. So, if you provide no dtdname_structure.css file the Structure view should appear as close to Normal view as possible. That is typically where you should start, only adding settings to the Structure view CSS where you want elements to appear different from TagsOn / Normal view.

As for synching the two views during scrolling there is an INI setting for this listed in the Customization Guide. The request for an API to toggle this is in our list of feature requests but has yet to make it onto a release schedule.

[dcramer]

Thanks for that information...I was confused/misremembering what my problem with SV was. What I really want is structure view in one window and normal view in the other.

I see now that if I use a blank css for my sv css (I'm using that switchSVStyles function from Journalist so I can toggle between sv csses), then almost looks like Normal view. The big exception is tables, which are mutilated in SV and not rendered as tables like they are in the main pane. Can SV be made to render tables wysiwyg? 

If it weren't for the mutilated tables, then you could use sv as a tags off view and have tags on in the main pane. If you're careful not to click in SV, then there won't be any synching (however, there's no way to synch sv to the main pane).

Regarding (not) synching, I'm using 4.6 and in the docs only see keep_sv_mv_in_sync_by_default which is described as follows: "This makes element collapsing and expanding which you do in either the Structure View or the Main View, get automatically done in the other view." and is already set to NO by default. Is there another variable that's not mentioned in the doc?

I think the feature request is:
1. Same rendering of tables in SV as main pane.
2. Ability to turn off the synchronizing of  the main pane to the SV location when you click in SV. Preferably via an api rather than ini setting).
3. Ability via an api/button to synchronize SV to main pane.
4. Ability via an api/button to synchronize main pane to SV.
5. Support for @sq-start-and-end-tags css rule (that makes structure view same as tags on view in main pane)

After all that's done, SV is just like the main pane and what makes one sv and the other the main pane is just some css differences. Then there's nothing (other than system limitations) from adding a third (or fourth) new view. I guess once we're all using machines with 8 GB of ram and 50 inch monitors, we may want to have four views of the same document side by side (perhaps with each highlighting different information), so I guess name the methods in your API accordingly :-)

Thanks
David

[Derek Read]

Yeah, the main limitation with SV CSS is that it essentially supports display:block/inline/none only. Tables and lists are not rendered as such (though for lists you can come close I guess).

All of your proposals are interesting. I'll record them in our feature requests database. It almost sounds like you want to be able to duplicate the feature that MS Word has where you can split the editing window in half and edit the same document in either half.

[dcramer]

Yes, that's exactly what I had in mind. In fact, there should be a feature request logged long ago asking for in terms of the MS Word functionality (or emacs, which allows an indefinite number of splits), but it seemed like it would be a major addition affecting core code of the product. In the course of this thread, however, I realized that with css switching, I could almost make SV do what I want, so maybe it's not such an impossible dream after all.

Thanks,
David