Framemaker Version History

0 views

Skip to first unread message

Elenor Waas

unread,

Aug 3, 2024, 5:02:02 PM8/3/24

to prophtingbipe

Now you can view the complete layout of a DITA map in the Map Editor. When you open a map for editing, it opens the Layout view of the Map Editor. In this view, you can see the map hierarchy in a tree view and also organize or structure the topics in a map.

The Layout view contains a separate tool bar which helps you perform many tasks on the topics present in a map.
You can insert topic references, topic group, key definitions in a map. You can reorganize the topics present in a map by moving them up, down, left, or right. You can also drag-and-drop the topics to move them in a map. The Map Editor also provides the icons to lock or unlock files, check the version history, and do a version label management.

In addition to organizing topics in the map file, you can also add, move, copy, paste, or delete references using the Options menu available for an element in the Layout view. You can also drag-and-drop a topic or a map from the repository panel to the map opened in the Map Editor.

The right panel displays the Content Properties and the Map Properties in the Layout view of the Map Editor. The Inline Attributes defined for the selected topic are displayed against the topic in the Layout view. For example, you can quickly find all topics which have the platform attribute defined as IOS.

AEM Guides now allows the configuration of Inline Attributes by your administrator from the Editor Settings. You can also add new inline attributes or delete the existing ones from the Inline Attributes tab in the Editor Settings.
The configured Inline Attributes defined for a topic are displayed against the topic in the Layout view.

Now the filter search in the repository view has been made more powerful. Two new search criteria, Last Modified and Tags have been added to filter the files and to narrow down your search in the AEM repository:

Adobe FrameMaker was a word or document processor for large or complex documents, including structured documents. It was originally developed by Frame Technology Corporation, which was bought by Adobe in October 1995.

Charles "Nick" Corfield, a mathematician decided to write a What You See Is What You Get WYSIWYG document editor on a Sun-2 workstation while doing his Master's degree at Columbia University. The idea came from his roommate, Ben Meiry, who went to work at Sun Microsystems. They saw that there was a market for a powerful and flexible desktop publishing (DTP) product for the professional market, as the only current substantial DTP product was Interleaf, which ran on Sun workstations in 1981.

Corfield worked quickly so that after only a few months, Corfield had completed a prototype of FrameMaker which was liked by salesmen at the fledgling Sun Microsystems, which needed commercial applications to showcase their workstations graphics. They used the prototype demonstrations so that FrameMaker got plenty of exposure in the Unix workstation arena.

Originally written for SunOS (a variant of UNIX) on Sun machines, FrameMaker was a popular technical writing tool, and the company was profitable early on. Because of the flourishing desktop publishing market on the Apple Macintosh, the software was ported to the Mac as its second platform.

A pre-alpha demo version of FrameMaker 2.0 was included with NeXTSTEP 0.9 in April 1989. The Macintosh version became available in May 1990. Version 2.1 added international support, such European paper sizes, metric measurements, and localization for the Japanese market.

We are a registered charity. Since opening in 2013, over 160,000 people, including 18,000 school pupils, have visited the Centre. Our visitors deserve a space which is engaging and inspiring, where they can feel a sense of adventure, exploration and wonder!

Small donations can be made below or to make the absolute most of your donation, please do consider making a direct bank transfer. Contact us by email using ad...@computinghistory.org.uk to ask for details. If you'd like to chat about supporting us please contact our Partnerships team.

The post discusses a few of the reasons why we may want to write our documents on a wiki and then publish them to other formats, or conversely write the documents using another tool and then publish them to a wiki as one of the delivery formats.

ePublisher is not a Confluence plugin. It is a set of standalone tools that can publish to Confluence as one of the output destinations. ePublisher allows you to transform content from Word, FrameMaker or PDF into a number of different output formats, including Confluence. It also provides a number of styling and design options for you to tailor the output documents.

