Date   

Re: Class error compiling index for javahelp in DITA-OT 3.4 #DITA-OT #JavaHelp

Radu Coravu
 

Hi Jeff,

Unmodified versions of the DITA OT 3.4 are no longer shipped with the javahelp plugin.

Did you run this command to install it?

dita -install https://github.com/dita-ot/org.dita.javahelp/archive/2.5.zip
it seems that the JavaHelp plugin installed this way no longer has that JAR library I mentioned in my previous email.

Actually it seems I had previously added an issue for that:

https://github.com/dita-ot/org.dita.javahelp/issues/2

You probably need to find an older DITA OT distribution (one which had the JavaHelp plugin included along with that library and get the JavaHelp plugin directly from that).

Regards,

Radu

Radu Coravu
Oxygen XML Editor
On 3/14/20 11:25 PM, Jeff Hooker wrote:
Hi Radu,

I am indeed running it from the dita command (.bat rather than .sh, since I'm on a Windows box) against an unmodified version of 3.4.

Regards,
Jeff.

On Sat, Mar 14, 2020 at 8:04 AM Radu Coravu <radu_coravu@...> wrote:

Hi Jeff,

How exactly are you running the DITA OT?

If you are not running it using the DITA command:

https://www.dita-ot.org/dev/topics/build-using-dita-command.html

then you will probably need to add in the classpath of the Java process which starts ANT a reference to the JAR library "DITA-OT/plugins/org.dita.javahelp/lib/javahelp.jar".

Regards,
Radu
Radu Coravu
Oxygen XML Editor
On 3/13/20 11:00 PM, Jeff Hooker wrote:
Hi folks,

When I try to publish a sample project to Javahelp using 3.4 OT, I get this error message:

Error: The following error occurred while executing this line:
C:\Git\dita-ot-3.4\dita-ot-3.4\plugins\org.dita.javahelp\build_dita2javahelp.xml:181: java.lang.IllegalArgumentException: Index writer class not defined

The error comes back to the:

  <target name="dita.map.javahelp.index"
            description="Build JavaHelp Index file">
        <local name="javahelp.index.output.dir"/>
        <condition property="javahelp.index.output.dir" value="${dita.output.dir}" else="${_dita.map.output.dir}">
          <isset property="inner.transform"/>
        </condition>
        <pipeline message="Extract index term."
                  tempdir="${dita.temp.dir}"
                  inputmap="${user.input.file}">
          <module class="org.dita.dost.module.IndexTermExtractModule">
            <param name="output" location="${javahelp.index.output.dir}/${dita.map.filename.root}.xml"/>
            <param name="targetext" value=".html"/>
            <param name="indextype" value="javahelp"/>
            <param name="encoding" value="${args.dita.locale}" if="args.dita.locale"/>
          </module>
        </pipeline>
    </target>   


part of the build_dita2javahelp.xml file. If I delete everything between the target tags, then the javahelp builds, but obviously without an Index.

The eclipsehelp plugin uses the same module and it compiles and delivers an index, so the class is clearly present in the OT, but either it is not declared correctly in the javahelp plugin or some other detail is amiss. 

Anyone else seen this?

Thanks
Jeff.



  


Re: Class error compiling index for javahelp in DITA-OT 3.4 #DITA-OT #JavaHelp

Jeff Hooker
 

Hi Radu,

I am indeed running it from the dita command (.bat rather than .sh, since I'm on a Windows box) against an unmodified version of 3.4.

Regards,
Jeff.

On Sat, Mar 14, 2020 at 8:04 AM Radu Coravu <radu_coravu@...> wrote:

Hi Jeff,

How exactly are you running the DITA OT?

If you are not running it using the DITA command:

https://www.dita-ot.org/dev/topics/build-using-dita-command.html

then you will probably need to add in the classpath of the Java process which starts ANT a reference to the JAR library "DITA-OT/plugins/org.dita.javahelp/lib/javahelp.jar".

Regards,
Radu
Radu Coravu
Oxygen XML Editor
On 3/13/20 11:00 PM, Jeff Hooker wrote:
Hi folks,

When I try to publish a sample project to Javahelp using 3.4 OT, I get this error message:

Error: The following error occurred while executing this line:
C:\Git\dita-ot-3.4\dita-ot-3.4\plugins\org.dita.javahelp\build_dita2javahelp.xml:181: java.lang.IllegalArgumentException: Index writer class not defined

The error comes back to the:

  <target name="dita.map.javahelp.index"
            description="Build JavaHelp Index file">
        <local name="javahelp.index.output.dir"/>
        <condition property="javahelp.index.output.dir" value="${dita.output.dir}" else="${_dita.map.output.dir}">
          <isset property="inner.transform"/>
        </condition>
        <pipeline message="Extract index term."
                  tempdir="${dita.temp.dir}"
                  inputmap="${user.input.file}">
          <module class="org.dita.dost.module.IndexTermExtractModule">
            <param name="output" location="${javahelp.index.output.dir}/${dita.map.filename.root}.xml"/>
            <param name="targetext" value=".html"/>
            <param name="indextype" value="javahelp"/>
            <param name="encoding" value="${args.dita.locale}" if="args.dita.locale"/>
          </module>
        </pipeline>
    </target>   


part of the build_dita2javahelp.xml file. If I delete everything between the target tags, then the javahelp builds, but obviously without an Index.

The eclipsehelp plugin uses the same module and it compiles and delivers an index, so the class is clearly present in the OT, but either it is not declared correctly in the javahelp plugin or some other detail is amiss. 

Anyone else seen this?

Thanks
Jeff.


  


Re: Class error compiling index for javahelp in DITA-OT 3.4 #DITA-OT #JavaHelp

Radu Coravu
 

Hi Jeff,

How exactly are you running the DITA OT?

If you are not running it using the DITA command:

https://www.dita-ot.org/dev/topics/build-using-dita-command.html

then you will probably need to add in the classpath of the Java process which starts ANT a reference to the JAR library "DITA-OT/plugins/org.dita.javahelp/lib/javahelp.jar".

Regards,
Radu
Radu Coravu
Oxygen XML Editor
On 3/13/20 11:00 PM, Jeff Hooker wrote:

Hi folks,

When I try to publish a sample project to Javahelp using 3.4 OT, I get this error message:

Error: The following error occurred while executing this line:
C:\Git\dita-ot-3.4\dita-ot-3.4\plugins\org.dita.javahelp\build_dita2javahelp.xml:181: java.lang.IllegalArgumentException: Index writer class not defined

The error comes back to the:

  <target name="dita.map.javahelp.index"
            description="Build JavaHelp Index file">
        <local name="javahelp.index.output.dir"/>
        <condition property="javahelp.index.output.dir" value="${dita.output.dir}" else="${_dita.map.output.dir}">
          <isset property="inner.transform"/>
        </condition>
        <pipeline message="Extract index term."
                  tempdir="${dita.temp.dir}"
                  inputmap="${user.input.file}">
          <module class="org.dita.dost.module.IndexTermExtractModule">
            <param name="output" location="${javahelp.index.output.dir}/${dita.map.filename.root}.xml"/>
            <param name="targetext" value=".html"/>
            <param name="indextype" value="javahelp"/>
            <param name="encoding" value="${args.dita.locale}" if="args.dita.locale"/>
          </module>
        </pipeline>
    </target>   


part of the build_dita2javahelp.xml file. If I delete everything between the target tags, then the javahelp builds, but obviously without an Index.

The eclipsehelp plugin uses the same module and it compiles and delivers an index, so the class is clearly present in the OT, but either it is not declared correctly in the javahelp plugin or some other detail is amiss. 

Anyone else seen this?

Thanks
Jeff.


  


Chunking + Map-first preprocessing + branch filtering #branch-filtering #chunk

Nicholas Mucks
 

Hi,
We notice that ditamaps with a ditavalref element at the root of their map and chunks at some chapter maps end up with broken links in normalized output for those chapter maps. It looks like the chunking adds the root element ID at the end of the hashed filenames in the topicref’s href attribute and one of the preprocessing steps fails to resolve the hash reference back to the original file name.

Has anyone seen this? Also, does anyone know where that logic exists in the preprocess2 pipeline? Ideally we could override it to simply use the hashed filename without the appended ID value or override the chunk preprocessing not to add it at all.

Thanks!

Take care,
- Nick

Sent from mobile


Class error compiling index for javahelp in DITA-OT 3.4 #DITA-OT #JavaHelp

Jeff Hooker
 

Hi folks,

When I try to publish a sample project to Javahelp using 3.4 OT, I get this error message:

Error: The following error occurred while executing this line:
C:\Git\dita-ot-3.4\dita-ot-3.4\plugins\org.dita.javahelp\build_dita2javahelp.xml:181: java.lang.IllegalArgumentException: Index writer class not defined

The error comes back to the:

  <target name="dita.map.javahelp.index"
            description="Build JavaHelp Index file">
        <local name="javahelp.index.output.dir"/>
        <condition property="javahelp.index.output.dir" value="${dita.output.dir}" else="${_dita.map.output.dir}">
          <isset property="inner.transform"/>
        </condition>
        <pipeline message="Extract index term."
                  tempdir="${dita.temp.dir}"
                  inputmap="${user.input.file}">
          <module class="org.dita.dost.module.IndexTermExtractModule">
            <param name="output" location="${javahelp.index.output.dir}/${dita.map.filename.root}.xml"/>
            <param name="targetext" value=".html"/>
            <param name="indextype" value="javahelp"/>
            <param name="encoding" value="${args.dita.locale}" if="args.dita.locale"/>
          </module>
        </pipeline>
    </target>   


part of the build_dita2javahelp.xml file. If I delete everything between the target tags, then the javahelp builds, but obviously without an Index.

The eclipsehelp plugin uses the same module and it compiles and delivers an index, so the class is clearly present in the OT, but either it is not declared correctly in the javahelp plugin or some other detail is amiss. 

Anyone else seen this?

Thanks
Jeff.


examples of hazard-statements? #hazard-statements

jason@...
 

Hello . . . I work for a company that manufactures industrial equipment. The tech docs team that I'm a part of is starting to rewrite safety/warning messages in our documentation to be ANSI-compliant. While we're at it, we'd like to write these in such a way that they are DITA-ready (even though our conversion to DITA is still some time away...)

So, I wanted to ask if anyone on this list might be willing to share or point us to 1 or 2 examples of DITA-structured hazard statements?

Ideally, the examples would be equipment-related, and would show the DITA markup and the final output/formatting. But anything you might be able to share would be great, and much appreciated.

Many thanks in advance!

--
jason nichols


Re: OT processing for troubleshooting topic #DITA-OT #troubleshooting

 

Hi Bob, 

Can you show specifically how you suppressed the "Procedure" label?  I want to suppress both it and the "About this task" head.
Regards, 
Grant Hogarth


[ANN] Release of XMLmind Word To XML v1.8.1 #XMLmind

Hussein Shafie
 

Release of XMLmind Word To XML v1.8.1. Highlights:

- Thanks to XMLmind Web Help Compiler v3 (https://www.xmlmind.com/ditac/whc.shtml), the generated Web Help gets a fresh new look, among several other useful enhancements. For example, the Web Help is now “responsive” by default.

- Also some minor enhancements and bug fixes.

More information in https://www.xmlmind.com/w2x/changes.html

--------------------------------------
What is XMLmind Word To XML?
--------------------------------------

XMLmind Word To XML can automatically convert DOCX files to:

- Clean, styled, valid HTML (single page or multi-page HTML, Web Help, EPUB) looking very much like the source DOCX file.

- Unstyled, but structured and valid, DITA bookmap, map, topic, DocBook, XHTML (single page or multi-page HTML, Web Help, EPUB) or XML conforming to your custom schema.

Home Page: https://www.xmlmind.com/w2x/

Download: https://www.xmlmind.com/w2x/download.shtml

Free online DOCX conversion services: https://www.xmlmind.com/w2x/online_w2x.html


Re: Plain text output #text

Larry Kollar
 

I'm using the Levenshtein distance algorithm. I started with the C code from https://en.wikibooks.org/wiki/Algorithm_Implementation/Strings/Levenshtein_distance#C (second example) -- translating it to awk was pretty straightforward. If you prefer Python or Perl, you can use one of the pre-built libraries.

There's a recursive awk implementation at http://awk.freeshell.org/ja/LevenshteinEditDistance but I found it to be significantly slower.

Looping through an array of strings ends up requiring (b^2-b) comparisons if you throw out attempts to compare a block to itself. Then it occurred to me that if I delete each block that I've already compared to all the others, I don't get duplicate hits (i.e. comparing A to B, then B to A). That gives (b^2-b)/2 comparisons, which is pretty significant when you're talking about a smallish book containing 2400 block elements. Even with that optimization, 2400 block elements means nearly 2.9 million calls to the matching algorithm. I haven't had cause to utter the phrase "computationally expensive" in a looong time. :)

Next, I'm going to look at going to C... but past efforts suggest that it won't be that much faster.


Re: Plain text output #text

Mica Semrick
 

For the plain text you may also consider using tidy with a configuration to not wrap lines, then some simple XSLT to get rid of all the element tags. It may leave you with a decent amount of white space, but it should leave each element on it's own line.


On March 6, 2020 9:43:57 AM PST, lkollar@... wrote:
I got bored this week and cobbled up a reuse analyzer. It's about 100 lines of awk, and I found the fuzzy matching code on the web.

It turns out the more difficult part is getting plain text out of DITA, with each block element on one line, so the script can properly compare blocks. I tried Robert Anderson's Morse example (mentioned earlier this week), turning off the Morse code mapping part. I ended up with the entire topic on one line, often with missing spaces. That ain't working.

My current scheme is to export Markdown, then use `pandoc -t plain --wrap=none` to strip most of the markup. The awk script fixes the rest as it ingests the text files. This works OK, but is best for documents that have been given NO reuse treatment. As one might expect, the Markdown export resolves all existing keys and conrefs, and outputs them with the rest of the content. That means a bunch of false positives.

If the Markdown plugin allows customization, I could make a variant that just throws away the reused content for me. But maybe I'm missing a better way to do it.


Re: Plain text output #text

Chris Papademetrious
 

Hey cool, this has been something I've wanted to do too!

What fuzzy matching code are you using? I've been looking primarily at "longest common substring" algorithms.

 - Chris


Plain text output #text

Larry Kollar
 

I got bored this week and cobbled up a reuse analyzer. It's about 100 lines of awk, and I found the fuzzy matching code on the web.

It turns out the more difficult part is getting plain text out of DITA, with each block element on one line, so the script can properly compare blocks. I tried Robert Anderson's Morse example (mentioned earlier this week), turning off the Morse code mapping part. I ended up with the entire topic on one line, often with missing spaces. That ain't working.

My current scheme is to export Markdown, then use `pandoc -t plain --wrap=none` to strip most of the markup. The awk script fixes the rest as it ingests the text files. This works OK, but is best for documents that have been given NO reuse treatment. As one might expect, the Markdown export resolves all existing keys and conrefs, and outputs them with the rest of the content. That means a bunch of false positives.

If the Markdown plugin allows customization, I could make a variant that just throws away the reused content for me. But maybe I'm missing a better way to do it.


Re: Reuse - best practices #reuse

Matt Lorenzi
 

This is such good information. Thanks to everyone for offering their suggestions. 


Re: Consultants for updating PDF plug-ins #consulting #DITA-OT #PDF

 

I worked (somewhat indirectly) with Mark Novembrino for several years when I was at Brocade (Now Broadcom).
He was a superb resource and a very good person to work with.
He was instrumental in our transition from FrameMaker to DITA (XMetaL+SDL).
Grant Hogarth 
Technical Writer, Services Tools team
Workiva Inc. 
1700 Platte St, Suite 200, Denver, Colorado 80202 
Mobile: 1-801-815-8353 


On Thu, Mar 5, 2020 at 2:13 PM nmcdonagh via Groups.Io <nmcdonagh=yahoo.com@groups.io> wrote:
Elizabeth

I have worked with Mark Novembrino (Number 9 Solutions) he is also very good at TridionDocs (mnovembrion9@...)

We have also worked with a group in Ukraine that are very efficient and very reasonable, they are call Intelliarts, I can introduce if interested. 

Noel McDonagh


On Thursday, March 5, 2020, 12:33:07 PM EST, Elizabeth Gschwind <elizabethgschwind@...> wrote:


Wondering if there are any good consultants people could recommend to help us port our extensive customizations for PDF output - from DITA-OT version 1.5.2 to 2.5.4?  Email me if interested in getting more info and providing an estimate - thanks.


Re: Consultants for updating PDF plug-ins #consulting #DITA-OT #PDF

nmcdonagh
 

Elizabeth

I have worked with Mark Novembrino (Number 9 Solutions) he is also very good at TridionDocs (mnovembrion9@...)

We have also worked with a group in Ukraine that are very efficient and very reasonable, they are call Intelliarts, I can introduce if interested. 

Noel McDonagh


On Thursday, March 5, 2020, 12:33:07 PM EST, Elizabeth Gschwind <elizabethgschwind@...> wrote:


Wondering if there are any good consultants people could recommend to help us port our extensive customizations for PDF output - from DITA-OT version 1.5.2 to 2.5.4?  Email me if interested in getting more info and providing an estimate - thanks.


Consultants for updating PDF plug-ins #consulting #DITA-OT #PDF

Elizabeth Gschwind (FICO)
 

Wondering if there are any good consultants people could recommend to help us port our extensive customizations for PDF output - from DITA-OT version 1.5.2 to 2.5.4?  Email me if interested in getting more info and providing an estimate - thanks.


Re: Reuse - best practices #reuse

Ron Wheeler
 

You are on the right track.
keyrefs, topicrefs and their cousins make it easy to reposition the physical location of things without disturbing your main map.
If you define these in a separate file which you reference in your main map at the start, such as I have done

    <topicref href="description_variables.ditamap"
        format="ditamap" processing-role="resource-only" />

you will be able to restructure your physical locations and have all DITA projects that use the keys be automatically "fixed".
"resource-only" is the key that keeps your map of keys from being included as content.
The name "description_variables.ditamap" is arbitrary and only gets its name from the fact that the project is all about condo descriptions for our condo association.
(I needed to produce  master descriptions of all condos as well as a description of each condo as a separate document,  in 2 languages.)

Any other project that needs to reuse any of the content, simply has to include this reference and their project will find all of the files in their current locations regardless of any physical restructuring that has occurred.

Very helpful even where sharing is not contemplated. I restructured my files several times as I developed the DITA application and it was easy to reorganize things without having to go through all of the maps to re-specify links.

Ron


On 2020-03-03 1:16 p.m., Matt Lorenzi via Groups.Io wrote:
I think one of the biggest concerns I have is losing track of the original "home" of a topic. It isn't always known ahead of time which topics maybe become common to other models; it might not even be known at the time that other models are coming along. So I am sure in practice you simply do a topicref to the topic needed - wherever it may be. I sense this is where the power of keyrefs come in. I need more coffee to wrap my head around this.


Re: Reuse - best practices #reuse

Elizabeth Gschwind (FICO)
 

I agree Patricia. We put our shared content in folders labelled “Common” in our CMS, and also add the word “COMMON” to the file names so those objects are easy to identify.

 

This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.


Re: Reuse - best practices #reuse

Patricia Billard
 

Hi Matt, A topicref to a topic "wherever that may be" is not great specifically because you do lose track of what topics are reused in some other map, and you don't always end up with one "golden topic" source.  A best practice is to always put reused/reusable content in a specific place in your CMS structure.  For example, a folder called "Common Content" or "Shared Content" or something like that.  For the situation in which you start out with something you don't think would be shared, and now someone wants to reuse it, you'd need a business process to move that topic in to a Common Content folder at that time.


Re: Inserting Content Before a ToC #PDF #DITA-OT

Wanda Phillips
 

Excellent, thank you. I'm not as familiar with the bookmap, but I will certainly become familiar. I can see it in my future.