- oXygen-user - www.oxygenxml.com

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

blank context pane
by Bob Stayton 20 Apr '15

20 Apr '15

I've been using Oxygen XML for years to debug XSL stylesheets. In the latest versions, the window pane for the context element has shown odd behavior. When I step through the debug process, the Context pane flashes the context element, and then clears immediately. If I'm quick, I can almost read it. Is there some autoclear function that I'm not aware of for that pane? The Variables and other panes are working fine. -- Bob Stayton Sagehill Enterprises bobs(a)sagehill.net

2 1

Use BaseX for XQuery Validation?
by Eliot Kimber 17 Apr '15

17 Apr '15

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

2 1

Overline style
by Joel 17 Apr '15

17 Apr '15

Hello, How do I apply an overline style in Oxygen? I have electronic symbols that need a line above the text. Thanks, Joel

2 1

[Ann] Oxygen XML Editor 17.0 beta - build 2015041612
by Oxygen XML Editor Support (Adrian Buza) 16 Apr '15

16 Apr '15

Dear oXygen users, We are happy to announce that version 17.0 of oXygen XML Editor is close to being released. We have decided to offer a new beta build (2015041612) prior to the final release to give you the opportunity to send us your feedback on the new features. Below, please see information about: * Downloading - oXygen 17.0 beta downloading links and notes * Licensing - a trial license key for testing * What's new - a summary of the most important new features in version 17.0 = Downloading = Windows 64-bit: http://www.oxygenxml.com/beta17/Windows64/oxygen-64bit.exe Windows 32-bit: http://www.oxygenxml.com/beta17/Windows/oxygen.exe OS X/Java SE 6: http://www.oxygenxml.com/beta17/MacOSX/oxygen.zip Linux 64-bit: http://www.oxygenxml.com/beta17/Linux64/oxygen-64bit.sh Linux/All Platforms: http://www.oxygenxml.com/beta17/All/oxygen.tar.gz Eclipse/ZIP: http://www.oxygenxml.com/beta17/Eclipse/com.oxygenxml.editor_17.0.0.v201504… Important Notes: - This build is meant for testing purposes only. Do not use it for production work. - You should install this beta version in a different directory than your current Oxygen installation. For Windows, we also recommend that you disable file associations during the installation to preserve your current Oxygen file associations with the various XML file types. - The OS X .zip distribution requires Java SE 6 from Apple, which is available here: http://support.apple.com/kb/DL1572 - For 32-bit Linux you have to use the "All Platforms" distribution and you also need to have installed either OpenJDK 7 (http://openjdk.java.net/install/) or Java SE 8 JRE/JDK from Oracle (http://www.oracle.com/technetwork/java/javase/downloads/index.html) - The "All Platforms" (.tar.gz) distribution includes launchers for Mac (Oxygen XML Editor.app or oxygenMac.sh), Linux (oxygen.sh), and Windows (oxygen.bat). - All feedback is welcome. = Licensing = If you already have a license key for Oxygen XML Editor with an active SMP, it will also work for this beta version. If you don't have one, a registration dialog box will open and you can use the following trial license key: ------START-LICENSE-KEY------ Registration_Name=oXygen XML v17 Beta Company= Category=Enterprise Component=XML-Editor, XSLT-Debugger, Saxon-SA Version=17 Number_of_Licenses=1 Date=03-30-2015 Trial=31 SGN=MCwCFADtFJ2DUmrsYwVq4sDUfqegwtpdAhRZLID8yK5+0R+UxlPRnLQ9fxCMFQ\=\= -------END-LICENSE-KEY------- = What's new in Oxygen XML Editor 17.0 = XML Quick Fixes: * Quick Fixes for Relax NG Errors * Schematron Quick Fixes XML Refactoring: * XML Refactoring Tool Visual XML Editing: * LESS Support in the Author Mode * Change the Tag Display Font * Actions to Insert Multiple Rows or Columns * The fileFilter Property is Available for URLChooser Form Control * Bold, Italic, and Underline Actions Support Multiple Selections Interface: * Customizable Toolbars * Color Themes * Improved HiDPI and Retina Support * Online Help Option DITA Support: * Search for Orphaned Resources Not Referenced in DITA Maps * Insert Image Reference Wizard * Validation Warning for References to Missing Topics and Images * Publish DITA Maps to Web Presentations * Auto-Detect Transformation Types and Parameters for Newly Installed DITA OT Plugins * CSS Improvements * DITA Map CSS Can Render Subject Scheme Map Elements * Support for DITA OT 2.0 * Check for Duplicate Topic IDs in a DITA Map WebHelp: * WebHelp Output Embeddable in iframe Element * WebHelp Context-Sensitive Help System * WebHelp System Supports LDAP Authentication * WebHelp System Supports Right-to-Left (RTL) Oriented Languages * Search Engine Optimization for WebHelp Output CSS: * CSS Inspector View * Support for Selecting/Combining Multiple CSS Styles in Author Mode * Support for editing LESS Stylesheets * Code Templates Included in the Content Completion List for Form Control Functions * New HTML Content Form Control * Define Actions for Button and Button Group Form Controls Directly in the CSS * Additional Properties Supported for the oxygen Media Type * The min-width and max-width Properties Supported for the CSS @media Rule * The font-family Property is Fully Supported * Support for position Property * Support for min-height Property * Support for letter-spacing Property * oxy_url Function with Editor Variables SVN Client: * Improvements to the Create Patch and Export Actions * Action to Display Additional Information About Versioned Items * Additional Improvements and Bug Fixes API: * Intercept List of Actions Provided by a Callout * Tree Component for Consistent Look and Feel * Customize Author Menu [Eclipse] * Customize Text/Author Contextual Menus [Eclipse] * Customize the Toolbars in the DITA Maps Manager [Eclipse] * Add Custom Browse Actions to Input Dialogs [Eclipse] * API for Customizing the Author Toolbar [Eclipse] * API for Providing Editor Adapters [Eclipse] * Plugin Extension to Specify Location of Custom Refactoring Operations * Styles Filter Extension Point [Eclipse] * ExtensionsBundle Extension Point [Eclipse] * Provide Text for a DITA Link [Eclipse] * Expand/Collapse Foldable Elements in Author Mode * Customize Drop-Down Buttons on a Toolbar [Eclipse] * Easier Way to Provide Documentation for Elements * Filter Errors Presented to the End User * Choose the Custom CSS to be Included in the Styles Drop-down List * Support for Composite Toolbars * API to Find Tracked Attribute Changes * Obtain a Reader Object of a URL Other: * Support for Configuring Proposals in the Content Completion Assistant * Ready for MarkLogic 8 * Automatic Escaping of Characters that Exceed the XML Encoding * Option to Lock Local Resources * Support for the JATS Document Type * Support for XLIFF 1.2 and 2.0 Documents * Compare Files Tool Includes Support for XML Fragment Comparison * Deprecated Support for Documentum CMS * Define Shortcut Keys for Code Templates Component Updates: * Apache HTTP Client 4.3.5 * Calabash 1.0.25 * eXist DB 2.2 * JSch 0.1.51 * Eclipse 4.5 Please let us know if you encounter any problems with this build. Again, all feedback is welcome. Best 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

