Integrating Attribute Domains
Attribute domains are defined in a single .ent file that defines a single parameter entity with the entity declaration and
a single general text entity that provides the 
@domains
attribute contribution for the module.
To integrate an attribute domain into a DTD document type shell, follow the steps shown here. If you do not already
have your own document type shell for the topic or map type you want to integrate with, copy the closest starting
point (e.g., one of the D4P .dtd files) and then modify that. [Add reference to specialization tutorial once it is updated
to DITA 1.2.]
1. Insert a declaration for and reference to the attribute domain's .ent file.
Look for a comment that looks like this:
<!-- ============================================================= -->
<!--                    DOMAIN ATTRIBUTE DECLARATIONS              -->
<!-- ============================================================= -->
After this comment, add an entry that looks like this (e.g., for the d4p_renditionTarget attribute domain):
<!ENTITY % d4p_renditionTargetAtt-d-dec     
PUBLIC 
"urn:pubid:dita4publishers.sourceforge.net:doctypes:dita:modules:d4p_rendi
tionTargetAttDomain:entities" 
"d4p_renditionTargetAttDomain.ent"                                        
>
%d4p_renditionTargetAtt-d-dec;
2. Add the domain's parameter entity the 
%props-attribute-extensions;
parameter entity.
Find a comment that looks like this:
<!-- ============================================================= -->
<!--                    DOMAIN ATTRIBUTE EXTENSIONS                -->
<!-- ============================================================= -->
Immediately following that comment should be a line that looks like this:
<!ENTITY % props-attribute-extensions "" >
Between the double quotes (or before the ending double quote if there is already a value in the declaration, add a
reference to the parameter entity defined in the .ent file included in the previous step. The parameter entity should
be named "%attributeNameAtt-d-attribute" but you will need to look in the .ent file to make sure. The result
should look like this:
<!ENTITY % props-attribute-extensions "%d4p_renditionTargetAtt-d-
attribute;" >
Note the "%" at the start of the entity name (this is a parameter entity reference open character) and the ";" at the
end (this an entity reference close character).
3. Add a reference to the domain's 
@domains
attribute contribution entity to the "included-domains" general entity
declaration.
Look for a comment like this:
<!-- ============================================================= -->
<!--                    DOMAINS ATTRIBUTE OVERRIDE                 -->
<!-- ============================================================= -->
DITA For Publishers | The DITA For Publishers Markup Vocabulary | 31
Convert pdf to word and edit text - Convert PDF to txt files in C#.net, ASP.NET MVC, WinForms, WPF application
C# PDF to Text (TXT) Converting Library to Convert PDF to Text
convert pdf into text file; convert pdf file to text
Convert pdf to word and edit text - VB.NET PDF Convert to Text SDK: Convert PDF to txt files in vb.net, ASP.NET MVC, WinForms, WPF application
VB.NET Guide and Sample Codes to Convert PDF to Text in .NET Project
change pdf to txt file; extract text from pdf
And then a declaration like this:
<!ENTITY included-domains 
""
>
Your shell may already have things inside the double quotes.
Within the double quotes add a reference to the domains attribute component entity for the domain. This should be
named like "&attributeNameAtt-d-att;" but you will need to look in the .ent file to make sure. The result should
look something like this:
<!ENTITY included-domains 
"
&d4p_renditionTargetAtt-d-att;
">
The line breaks within the declaration and within the double quotes don't matter. It is convenient to put each entity
reference on its own line so its each to update the declaration as you add or remove domains.
Note the "&" at the start of the entity name (this is a general entity reference open character) and the ";" at the end.
Your shell should be ready to use. How you test it depends of course on your working environment. Deployment and
testing in specific tools is beyond the scope of this document.
DITA For Publishers Vocabulary Reference
This section provides reference entries for each of the DITA for Publishers element types and attributes.
This section is an alphabetical reference by element type and attribute name for all the DITA for Publishers
vocabulary modules.
DITA For Publishers | The DITA For Publishers Markup Vocabulary | 32
VB.NET PDF Convert to Word SDK: Convert PDF to Word library in vb.
VB.NET Tutorial for How to Convert PDF to Word (.docx) Document in VB.NET. using RasterEdge.XDoc.PDF; Convert PDF to Word Document in VB.NET Demo Code.
convert pdf to word and edit text; convert image pdf to text pdf
C# PDF Convert to Word SDK: Convert PDF to Word library in C#.net
third-party software, you can hardly edit PDF document Under this situation, you need to convert PDF document to some easily editable files like Word document
convert pdf file to text online; convert pdf to txt batch
The DITA For Publishers Word to DITA and DITA to
InDesign Tools
This part documents the Word-to-DITA and DITA-to-InDesign transformation frameworks.
The Word-to-DITA and DITA-to-InDesign transformation frameworks enable the use of DITA with Word as the
primary authoring and editorial workflow vehicle and InDesign as the primary print production technology.
These two frameworks reflect the fact that for many publishers it is simply impractical or impossible to use an XML-
first or XML-only editorial process, especially when dealing with external authors and subject matter experts. For
good or ill, Microsoft Word is the form most authors can or will use. Likewise, InDesign is almost universally
accepted as the tool for producing high-quality typeset publications. Without ways to integrate these two technologies
into a DITA-based environment, the use of DITA (or XML in general) is a non-starter for most Publishers.
The technologies documented in this part are frameworks, meaning that they require some degree of configuration
and customization to be useful in a specific context—you cannot simply take an arbitrary Word document and expect
any transform to give you a useful XML result. Likewise, the use of InDesign (or any desktop publishing system)
requires a mapping to specific styles and layouts that will always be specific to your documents.
Given that configuration is always required, these frameworks have been designed to make the configuration and,
where necessary, customization process as easy as possible.
The Word-to-DITA transformation can be configured largely or entirely (depending on your requirements) using an
XML configuration file to map Word styles to DITA markup structures. It can handle going from Word documents to
single topics or to complete systems of maps and topics.
The DITA-to-InDesign transformation is configured through a simple-to-modify XSLT module that maps DITA
elements in context to InDesign style names.
When requirements are not too extreme it is possible to get a demonstrable end-to-end-with-DITA-in-the-middle
system going in less than a day, including defining custom vocabulary modules.
These frameworks don't do everything you may want to have and are not intended to compete with or replace
commercial tools. They are intended primarily to get you started and to provide a starting point for further
development and extension.
For example, Word-based authoring can be made more effective and reliable by using Word macros to guide authors
in styling. Likewise, InDesign scripting can go a long way toward automating some repetitive layout tasks by taking
advantage of the additional structure provided by base markup. There are a number of commercial products that offer
support for authoring XML in Word or generating XML from styled word, such as the Inera eXstyles product
(www.inera.com).
Finally, the production of complete, print-ready publications from XML through InDesign is an inherently
challenging process. The DITA For Publishers DITA-to-InDesign framework does not attempt to solve that problem.
It is intended primarily to support processes where designers must be directly involved in the layout, such as
magazine production, or where there is no attempt to completely automate composition, but simply to provide the
input to an more traditional manual layout process.
To fully automate production from XML the Typefi product is the best solution (www.typefi.com). Typefi enables up
to 100% automation of InDesign-based production where book design is consistent across titles, e.g., for series
publications like travel guides, journals, and so on. Typefi provides a level of sophistication that would be impossible
(and pointless) to replicate. Typefi is a for-cost product but it offers a tremendous value when automated composition
is a requirement.
DITA For Publishers | The DITA For Publishers Word to DITA and DITA to InDesign Tools | 33
C# Convert: PDF to Word: How to Convert Adobe PDF to Microsoft
C# Convert: PDF to Word: How to Convert Adobe PDF to Microsoft Word (.docx) File. Empower C# users to easily convert PDF document to Word document.
convert pdf to searchable text online; converting pdf to editable text for
VB.NET Create PDF from Word Library to convert docx, doc to PDF in
XDoc.HTML5 Viewer. view, Annotate,Convert documents online using ASPX. XImage.Raster. XDoc.PDF. Scanning. Microsoft Office. XDoc.Word. XDoc.Excel. XDoc.PowerPoint
convert pdf image to text online; convert scanned pdf to word text
The Word-to-DITA Transformation Framework
The Word-to-DITA (Word2DITA) transformation framework enables the reliable generation of maps and topics form
styled Word documents.
The Word-to-DITA transformation framework provides a general facility for converting styled Microsoft Word
documents into DITA maps and topics. It is intended primarily to support ongoing authoring of DITA content using
Microsoft Word, where all authoring is done in Word and DITA maps and topics are generated from the Word on
demand. It does not provide a way to go from DITA back to Word (although that would be technically possible, if not
trivial).
The Word-to-DITA transformation is not intended to support general data conversion from arbitrary Word documents
to DITA. It requires at least some amount of consistent styling. However, it may still produce useful starting points
from lightly-styled documents. Try it and see. Because the output of the transform can be quite complete, it may be
most effective to do data cleanup in Word (that is, applying appropriate styles) and then use the transform to generate
more-or-less ready-to-use maps and topics, rather than generating DITA content that needs significant rework to be
usable.
The Word-to-DITA process can do any of the following:
• Generate a single DITA topic document from a single Word document
• Generate a single DITA map document and one or more topic documents from a single Word document
• Generate a tree of maps and one or more topic documents from a single Word document.
Transformations are from Word documents using a specific set of named styles to DITA documents of any type. The
transformation is defined entirely or mostly through a declarative style-to-tag map that defines how each Word
paragraph and character style maps to specific DITA structures.
The declarative style-to-tag map makes it quick and relatively easy to set up and maintain conversions. As long as the
style-to-tag mapping is sufficient no XSLT programming is required.
If the style-to-tag map is not sufficient then you can extend the base Word-to-DITA transform using XSLT. Some
reasons to extend include:
• Handling complex structures that cannot be expressed with declarative mapping (usually deeply-nested structures)
• Implementing custom rules for assigning element IDs.
• Implementing custom rules for constructing map and topic filenames.
The Word-to-DITA transform can be used either through the DITA Open Toolkit or as a standalone XSLT
transformation (for example, to embed it in a CMS-managed tool chain). While it is packaged as an Open Toolkit
plugin, it has no dependencies on any Toolkit components—it just uses the Toolkit's processing framework to make it
convenient to apply the transform.
Getting Started With The Word2DITA Transform
How to set up an Ant task to convert a Word document to DITA using the Open Toolkit
The Word2DITA transform is packaged as an Open Toolkit plugin (see Generating DITA from Documents (Word-to-
DITA Transformation Framework) on page 25). This makes it easy to apply the transform to Word documents using
an existing Open Toolkit installation.
The basic steps to follow are:
1. Deploy the DITA for Publishers Toolkit plugins to your Open Toolkit (see Installing the Toolkit Plugins on page
11).
2. Create a file named build.properties in your home directory (e.g., /Users/ekimber) and in that file put
a line like this:
dita-ot-dir=c:/DITA-OT
Where the part in bold reflects the location of the Toolkit on your machine.
DITA For Publishers | The DITA For Publishers Word to DITA and DITA to InDesign Tools | 34
C# Create PDF from Word Library to convert docx, doc to PDF in C#.
A convenient C#.NET control able to turn all Word text and image content into high quality PDF without losing formatting. Convert multiple pages Word to
convert pdf images to text; converting pdf to text
C# PDF Text Extract Library: extract text content from PDF file in
source PDF document file for word processing, presentation extract text content from source PDF document file obtain text information and edit PDF text content
convert pdf file to txt file; best pdf to text converter for
3. Copy the word2dita/all_defaults directory to a convenient place. This will be the starting point for your
word-to-DITA transformation configuration.
4. Edit the file dita-ot-run-word2dita.xml and change this line:
<property name="args.input" 
location="${myAntFile.dir}/
word2dita_single_doc_to_map_and_topics_01.docx"
/>
To reflect the filename of the Word document you want to convert.
5. Edit your Word document and make sure that the first paragraph in the document is styled with the "Title"
paragraph style—you may need to add a new paragraph. This paragraph defines the map title and signals the
generation of the root output map. This setup is required by the default style-to-tag mapping.
6. Run the dita-ot-run-word2dita.xml with Ant:
ant -f dita-ot-run-word2dita.xml
If you've set the dita-ot-dir Ant property correctly then it should run and you should get some output. You should
get a map and some number of topics, one for each Heading 1, Heading 2, Heading 3, and Heading 4 paragraph in
your Word document.
The Toolkit log will include messages from the Word-to-DITA transform, which will report unmapped paragraph and
character styles. By default, any unmapped paragraph style is mapped to 
<p>
, so you will usually get valid, if not
ideal, output from the default mapping.
Once you have verified that you can get something from the transform you are ready to start configuring the style-to-
tag mapping to reflect your specific requirements and Word documents. You will likely find that you also need to
refine how your documents are styled so that they map most effectively.
Finally, remember that the Word-to-DITA process is a work in progress and there is always room for improvement.
Please report any bugs or feature requests to the DITA for Publishers bug tracker on SourceForge (https://
sourceforge.net/tracker/?group_id=262530&atid=1259341). The Word to DITA transform has been used in
production by several companies but for a relatively narrow set of requirements, so I cannot claim to have tested it
broadly.
Remember too that the Word to DITA framework is open source, which means I welcome fixes and enhancements
from the community.
Generating DITA from Word Using the Toolkit Plugin
How to use the Word-to-DITA Toolkit Plugin to generate DITA content from Word documents.
To use the transformation as a Toolkit plugin simply deploy the DITA for Publishers Toolkit plugins to your Open
Toolkit directory. The Word-to-DITA transformation type is "word2dita".
Required Parameters
args.input
The absolute filename and path of the DOCX file to process.
w2d.style-to-tag-map
The absolute filename and path of the style-to-tag mapping to use.
Optional Parameters
output.dir
Specifies the absolute path of of the directory to contain the generated output.
w2d.clean.output.dir
When set to "true" deletes any files in the output directory before running the generation.
w2d.filter.br
DITA For Publishers | The DITA For Publishers Word to DITA and DITA to InDesign Tools | 35
C# PDF Convert to HTML SDK: Convert PDF to html files in C#.net
easy for C# developers to convert and transform style that are included in target PDF document file original formatting and interrelation of text and graphical
convert scanned pdf to text online; convert pdf photo to text
VB.NET PDF Convert to Jpeg SDK: Convert PDF to JPEG images in vb.
C#.NET convert csv to PDF, C#.NET convert PDF to svg, C#.NET convert PDF to text, C#.NET convert PDF to images VB.NET How-to, VB.NET PDF, VB.NET Word, VB.NET
c# convert pdf to text; convert pdf to openoffice text
When set to any value (e.g., "true"), filters out literal break characters, which are otherwise
preserved in the DITA output as 
<br>
elements.
w2d.filter.tabs
When set to any value (e.g. "true"), filters out literal tab characters, which are otherwise preserved
in the DITA output as 
<tab>
elements.
w2d.root.output.filename
The filename to use for the root output file (the root map or root topic depending on how your
mapping is set up), e.g. "rootmap.ditamap".
w2d.word2dita.xslt
Specifies the name of the XSLT transform to use to convert the DOCX file to DITA. Default is the
docx2dita.xsl transform in the word2dita Toolkit plugin.
w2d.debug.xslt
Turns on debugging of the XSLT transform. Default is "false".
Setting Up an Ant Script for Running the Word-to-DITA Transform
How to set up an Ant task to run the Word-to-DITA transform against DOCX files.
You can set up an Ant script to run the transform against a specific Word document. A typical script looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<project name="Single Word Doc to Map and Topics 01" 
default="transformMyDoc">
<property file="build.properties"/>
<property file="${user.home}/.build.properties"/>
<property file="${user.home}/build.properties"/>
<!-- This property should be set in one of the included files above
to reflect the location of Toolkit on your machine:
-->
<property name="dita-ot-dir" location="c:\DITA-OT1.5"/>
<dirname property="myAntFile.dir" file="${ant.file}"/>
<tstamp/>
<target name="transformMyDoc">
<property name="word.doc" 
location="${myAntFile.dir}/
word2dita_single_doc_to_map_and_topics_01.docx"/>
<basename  property="doc.base.name" file="${word.doc}" suffix=".docx"/>
<ant antfile="${dita-ot-dir}/build.xml" target="dita2word2dita">
<!-- Set this to the filename of the DOCX file to be transformed: -->
<property name="args.input" 
location="${word.doc}"/>
<!-- Change w2d.style-to-tag-map to point to your style-to-tag map 
document: -->
<property name="w2d.style-to-tag-map" 
location="${myAntFile.dir}/style2tagmap.xml"/>
<property name="w2d.root.output.filename" 
value="${doc.base.name}.ditamap"/>
<!-- Specify output.dir to set to the output directory to contain the 
DITA For Publishers | The DITA For Publishers Word to DITA and DITA to InDesign Tools | 36
generated DITA files: -->
<property name="output.dir" location="${myAntFile.dir}/../dita"/>
<property name="w2d.clean.output.dir" value="true"/><!-- Clean output 
directory before doing generation -->
<property name="w2d.debug.xslt" value="true"/><!-- Turn XSLT debug 
messages on -->
</ant>
<ant antfile="${dita-ot-dir}/build.xml" target="dita2xhtml">
<property name="args.input" 
location="${myAntFile.dir}/../dita/${doc.base.name}.ditamap"/>
</ant>
</target>  
</project>
The text in bold is what you would change to reflect your documents.
Note the initial 
<property>
elements that import a file named build.properties. This approach lets you put
this script anywhere and use the build.properties file to set the location of your Toolkit, defined in the Ant property
dita-ot-dir. (See Getting Started With The Word2DITA Transform on page 34 for more details on this one-time setup
task.)
If you name this file build.xml in an appropriate directory (e.g., the same directory as the Word document), you
can run this Ant script from the command line like so:
c:\workspace\myworddoc\> ant
You can also specify the Word document as a command-line parameter:
c:\workspace\myworddoc\ > ant -Dword.doc=c:/workspace/anotherworddoc/some-
document.docx
TODO: It should be possible to use Ant to convert a set of documents in one go but I haven't worked out the details
for that yet.
If you want to get really sophisticated you can extend your Ant script to run the Toolkit against the DITA files you
just generated, for example, to generate HTML as a way to validate the generated files. To do that you would add this
<ant>
element after the 
<ant>
element that runs the Word-to-DITA transform:
<ant antfile="${dita-ot-dir}/build.xml" target="dita2xhtml">
<property name="args.input" 
location="${myAntFile.dir}/../dita/${doc.base.name}.ditamap"/>
</ant>
You can, of course, add any other normal Toolkit arguments you might want to add.
Generating DITA From Within OxygenXML
You can transform Word documents from within OxygenXML without using the Open Toolkit
OxygenXML has two handy features that make transforming Word documents into DITA convenient, especially as
you are defining the style-to-tag mapping or implementing custom XSLT extensions:
• OxygenXML can open Zip archives in its Archive Browser. As DOCX files are just Zip archives, it means you
can open Word DOCX files in Oxygen and get to the individual files inside very easily.
• OxygenXML can run XSLT transforms and, in particular, can run them against files within Zip packages.
In addition, you can use Oxygen's built-in Open Toolkit to manage resolution of the XSD schema for style-to-tag
mapping documents simply by deploying the DITA for Publisher's Toolkit plugins to Oxygen's Toolkit instance (see 
Installing the Toolkit Plugins on page 11).
DITA For Publishers | The DITA For Publishers Word to DITA and DITA to InDesign Tools | 37
You can use Oxygen's normal Toolkit transformation scenario to run transforms against Word documents. Simply set
the transtype Ant parameter to "word2dita" and specify the Word document as the input file.
You can also transform Word documents directly in Oxygen, which is handy for testing and development of your
style-to-tag mapping.
To run the transform in Oxygen, do the following:
1. Open the DOCX file you want to transform in Oxygen's Archive Browser
2. Navigate to the file word/document.xml within Archive Browser and open it in the editor (double click on
the filename).
All Word documents have a file named document.xml, which contains all the paragraph content for the
document. This file is the input to actual Word-to-DITA transform.
3. Open the file net.sourceforge.dita4publishers.word2dita/xsl/docx2dita.xsl from the
Toolkit plugin, either as deployed to your Toolkit or from the DITA for Publishers distribution package (the
transform has no dependencies on any other Toolkit components so you can run it standalone).
4. From the docx2dita.xsl file, select the Configure Transformation Scenario button from the Toolbar and select
New to create a new transformation scenario.
5. For the XML file select the document.xml file you opened from the DOCX archive.
6. Select the Parameters button to open the Parameters dialog and set the following parameters:
outputDir
The URI of the output directory to hold the generated files.
styleMapUri
The URI of the style-to-tag map document to use for the transform.
7. Save the scenario and select Transform now to run the transform.
You should get some output. Use Oxygen's File->Open dialog to open the generated file (map or topic).
You can now rerun the transform at will and see the updated files in the editor.
Style to Tag Mapping
The docx2dita transform is driven by a configuration file, the style-to-tag map. The style-to-tag map enables an
entirely or almost-entirely configuration-driven transformation of styled Word documents into DITA-based XML,
specialized or not. Through careful design of Word templates it is possible to quickly configure the transformation to
produce good XML documents.
The style-to-tag map consists of a sequence of 
<style>
elements, where each style element defines the mapping for
a paragraph, character, list, or table style to the appropriate DITA XML structure. The mapping document may also
include an initial 
<documentation>
element that can hold documentation in any markup language (its content is
ignored and not validated), as well as 
<output>
elements that define the public and system IDs to use for any
generated map or topic documents.
The basic rules and constraints for the mapping are:
• The result document always consists of a single root topic or map. The first non-skipped and non-root-topic-
prolog paragraph in the Word document must be of structure type "topicTitle", "map", or "mapTitle" and level "0"
(zero).
• Paragraph styles that map to topic titles and contained elements (within topic bodies) must map to exactly one
fixed level. Thus, to have two levels of subsection topics, you must have two separate paragraph styles, one that
maps to level 1 and one that maps to level 2, even though both map to 
<subsection>
topic types.
• Character style mapping is flat within a paragraph: there is currently no general way to infer multiple levels of
inline markup from a flat sequence of character runs (this is more a limitation of Word's character styles than of
the mapping mechanism). In theory it would be possible to use marker characters or character styles or, more
reliably, embedded XML elements, to capture more complex inline structures.
• Each mapped style effectively says "I'm this type of structure, I go in this part of the topic, and (if necessary), I'm
contained by this containing element." That, plus other details as needed for specific types of target elements, is
sufficient to enable accurate creation of DITA XML from appropriately-styled Word documents.
DITA For Publishers | The DITA For Publishers Word to DITA and DITA to InDesign Tools | 38
• Common containment is determined by adjacency of similar container types and levels. For example, within a
topic body, each sequence of adjacent paragraphs with the same 
@containerType
and 
@level
value will be
grouped together within the same result element as determined by the 
@containerType
value.
Each style mapping has the following required attributes:
@styleName
The Word style name. This is the value in the 
@w:val
attribute of the 
<w:style>
/
<w:name>
element whose 
@w:styleId
value matches the style ID specified by a
given paragraph, text run, list item, or table. This is the display name of the style as
shown in the various style-related dialogs in Word. The style name is not case
sensitive, so "Heading 1" and "heading 1" identify the same style. Note that styles may
have associated aliases. Mapping to aliases is not supported as of version 0.9.16.
If you specify 
@styleName
you should not specify 
@styleId
. If you specify both
then 
@styleName
is used.
@styleId
The Word style ID. This is the value in the 
@w:val
attribute of the 
<w:*Style>
element associated with given paragraph, text run, list item, or table. Note that this
value is not the same as the display name of the style. For example, spaces and
underscores in style names are removed to form the style ID. In general, you can
construct the style ID for a given style by simply removing all spaces from the style's
display name.
If you specify 
@styleId
you should not specify 
@styleName
. If both are specified,
@styleName
is used.
@structureType
Indicates the type of target structure the Word construct represents. Possible values
are:
topicTitle
Paragraphs that start new topics and provide their titles. The style
mapping must also indicate the topic type, prolog type, body type, and
topic nesting level.
map
Paragraphs that start new maps. Normally used only to generate the
root map for the result.
mapTitle
Paragraphs that start new maps and provide their titles.
topicHead Paragraphs that generate new 
<topichead>
elements in the result
map and provide their titles.
topicGroup Paragraphs that generate new 
<topicgroup>
elements in the result
map. Note that topic groups never have titles.
section
Paragraphs that start new sections and, optionally, provide their titles.
The style mapping must specify the section tag name and how the
section title is determined (
@spectitle
).
dt
A paragraph that is the definition term part of a definition list entry.
dd
A paragraph that is the definition description part of a definition list
entry. Must immediately follow a "dt" structure type paragraph.
skip
The paragraph is completely ignored by the transform. Skipped
paragraphs are ignored for the purpose of determining adjacent
paragraphs when determining common containers. This means, for
example, that a sequence of paragraphs mapped to the same level 1
container, interrupted by a skipped paragraph, and followed by more
paragraphs in the same level 1 container will be in a single container
instance in the result.
xref
Represents a cross reference. Intended to map to 
<xref>
or a
specialization of 
<xref>
.
DITA For Publishers | The DITA For Publishers Word to DITA and DITA to InDesign Tools | 39
shortdesc
A paragraph that serves as the shortdesc for its containing topic.
@topicZone
Indicates which part of the target topic the result element belongs in. Possible values
are:
titleAlts
Provides one or more title alternatives
shortdesc Provides the short description for the topic.
prolog
Contributes to the topic prolog.
body
Contributes to the topic body as a block-level element.
inline
An inline element contained by some other generated element.
topicmeta An element that goes in the topicmeta container of a map or topicref
element.
@containingTopic
Indicates which topic should contain the element: "root" or "current". When
@containingTopic
is "root", the paragraph will be included in the root topic,
regardless of where it occurs within the input Word document. This is intended
primarily for prolog components.
@containerType
For components that imply a container, such as list items, specifies the tag name of the
containing element, e.g. "ul" for unordered list items. The container type value, along
with the 
@level
value, is used to group sequences of adjacent paragraphs together.
All adjacent paragraphs with the same 
@containerType
and 
@level
value will be
grouped together under a single instance of the specified container.
@tagName
Specifies the XML tag name for the result element generated directly from the Word
component.
@topicType
For structure type "topicTitle", specifies the topic element tag name.
@prologType
For structure type "topicTitle", specifies the prolog element tag name.
@bodyType
For structure type "topicTitle", specifies the body element tag name.
@level
Indicates the nesting level for a given topic or other containing structure. Styles within
the Word document are always specific to a given nesting level (otherwise there is no
reliable way to map a flat list of paragraphs into a hierarchy of XML elements). For
structure type "topicTitle", level "0" indicates the root topic for the result document.
Note that the level hierarchy for topic- and map-creating paragraphs is distinct from
the level hierarchy for paragraphs that contribute to topic bodies (topicZone="body").
For body paragraphs, the level is relative to the body itself. E.g., level="1" would be
for first-level list items, level="2" for second-level list items, and so on.
@spectitle
For section structure types, indicates how the section title is constructed. A section-
generating paragraph can also provide the section title text for use in a 
<title>
element or the section title can be provided by the paragraph following the section-
generating paragraph. The possible values for 
@spectitle
are:
#toColon
The paragraph is expected to have initial text terminated by a colon and
whitespace (": "). The section's 
@spectitle
attribute is set to the
value of the text up to but not including the colon. The text following
the colon and whitespace is used as the first paragraph of the section, if
any.
#toEmdash The paragraph is expected to have initial text terminated by an em dash
("—") and optional whitespace. The section's 
@spectitle
attribute is
set to the value of the text up to but not including the dash. The text
following the dash is used as the first paragraph of the section, if any.
DITA For Publishers | The DITA For Publishers Word to DITA and DITA to InDesign Tools | 40
Documents you may be interested
Documents you may be interested