April 2015 - oXygen-user - www.oxygenxml.com

Multi-row tabs?
by Jostein Austvik Jacobsen 02 Oct '17

02 Oct '17

I often have a lot of XML-files open simultaneously. Is it possible to configure multiple rows of tabs? Something similar to this: http://winaero.com/blog/wp-content/uploads/2013/10/Firefox-with-multi-row-t… Jostein

5 9

Re: [oXygen-user] Pretty Print <lb/> in Oxygen
by Syd Bauman 12 Jan '16

12 Jan '16

A few hours ago Ute Recker-Hamm posted a wonderful question to TEI-L, the main list for the Text Encoding Initiative.[1] She basically asked "what do y'all do to get your physical lines, as encoded with the empty TEI <lb> element, to line up nicely in oXygen?". I remember asking a similar question a few years ago, and vaguely recall being told that manipulating the options under "Preferences > Editor / Format / XML" (in particular the "Preserve space" and "Default space" lists) should get format-and-indent to do the trick. However, I recall that I never got it working to my satisfaction, and when I look through the archives of this list now, I can't find the answer I recall. So what is "it" that I want format-and-indent to do? When given a text that looks like this: view A ---- - I call our world Flatland, not because we call it so, but to make <lb/>its nature clearer to you, my happy readers, who are privileged to live <lb/>in Space. Imagine a vast sheet of paper on which straight Lines, Triangles, <lb/>Squares, Pentagons, Hexagons, and other figures, instead of remaining <lb/>fixed in their places, move freely about, on or in the surface, but without <lb/>the power of rising above or sinking below it, very much like shadows <lb/>—only hard with luminous edges—and you will then have a pretty <lb/>correct notion of my country and countrymen. Alas, a few years ago, <lb/>I should have said “my universe:” but now my mind has been opened <lb/>to higher views of things. I'd like it to end up formatted as it is now -- with each <lb> starting a new line. If the desired line length were long enough, it wouldn't be changed at all. If the desired line length were shorter, it might look like this: view B ---- - I call our world Flatland, not because we call it so, but to make <lb/>its nature clearer to you, my happy readers, who are privileged to live <lb/>in Space. Imagine a vast sheet of paper on which straight Lines, Triangles, <lb/>Squares, Pentagons, Hexagons, and other figures, instead of remaining <lb/>fixed in their places, move freely about, on or in the surface, but without <lb/>the power of rising above or sinking below it, very much like shadows <lb/>—only hard with luminous edges—and you will then have a pretty <lb/>correct notion of my country and countrymen. Alas, a few years ago, <lb/>I should have said “my universe:” but now my mind has been opened <lb/>to higher views of things. What I *don't* want is for format-and-indent to make it look like this: view C ---- - I call our world Flatland, not because we call it so, but to make <lb/>its nature clearer to you, my happy readers, who are privileged to live <lb/>in Space. Imagine a vast sheet of paper on which straight Lines, Triangles, <lb/>Squares, Pentagons, Hexagons, and other figures, instead of remaining <lb/>fixed in their places, move freely about, on or in the surface, but without <lb/>the power of rising above or sinking below it, very much like shadows <lb/>—only hard with luminous edges—and you will then have a pretty <lb/>correct notion of my country and countrymen. Alas, a few years ago, <lb/>I should have said “my universe:” but now my mind has been opened <lb/>to higher views of things. In fact, if I had my druthers, an input document that looked like view C would come out of the processing looking like view A or B. Note ---- [1] Those of you who are members of a TEI list at Brown can find it at https://listserv.brown.edu/?A2=ind1410&L=tei-l&F=&S=&P=64155. I have not re-produced it here because I did not get the original poster's permission to do so. (Not that I think it is illegal or immoral to re-post without such permission, only that it's rude.)

7 9

Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp
by T. Hatanaka 08 May '15

08 May '15