You will start off with a template created in the original software for your input document(s). For example, if your input documents are in Word, then you will import your Word template into ePublisher. If you also have input documents in FrameMaker then you will need a FrameMaker template to import into ePublisher.

You will import your template(s) and/or sample document(s) into ePublisher Pro. ePublisher Pro will analyse the styles in the imported documents and provide you with a list of styles. You will then map the styles to your requirements for your output documents.

When you deploy your content from ePublisher, it updates any existing pages with the content from the ePublisher source document. In effect, if you have updated the page in Confluence, your change will be overwritten by the ePublisher deployment. The page history retains every version of the page. The comments on the wiki page remain untouched. (This is as you would expect, because ePublisher uses the Confluence API to apply the updates.)

I hope the above step-by-step guide through my experiment will be useful to anyone who wants to try ePublisher with Confluence. This tool will be very useful to people who have a large set of legacy documents that they want to convert to wiki format, or people who want to author their content outside the wiki on an ongoing basis, and convert it regularly to wiki as well as other formats. Single-sourcing of content is great for environments where different readers or customers need their documentation in different formats.

LinkedIn and 3rd parties use essential and non-essential cookies to provide, secure, analyze and improve our Services, and to show you relevant ads (including professional and job ads) on and off LinkedIn. Learn more in our Cookie Policy.

DITAToo Virtual Drive is an addition to the DITAToo CCMS. It gives users access to the repository content directly from Windows Explorer. And thus from any other Windows application, like your favorite DITA editor, or MSWord, Photoshop, Notepad, FrameMaker, all without the need to install a CMS connector.

DITAToo Virtual Drive is a small application running as a service in the background. It creates a virtual drive on your computer. That drive actually is the database. You can access the files and folders just as any other file on your file system. Even more: you can perform database action on the files directly. Check out or check in, update the workflow state, show version history or compare two versions with differences highlighted. Access is very fast, almost like files are locally stored.

Nice thing is that all files, even non-DITA files, are versioned. Or can be assigned a workflow state, can be tagged with metadata for search, or can be put under translation management. So you can go back to a previous version of your unstructured FrameMaker file or branch an older version to create a new variant. Same for MSWord and any other file that's stored on your Virtual Drive.

DITAToo Virtual Drive makes content management collaboration complete. Suppose you have started making DITA topics for your user manual, but still some content is in unstructured FrameMaker files. Other content is in Word files. Using Virtual Drive it's easy to get it all together in one CMS and make it accessible for all your DITAToo users - while maintaining versioning, translation and workflow management on both the DITA topics and the unstructured content.

And there's more. For one project I had to modify a large group of files, spread over different folders. Same modification in each file. In a database client such as DITAToo Author it's very hard to do these kind of modifications. You have to edit each file separately, one by one. In Windows Explorer however, changing files is a matter of selecting the complete set, do a search action using Notepad or Oxygen and replace - update all files in one action! Same for renaming files or any other batch modification.

Of course there's also a drawback. It's so easy to modify files and folders that users are tempted to do so, even when not really necessary. Just drag and drop a new file to or from a folder. Or add temporarily files. Users must be aware that it's still a database they're working in and that the database is a shared environment. But note that when a topic is used by any other topic or project (DITA map) you get at least a warning before removing that topic outside the Virtual Drive, giving you the option to cancel the operation. Files and topics that have a certain workflow state that forbids editing can not be checked out or removed. Topics or files that are checked out by other users are also locked. Even in Virtual Drive. So you could open it, edit and modify but you can not save and check in.

To avoid database disasters the DITAToo administrator can give or deny users access rights to certain folders. So you can protect critical content from being accidentally modified and give users access to only these files and folders they're supposed to work with.

Your core technical writers staff will need the DITAToo Author client to do all kinds of database actions and manage all the content. For regular editing tasks however the virtual drive will be sufficient. Registered DITAToo users get the Virtual Drive as part of the DITAToo license. So they can choose to use either Virtual Drive or the DITAToo client in their daily work.