- oXygen-user - www.oxygenxml.com

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

Generating IDs on DITA maps
by Mark Giffin 15 Apr '15

15 Apr '15

Is there a way to get Oxygen to generate an ID for a new DITA map? It already does this for topics. Also, is there a way to batch generate IDs for a whole group of XML files, like those in a DITA map? I see info on things like "Managing ID/IDREFS" in the help, but that seems to apply to something else. Thanks, Mark

2 3

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

14 Apr '15

Let me revive this old thread. Could you reconsider this? As already said, the Japanese text has no explicit word breakers. It's something like "THEQUICKBROWNFOXJUMPSOVERTHELAZYDOG." The current WebHelp implementation is tokenizing it into "TH" "HE" "EQ" "QU" "UI" "IC" "CK"... both at build-time and run-time. It works to some extent, but not quite comfortable. That's why analyzers such as Kuromoji are most welcome. And, to deliver fully capable search experience, WebHelp requires both build-time and run-time analyzers, as you pointed out. 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. 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. 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, November 19, 2013 6:09 PM To: Naoki Hirai Cc: oXygen-user(a)oxygenxml.com Subject: Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp Dear Naoki-san, The Webhelp content indexer is indeed based on the Lucene engine just like the Kuromoji morphological analyzer, so delegating the task of indexing any Japanese content at build time (when the Webhelp pages are created by the Oxygen Webhelp transformation) to the Kuromoji analyzer is doable. However the Webhelp search is performed at runtime on the client side, with JavaScript code running on the machine where the Webhelp search is executed in the browser, not on the server side, where the Webhelp pages are stored. The difficulty in integrating an analyzer that deals with a specific language sentence morphology like the Kuromoji analyzer comes from the lack of an equivalent JavaScript analyzer that is able to split the search string entered by the user into the morphological components recognized by the Lucene-based morphological analyzer that built the index database at build time. I did a Google search but I could not identify a client side JavaScript solution for a Japanese morphological analyzer. If you can suggest such a solution we would surely consider it as a future improvement for the Webhelp search. Kind regards, Sorin Naoki Hirai wrote: > Hi, > > > > I like Oxygen WebHelp very much and recommend it to Japanese users. The > WebHelp is sophisticated online manual solution, but one issue has still > remained for Japanese users. That is a Japanese search. For Japanese > it's difficult to extract words from sentences. Because the words are > not separated by spaces. Therefore, in general, a morphological analyzer > is used to extract the words from the sentences. Recently, an open > source Japanese morphological analyzer which is called "Kuromoji" has > become popular. The Apache Solr has introduced Kuromoji as the > morphological analyzer. > > > > So, my feature request is that Oxygen WebHelp plug-in will incorporate > Kuromoji as the morphological analyzer. And add a parameter which > selects a stemmer for generating a WebHelp output. I can help the > development and the evaluation. > > > > Please have a thought. > > > > Best regards, > > Naoki _______________________________________________ oXygen-user mailing list oXygen-user(a)oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user

2 1

[Ann] focheck - Validate XSL-FO and Antenna House extensions in oXygen or standalone
by Tony Graham 14 Apr '15

14 Apr '15

Antenna House is pleased to announce the availability of 'focheck' as an add-on oXygen framework for validating XSL-FO and Antenna House extensions. 'focheck' bundles a Relax NG schema and a Schematron grammar in an oXygen framework for detailed validation of XSL-FO within oXygen XML Editor. You can, of course, also use the 'focheck' Relax NG and Schematron outside of oXygen, either together or separately. The Relax NG handles structural validation and the Schematron handles the additional constraints that cannot be expressed in Relax NG. The Schematron parses property value expressions using an XSLT-based parser generated by the REx parser generator plus an XSLT library for reducing the parse tree to XSL-FO datatypes. 'focheck' is available on GitHub at https://github.com/AntennaHouse/focheck. If you want to go straight to installing it as an add-on, the Update Site URL to use is https://github.com/AntennaHouse/focheck/raw/master/add-on.xml 'focheck' is a work in progress. It does not (yet) handle every XSL-FO property or every requirement in the XSL-FO spec, nor does it evaluate either functions or relative lengths. Pull requests and new issues are welcome. I will also be talking about 'focheck' at XML London 2015 in June. [1] And, of course, thanks go to the folks at Oxygen XML Editor Support for helping with some of the issues encountered. 'focheck' is open source licensed under the Apache License, Version 2.0. Regards, Tony Graham. -- Senior Architect XML Division Antenna House, Inc. ---- Skerries, Ireland tgraham(a)antenna.co.jp [1] http://xmllondon.com/programme#Tony-Graham

2 2

"FO PDF" scenario
by scott ashmead 14 Apr '15

14 Apr '15

Hi, I'd like to generate a PDF from an .fo file. When I open the .fo file in Oxygen, I thought I would see a "FO PDF" transform scenario, but I don't see it. Is there a properties setting that controls this? Thank you,Scott

3 2

MarkLogic 8 denuding issues with Oxygen v16 and earlier
by Ross A 14 Apr '15

14 Apr '15

Hi Where can I obtain Oxygen XML Editor v17 beta? I'm using MarkLogic 8 with Oxygen v14 Enterprise and having debugging errors. I heard the Oxygen v17 address those issues with MarkLogic 8, but there is also v17 beta out there that I can use? Thx Sent from my iPhone

2 1

Oxygen does not recognize DITA <steps-informal>
by Mark Giffin 14 Apr '15

14 Apr '15

I get an error with this markup, which I think should be valid for DITA 1.2: <task id="d3e123"> <title>Words here</title> <taskbody> <steps-informal></steps-informal> </taskbody> </task> Here's the error: ------- E [Xerces] Unexpected element "steps-informal". The content of the parent element type must match "(prereq?,context?,(steps|steps-unordered)?,result?,example?,postreq?)". ------- Shouldn't Oxygen call this valid? Here's the spec for it: http://docs.oasis-open.org/dita/v1.2/os/spec/langref/steps-informal.html Thanks, Mark

2 1