Thanks for the quick turnaround. As a related but side note, I'm thinking to add to WebHelp a simple fuzzy query matching/scoring based on the Levenshtein distance ratio between the query and the index. Have you considered it in the past? I thought you might have considered it, as it would benefit not only Far Eastern cultures but probably also Western cultures. (albeit some Western's have the stemmer in WebHelp) Thanks, T. Hatanaka -----Original Message----- From: oxygen-user-bounces(a)oxygenxml.com [mailto:oxygen-user-bounces@oxygenxml.com] On Behalf Of Support Oxygen XML Editor (Sorin Ristache) Sent: Thursday, April 30, 2015 10:50 PM To: T. Hatanaka; oXygen-user(a)oxygenxml.com Subject: Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp Hi, Right, good catch! I just fixed it, the search box will allow in Oxygen 17.0 also search words of length shorter than three characters if the language of the content is Japanese. Best regards, Sorin <oXygen/> XML Editor http://www.oxygenxml.com On 4/30/2015 4:13 PM, T. Hatanaka wrote: > Sorin, > > I tried it out and found the indexed terms improved as expected. > Also confirmed that the user dictionary was loaded, which prevented the critical words from being missed. > > A simple but rather critical issue in the user experience at this moment: > nwSearchFnt.js expects 3 or more characters, while the Japanese words usually consist of 2 or more characters. > As a quick fix for testing purposes, I reduced the following threshold to 1 when indexerLanguage=='ja'. > >> if (finalArray[x].length > 2 || useCJKTokenizing){ > >> if (word.length > 2) { > > > There are a few other minor things that could be improved; I'll report them in due course. > The experience as a whole is very promising. Thank you so much! > > > Thanks, > T. Hatanaka > > -----Original Message----- > From: oxygen-user-bounces(a)oxygenxml.com [mailto:oxygen-user-bounces@oxygenxml.com] On Behalf Of Support Oxygen XML Editor (Sorin Ristache) > Sent: Thursday, April 30, 2015 3:15 PM > To: T. Hatanaka; oXygen-user(a)oxygenxml.com > Subject: Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp > > Hi, > > Please test the search in WebHelp pages Japanese content with the > following Oxygen 17.0 beta build: > > http://www.oxygenxml.com/userFiles/oxygen-AllPlatforms-17.0-beta-build-2015… > > You have to set the Japanese language in your DITA map (by adding the > xml:lang="ja-jp" parameter) or in the args.default.language parameter > and also follow the instructions at the end of the listing with DITA > transformation output messages for adding the Kuromoji analyzer runtime > file. After you add the runtime file the DITA transformation will detect > it and call it to index the Japanese content. > > The search terms should be separated by spaces as in European languages > but I think you already know that better than us because you are the one > who suggested we can assume that for a Japanese search string entered in > a web page. > > A Japanese user dictionary for the Kuromoji analyzer is optional and can > be set in the webhelp.search.japanese.dictionary parameter. > > > Best regards, > Sorin > > <oXygen/> XML Editor > > http://www.oxygenxml.com > > > On 4/30/2015 8:47 AM, T. Hatanaka wrote: >> Super! >> It'll be a great bonus to 17.0 whose beta itself is already amazing. >> I'll definitely test it out as soon as released. >> If I can help in any way at this moment, please let me know. >> >> Thanks, >> T. Hatanaka >> >> -----Original Message----- >> From: oxygen-user-bounces(a)oxygenxml.com [mailto:oxygen-user-bounces@oxygenxml.com] On Behalf Of Sorin Ristache >> Sent: Tuesday, April 28, 2015 11:16 PM >> To: T. Hatanaka; oXygen-user(a)oxygenxml.com >> Subject: Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp >> >> Hi, >> >> We implemented indexing of Japanese content in the WebHelp pages with >> the Kuromoji analyzer. It will go in the upcoming Oxygen 17.0 release. >> The Kuromoji analyzer will not be included in the Oxygen install kit, >> but a detailed INFO message in the DITA transformation console view will >> tell you where you can download the analyzer runtime file and where you >> have to copy it in the Oxygen install directory in order to enable >> indexing of Japanese content. >> >> Also a new parameter was added in the transformation for setting a user >> dictionary to the Kuromoji analyzer. It is an optional parameter, so the >> search results should be greatly improved on Japanese content even >> without setting a user dictionary. >> >> >> Regards, >> Sorin >> >> <oXygen/> XML Editor >> >> http://www.oxygenxml.com >> >> >> On 4/17/2015 2:34 PM, T. Hatanaka wrote: >>> Thank you for hearing. >>> Analyzer + user dic will be a huge plus in the relevant cultural area like us. _______________________________________________ oXygen-user mailing list oXygen-user(a)oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user