1 0

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

16 Apr '15

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 On 4/15/2015 2:19 PM, T. Hatanaka wrote: > Sorin, > > That will be of great help! > When you have a test or experimental build in the future, let me know and I'll be happy to test it, though I'm no expert. > > In the meantime, I took a look at the result of the following Lucene/Kuromoji code with Japanese inputs. > > UserDictionary userDic = new UserDictionary( new FileReader( new File( "userdic.txt" ) ) ); > Analyzer analyzer = new JapaneseAnalyzer( userDic, JapaneseTokenizer.Mode.SEARCH, > JapaneseAnalyzer.getDefaultStopSet(), JapaneseAnalyzer.getDefaultStopTags() ); > > These default parameters work fairly well even without UserDictionary(). > However, the user dictionary at build-time would be a strong plus, considering that the current client-side JavaScript would miss critical keywords due to its little tweak for partial match. > So, in your future design time, please also consider making the UserDictionary() file path configurable via a WebHelp transformation parameter. > > > 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 00:17 > To: T. Hatanaka; oXygen-user(a)oxygenxml.com > Subject: Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp > > Hello, > > > On 4/12/2015 5:26 AM, T. Hatanaka wrote: >> That being said, it would still benefit a lot to integrate sophisticated analyzers, even if it's only at build-time. Run-time ones are less required, I guess. When the Japanese people search Web, they, human beings, usually perform a kind of tokenization and normalization by themselves. >> i.e. They do not usually enter "BROWNFOXJUMPS" in the search text box. In most cases we can expect them to type "BROWN FOX JUMP". >> Actually "Please enter keywords separated by spaces" has been a common instruction found on the Japanese search UI. People have got used to it. >> So I guess that if the index were created by a sophisticated analyzer at build-time with custom dictionaries, we could improve search experience a lot with relatively minor tweaks in run-time JavaScript. > > > Thank you for letting us know. In a future version we will integrate the > Kuromoji analyzer in our Apache Lucene customization that runs on the > generated WebHelp pages for building the WebHelp search index. This > index will offer relevant search result in the WebHelp pages only for > Japanese search terms entered in the browser that are properly separated > with space characters. > > >> Here's another piece of news: >> Kuromoji has been ported to JavaScript: https://github.com/takuyaa/kuromoji.js >> I haven't tried it, but expect some difficulties. I heard it required a 17MB dictionary. > > > That is too large for a client-side JavaScript operation. The > tokenization of the search string entered by the user may take forever > based on a 17 MB JavaScript dictionary. The search will rely on properly > separated search terms entered by the user, as you suggested above. > > >> Thanks, >> T. Hatanaka > > > Best regards, > 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 > > > _______________________________________________ > 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