2 1

Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp
by T. Hatanaka 30 Apr '15

30 Apr '15

Sorin, I tried it out and found the indexed terms improved as expected. Also confirmed that the user dictionary was loaded, which prevented the critical words from being missed. A simple but rather critical issue in the user experience at this moment: nwSearchFnt.js expects 3 or more characters, while the Japanese words usually consist of 2 or more characters. As a quick fix for testing purposes, I reduced the following threshold to 1 when indexerLanguage=='ja'. > if (finalArray[x].length > 2 || useCJKTokenizing){ > if (word.length > 2) { There are a few other minor things that could be improved; I'll report them in due course. The experience as a whole is very promising. Thank you so much! Thanks, T. Hatanaka -----Original Message----- From: oxygen-user-bounces(a)oxygenxml.com [mailto:oxygen-user-bounces@oxygenxml.com] On Behalf Of Support Oxygen XML Editor (Sorin Ristache) Sent: Thursday, April 30, 2015 3:15 PM To: T. Hatanaka; oXygen-user(a)oxygenxml.com Subject: Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp Hi, Please test the search in WebHelp pages Japanese content with the following Oxygen 17.0 beta build: http://www.oxygenxml.com/userFiles/oxygen-AllPlatforms-17.0-beta-build-2015… You have to set the Japanese language in your DITA map (by adding the xml:lang="ja-jp" parameter) or in the args.default.language parameter and also follow the instructions at the end of the listing with DITA transformation output messages for adding the Kuromoji analyzer runtime file. After you add the runtime file the DITA transformation will detect it and call it to index the Japanese content. The search terms should be separated by spaces as in European languages but I think you already know that better than us because you are the one who suggested we can assume that for a Japanese search string entered in a web page. A Japanese user dictionary for the Kuromoji analyzer is optional and can be set in the webhelp.search.japanese.dictionary parameter. Best regards, Sorin <oXygen/> XML Editor http://www.oxygenxml.com On 4/30/2015 8:47 AM, T. Hatanaka wrote: > Super! > It'll be a great bonus to 17.0 whose beta itself is already amazing. > I'll definitely test it out as soon as released. > If I can help in any way at this moment, please let me know. > > Thanks, > T. Hatanaka > > -----Original Message----- > From: oxygen-user-bounces(a)oxygenxml.com [mailto:oxygen-user-bounces@oxygenxml.com] On Behalf Of Sorin Ristache > Sent: Tuesday, April 28, 2015 11:16 PM > To: T. Hatanaka; oXygen-user(a)oxygenxml.com > Subject: Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp > > Hi, > > We implemented indexing of Japanese content in the WebHelp pages with > the Kuromoji analyzer. It will go in the upcoming Oxygen 17.0 release. > The Kuromoji analyzer will not be included in the Oxygen install kit, > but a detailed INFO message in the DITA transformation console view will > tell you where you can download the analyzer runtime file and where you > have to copy it in the Oxygen install directory in order to enable > indexing of Japanese content. > > Also a new parameter was added in the transformation for setting a user > dictionary to the Kuromoji analyzer. It is an optional parameter, so the > search results should be greatly improved on Japanese content even > without setting a user dictionary. > > > Regards, > Sorin > > <oXygen/> XML Editor > > http://www.oxygenxml.com > > > On 4/17/2015 2:34 PM, T. Hatanaka wrote: >> Thank you for hearing. >> Analyzer + user dic will be a huge plus in the relevant cultural area like us. _______________________________________________ oXygen-user mailing list oXygen-user(a)oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user

2 1

updated framework not used in conversion
by Lou Burnard 30 Apr '15

30 Apr '15

I'm puzzled... I have installed all the recent updates to the TEI framework from the TEI site, and my local .com.oxygen.xml directory contains an updated version of one of the XSLT scripts provided as a result: -rw-rw-r-- 1 lou lou 13520 Apr 29 12:02 ./.com.oxygenxml/extensions/v16.1/frameworks/http___www.tei_c.org_release_oxygen_updateSite.oxygen/tei/xml/tei/stylesheet/profiles/oulipo/from_common.xsl However, when I actually run the conversion from within oXygen, it does not use this version, but instead the one released ages ago, which is still in the installation directory: -rw-r--r-- 1 lou lou 9612 Jan 22 13:43 ./OxygenXMLEditor16/frameworks/tei/xml/tei/stylesheet/profiles/oulipo/from_common.xsl The Ant script I am running in my transformation says "Loading stylesheet /home/lou/OxygenXMLEditor16/frameworks/tei/xml/tei/stylesheet/profiles/oulipo/docx/from.xsl" It also uses the build-from.xml file from the same directory, rather than the one one in the .com.oxygml tree, which is however identical. But since it uses relative paths, maybe that is the problem? Any advice much appreciated...

2 3

Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp
by T. Hatanaka 30 Apr '15

30 Apr '15

Super! It'll be a great bonus to 17.0 whose beta itself is already amazing. I'll definitely test it out as soon as released. If I can help in any way at this moment, please let me know. Thanks, T. Hatanaka -----Original Message----- From: oxygen-user-bounces(a)oxygenxml.com [mailto:oxygen-user-bounces@oxygenxml.com] On Behalf Of Sorin Ristache Sent: Tuesday, April 28, 2015 11:16 PM To: T. Hatanaka; oXygen-user(a)oxygenxml.com Subject: Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp Hi, We implemented indexing of Japanese content in the WebHelp pages with the Kuromoji analyzer. It will go in the upcoming Oxygen 17.0 release. The Kuromoji analyzer will not be included in the Oxygen install kit, but a detailed INFO message in the DITA transformation console view will tell you where you can download the analyzer runtime file and where you have to copy it in the Oxygen install directory in order to enable indexing of Japanese content. Also a new parameter was added in the transformation for setting a user dictionary to the Kuromoji analyzer. It is an optional parameter, so the search results should be greatly improved on Japanese content even without setting a user dictionary. Regards, Sorin <oXygen/> XML Editor http://www.oxygenxml.com On 4/17/2015 2:34 PM, T. Hatanaka wrote: > Thank you for hearing. > Analyzer + user dic will be a huge plus in the relevant cultural area like us. _______________________________________________ oXygen-user mailing list oXygen-user(a)oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user

2 1

Oxygen 16.1 won't run with DITA OT 2.0.1
by Mark Giffin 29 Apr '15

29 Apr '15

I copied a standard DITA Map XHTML output scenario and pointed it at a copy of DITA OT 2.0.1. It fails with the following error. Similar error for PDF output. No other changes to the scenario. ---------------- BUILD FAILED C:\Users\Mark\dita-ots\DITA-OT2.0.1\build.xml:41: The following error occurred while executing this line: C:\Users\Mark\dita-ots\DITA-OT2.0.1\plugins\org.dita.base\build_preprocess.xml:78: Failed to run pipeline: URI has a query component ---------------- Does it not work this way? Full log below. Thanks, Mark ---------------------------- Executing: "c:\program files (x86)\oxygen xml editor 16\jre/bin/java" -Xmx384m "-Dorg.apache.xerces.xni.parser.XMLParserConfiguration=org.ditang.relaxng.defaults.RelaxDefaultsParserConfiguration" -classpath "C:\Program Files (x86)\Oxygen XML Editor 16\tools\ant/lib/ant-launcher.jar" "-Dant.home=C:\Program Files (x86)\Oxygen XML Editor 16\tools\ant" org.apache.tools.ant.launch.Launcher -lib "C:\Program Files (x86)\Oxygen XML Editor 16\classes" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\oxygen.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\oxygenAuthor.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\oxygenDeveloper.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\oxygenEclipse.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\oxygenAuthorEclipse.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\oxygenDeveloperEclipse.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\resolver.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\org.eclipse.wst.xml.xpath2.processor_1.2.0.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\xml-apis.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\xercesImpl.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\commons-io-1.3.1.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\commons-logging-1.1.3.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\log4j.jar" -lib "C:\Users\Mark\dita-ots\DITA-OT2.0.1\lib\commons-codec-1.4.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\jing.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\saxon9ee.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\saxon.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\xmlgraphics-commons-1.5.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\fop.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\batik-all-1.7.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\js.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\xml-apis-ext.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\avalon-framework-4.2.0.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\jeuclid-core.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\jeuclid-fop.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\jai_tiff.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\jh.jar" -lib "C:\Users\Mark\dita-ots\DITA-OT2.0.1\lib\jsearch.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\lucene-analyzers-common-4.0.0.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\lucene-core-4.0.0.jar" -lib "C:\Users\Mark\dita-ots\DITA-OT2.0.1\plugins\com.oxygenxml.webhelp\lib\xhtml-indexer.jar" -lib "C:\Users\Mark\dita-ots\DITA-OT2.0.1\plugins\com.oxygenxml.highlight\lib\xslthl-2.1.1.jar" -lib "C:\Users\Mark\dita-ots\DITA-OT2.0.1" -lib "C:\Users\Mark\dita-ots\DITA-OT2.0.1\lib\dost-patches.jar" -lib "C:\Users\Mark\dita-ots\DITA-OT2.0.1\lib" -lib "C:\Users\Mark\dita-ots\DITA-OT2.0.1\lib\dost.jar" -f "C:\Users\Mark\dita-ots\DITA-OT2.0.1/build.xml" "-Dtranstype=pdf2" "-Dbasedir=C:\Users\Mark\Desktop\Security Guide" "-Doutput.dir=C:\Users\Mark\Desktop\Security Guide/out/pdf" "-Ddita.temp.dir=C:\Users\Mark\Desktop\Security Guide/temp/pdf" "-Dpdf.formatter=fop" "-Dxep.failOnError=true" "-Ddita.dir=C:\Users\Mark\dita-ots\DITA-OT2.0.1" "-Dargs.input=C:\Users\Mark\Desktop\Security Guide\Security-Guide.ditamap" "-DbaseJVMArgLine=-Xmx384m" Buildfile: C:\Users\Mark\dita-ots\DITA-OT2.0.1\build.xml init: dita2pdf2.init: check-arg: [mkdir] Created dir: C:\Users\Mark\Desktop\Security Guide\temp\pdf log-arg: [echo] ***************************************************************** [echo] * basedir = C:\Users\Mark\Desktop\Security Guide [echo] * dita.dir = C:\Users\Mark\dita-ots\DITA-OT2.0.1 [echo] * transtype = pdf2 [echo] * tempdir = C:\Users\Mark\Desktop\Security Guide/temp/pdf [echo] * outputdir = C:\Users\Mark\Desktop\Security Guide/out/pdf [echo] * clean.temp = true [echo] * DITA-OT version = 2.0.1 [echo] * XML parser = Xerces [echo] * XSLT processor = Saxon [echo] * collator = ICU [echo] ***************************************************************** [echo] #Ant properties [echo] #Tue Apr 28 21:26:10 PDT 2015 [echo] args.grammar.cache=yes [echo] args.input=C\:\\Users\\Mark\\Desktop\\Security Guide\\Security-Guide.ditamap [echo] args.logdir=C\:\\Users\\Mark\\Desktop\\Security Guide/out/pdf [echo] args.rellinks=nofamily [echo] args.xml.systemid.set=yes [echo] dita.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1 [echo] dita.plugin.com.sophos.tocjs.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\com.sophos.tocjs [echo] dita.plugin.org.dita.base.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1 [echo] dita.plugin.org.dita.docbook.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.docbook [echo] dita.plugin.org.dita.eclipsecontent.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.eclipsecontent [echo] dita.plugin.org.dita.eclipsehelp.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.eclipsehelp [echo] dita.plugin.org.dita.htmlhelp.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.htmlhelp [echo] dita.plugin.org.dita.javahelp.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.javahelp [echo] dita.plugin.org.dita.odt.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.odt [echo] dita.plugin.org.dita.pdf2.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.pdf2 [echo] dita.plugin.org.dita.specialization.dita11.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.specialization.dita11 [echo] dita.plugin.org.dita.specialization.dita132.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.specialization.dita132 [echo] dita.plugin.org.dita.specialization.eclipsemap.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.specialization.eclipsemap [echo] dita.plugin.org.dita.troff.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.troff [echo] dita.plugin.org.dita.wordrtf.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.wordrtf [echo] dita.plugin.org.dita.xhtml.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.xhtml [echo] dita.plugin.org.oasis-open.dita.v1_2.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.oasis-open.dita.v1_2 [echo] dita.temp.dir=C\:\\Users\\Mark\\Desktop\\Security Guide/temp/pdf [echo] preprocess.copy-image.skip=true [echo] ***************************************************************** build-init: preprocess.init: [echo] ***************************************************************** [echo] * input = C:\Users\Mark\Desktop\Security Guide\Security-Guide.ditamap [echo] ***************************************************************** gen-list: [gen-list] Using Xerces grammar pool for DTD and schema caching. [gen-list] Processing file:/C:/Users/Mark/Desktop/Security%20Guide/Security-Guide.ditamap [gen-list] Processing file:/C:/Users/Mark/Desktop/Security%20Guide/SecurityOverview.ditamap [gen-list] Processing file:/C:/Users/Mark/Desktop/Security%20Guide/SecurityArchitecture.ditamap [gen-list] Processing file:/C:/Users/Mark/Desktop/Security%20Guide/TheglellloginUtility.ditamap [gen-list] Processing file:/C:/Users/Mark/Desktop/Security%20Guide/TicketsandCertificates.ditamap [gen-list] Processing file:/C:/Users/Mark/Desktop/Security%20Guide/ConfiguringglellSecurity.ditamap ... deleted ... [gen-list] Processing file:/C:/Users/Mark/Desktop/Security%20Guide/ConfiguringaglellClusterto_26281156-d3e460.dita [gen-list] Processing file:/C:/Users/Mark/Desktop/Security%20Guide/ConfiguringaglellClusterto_26281156-d3e497.dita [gen-list] Processing file:/C:/Users/Mark/Desktop/Security%20Guide/ConfiguringaglellClusterto_26281156-d3e550.dita [gen-list] Processing file:/C:/Users/Mark/Desktop/Security%20Guide/ConfiguringaglellClusterto_26281156-d3e560.dita BUILD FAILED C:\Users\Mark\dita-ots\DITA-OT2.0.1\build.xml:41: The following error occurred while executing this line: C:\Users\Mark\dita-ots\DITA-OT2.0.1\plugins\org.dita.base\build_preprocess.xml:78: Failed to run pipeline: URI has a query component Total time: 1 second The process finished with exit code: 1

2 1

Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp
by T. Hatanaka 28 Apr '15

28 Apr '15

Thank you for hearing. Analyzer + user dic will be a huge plus in the relevant cultural area like us. -----Original Message----- From: oxygen-user-bounces(a)oxygenxml.com [mailto:oxygen-user-bounces@oxygenxml.com] On Behalf Of Support Oxygen XML Editor (Sorin Ristache) Sent: Thursday, April 16, 2015 7:07 PM To: T. Hatanaka; oXygen-user(a)oxygenxml.com Subject: Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp Hi, I did some research on the user dictionaries and my understanding is that setting a user dictionary is a great enhancement for morphological Lucene analyzers like the ones for the CJK languages, for example the JapaneseAnalyzer, and also for indexing domain-specific content in any language. So we should add a new parameter to the WebHelp page generation process for setting a user dictionary which makes sense for any language of the page content. The user dictionary has a simple and direct use for a morphological analyzer like the JapaneseAnalyzer because it is just a parameter of the class constructor, but is a little more complicated to integrate into the sequence of Lucene filters that follows an initial Lucene tokenizer in the typical Lucene processing pipeline for non-CJK languages. Thank you for your suggestions, Sorin <oXygen/> XML Editor http://www.oxygenxml.com On 4/15/2015 6:13 PM, T. Hatanaka wrote: > Hi, > >> What would the custom Japanese user dictionary add to the build-time >> indexing process: >> >> - a list of domain-specific words > > It will be the most important. > >> - or some generic tweaks that would allow matching a client-side search > > Presumably it will be JavaScript's role just as its wordsStartsWith() (I guess) does currently. > >> the generic tweaks added by a custom user >> dictionary would not be needed anymore. Could you give a short example >> please? > > Suppose there is a Japanese sentence whose structure resembles "OVERPAYPALEBAYBERRY." > > Kuromoji or any analyzer may segment it as "over,paypal,ebay,berry", "overpay,pale,bayberry", "over,pay,pal,e,bay,berry" or so, depending on its built-in dictionary and method. There is no single authoritative answer. > > With one of such imperfect indexes, the user may search for 'over', 'overpay', 'paypal', 'pale', 'ale', 'ebay', 'bay', 'bayberry', 'verpaypalebaybe' or even 'e'... (The last two may look ridiculous, but such array of characters can be a self-contained atomic well-known word in the Japanese language.) > > Kuromoji is clever enough to return multiple terms such as "(paypal|pay,pal),(ebay|e,bay)", but that would never be perfect. Hence the user dictionary can play a critical role to let the analyzer know the novel word "verpaypalebaybe" or boost the priority of "ale". > > Thanks, > T. Hatanaka > ________________________________________ > From: oxygen-user-bounces(a)oxygenxml.com <oxygen-user-bounces(a)oxygenxml.com> on behalf of Support Oxygen XML Editor (Sorin Ristache) <support(a)oxygenxml.com> > Sent: Wednesday, April 15, 2015 21:14 > To: T. Hatanaka; oXygen-user(a)oxygenxml.com > Subject: Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp > > Hello, > > Thank you for telling us, we will try to integrate the Kuromoji > analyzer into the Apache Lucene system that indexes the WebHelp pages. > > What would the custom Japanese user dictionary add to the build-time > indexing process: > > - a list of domain-specific words that are relevant for the domain of > the current DITA map and that are missing in the generic dictionary that > comes with the Kuromoji analyzer, > > - or some generic tweaks that would allow matching a client-side search > term with a partial match in the index built based on the WebHelp pages? > > I thought Kuromoji was a morphological analyzer that builds the index so > that a client-side search term will be matched with an indexed term > picked up from a WebHelp page even though the indexed term is only a > partial match, which means the generic tweaks added by a custom user > dictionary would not be needed anymore. Could you give a short example > please? > > > Thank you, > Sorin > > <oXygen/> XML Editor > > http://www.oxygenxml.com _______________________________________________ oXygen-user mailing list oXygen-user(a)oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user

2 1

Re: [oXygen-user] Use BaseX for XQuery Validation?
by Lizzi, Vincent 22 Apr '15

22 Apr '15

I have been wanting better support for BaseX in oXygen too. Being able to run XQuery on BaseX from within oXygen (via XQJ) is very useful. The guided editing and validation in oXygen (for example for XSLT) is extremely useful. It would be great to have both together in oXygen. Currently I switch to the BaseX GUI to write XQuery for BaseX, but this is not always practical because the BaseX GUI works only with local databases. Thanks, Vincent -----Original Message----- Message: 4 Date: Fri, 17 Apr 2015 08:48:33 -0500 From: Eliot Kimber <ekimber(a)contrext.com> To: Oxygen User <oxygen-user(a)oxygenxml.com> Subject: [oXygen-user] Use BaseX for XQuery Validation? Message-ID: <D1567960.527D4%ekimber(a)contrext.com> Content-Type: text/plain; charset="UTF-8" I'm implementing BaseX-specific XQueries, which use BaseX's support for importing modules based on mapping module URIs to a specific installation folder. Thus the XQuery processing has to go through the BaseX server code that provides the module resolution. Is there a way to configure BaseX as an XQuery validator in this case? I set up a BaseX validator but it fails to validate my BaseX-specific XQuery module with a "fails static validation" error, which I assume is because it can't resolve the modules. Thanks, Eliot ????? Eliot Kimber, Owner Contrext, LLC http://contrext.com ------------------------------ Message: 5 Date: Fri, 17 Apr 2015 18:01:51 +0300 From: "Oxygen XML Editor Support (Adrian Buza)" <support(a)oxygenxml.com> To: oxygen-user(a)oxygenxml.com Subject: Re: [oXygen-user] Use BaseX for XQuery Validation? Message-ID: <5531205F.6080601(a)oxygenxml.com> Content-Type: text/plain; charset=utf-8; format=flowed Hello Eliot, While it's possible to use an XQJ implementation/connection (like BaseX) for XQuery validation in Oxygen, it's a simple pass/fail validation, with no real details about the errors or their location, so not very useful. Regards, Adrian Adrian Buza oXygen XML Editor and Author Support Tel: +1-650-352-1250 ext.2020 Fax: +40-251-461482 support(a)oxygenxml.com http://www.oxygenxml.com On 17.04.2015 16:48, Eliot Kimber wrote: > I'm implementing BaseX-specific XQueries, which use BaseX's support > for importing modules based on mapping module URIs to a specific > installation folder. Thus the XQuery processing has to go through the > BaseX server code that provides the module resolution. > > Is there a way to configure BaseX as an XQuery validator in this case? > > I set up a BaseX validator but it fails to validate my BaseX-specific > XQuery module with a "fails static validation" error, which I assume > is because it can't resolve the modules. > > Thanks, > > Eliot > ????? > Eliot Kimber, Owner > Contrext, LLC > http://contrext.com > > > > _______________________________________________ > oXygen-user mailing list > oXygen-user(a)oxygenxml.com > http://www.oxygenxml.com/mailman/listinfo/oxygen-user ------------------------------ _______________________________________________ oXygen-user mailing list oXygen-user(a)oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user End of oXygen-user Digest, Vol 54, Issue 11 *******************************************

2 1

document validation
by Roderik Dernison 21 Apr '15

21 Apr '15

Good morning, I've made an extension to the DITA-schema called ling and another extension called ling-sod. The first validates fine. But the second gives errors: Description: cos-nonambig: emphasis and emphasis (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles. However, when I click the error message I'm redirected to another element that doesn't seem to be related to the problem. How to solve this problem? Vriendelijke groet, Ing. Roderik Dernison Programmeur/ontwikkelaar INL * Schatkamer van de Nederlandse Taal Matthias de Vrieshof 2 * Kamer 106a * 2311 BZ Leiden Tel. +31 (0)71 527 2491 * www.inl.nl<http://www.inl.nl/> ________________________________ ---------------------------------------------------------- Aan dit bericht kunnen geen rechten worden ontleend. Het bericht is alleen bestemd voor de geadresseerde. Indien het bericht niet voor u is bestemd, verzoeken wij u dit aan ons te melden en het bericht te verwijderen. This message shall not constitute any obligations. This message is intended solely for the addressee. If you have received this message in error, please inform us and delete the message. ----------------------------------------------------------

2 1