2 1

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

15 Apr '15

Sorin, That will be of great help! When you have a test or experimental build in the future, let me know and I'll be happy to test it, though I'm no expert. In the meantime, I took a look at the result of the following Lucene/Kuromoji code with Japanese inputs. UserDictionary userDic = new UserDictionary( new FileReader( new File( "userdic.txt" ) ) ); Analyzer analyzer = new JapaneseAnalyzer( userDic, JapaneseTokenizer.Mode.SEARCH, JapaneseAnalyzer.getDefaultStopSet(), JapaneseAnalyzer.getDefaultStopTags() ); These default parameters work fairly well even without UserDictionary(). However, the user dictionary at build-time would be a strong plus, considering that the current client-side JavaScript would miss critical keywords due to its little tweak for partial match. So, in your future design time, please also consider making the UserDictionary() file path configurable via a WebHelp transformation parameter. 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 00:17 To: T. Hatanaka; oXygen-user(a)oxygenxml.com Subject: Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp Hello, On 4/12/2015 5:26 AM, T. Hatanaka wrote: > That being said, it would still benefit a lot to integrate sophisticated analyzers, even if it's only at build-time. Run-time ones are less required, I guess. When the Japanese people search Web, they, human beings, usually perform a kind of tokenization and normalization by themselves. > i.e. They do not usually enter "BROWNFOXJUMPS" in the search text box. In most cases we can expect them to type "BROWN FOX JUMP". > Actually "Please enter keywords separated by spaces" has been a common instruction found on the Japanese search UI. People have got used to it. > So I guess that if the index were created by a sophisticated analyzer at build-time with custom dictionaries, we could improve search experience a lot with relatively minor tweaks in run-time JavaScript. Thank you for letting us know. In a future version we will integrate the Kuromoji analyzer in our Apache Lucene customization that runs on the generated WebHelp pages for building the WebHelp search index. This index will offer relevant search result in the WebHelp pages only for Japanese search terms entered in the browser that are properly separated with space characters. > Here's another piece of news: > Kuromoji has been ported to JavaScript: https://github.com/takuyaa/kuromoji.js > I haven't tried it, but expect some difficulties. I heard it required a 17MB dictionary. That is too large for a client-side JavaScript operation. The tokenization of the search string entered by the user may take forever based on a 17 MB JavaScript dictionary. The search will rely on properly separated search terms entered by the user, as you suggested above. > Thanks, > T. Hatanaka Best regards, 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