August 2012 - oXygen-user - www.oxygenxml.com

Edit modes preferences do not work for "Find in Files" results
by Yves Barbion 06 Aug '12

06 Aug '12

Hi group I'm using oXygen XML Editor 14. I have set my Edit modes preferences to open XML files in Author mode (Options > Preferences > Edit Modes > XML Editor: Author. This works when I open an XML file by double-clicking the topicref in a DITA map. However, I see that this does not work when I double-click an entry in the "Find in Files" pane. Can this be fixed? Thanks. -- Yves Barbion www.scripto.nu

3 2

SVG font question
by Timothy Reaves 06 Aug '12

06 Aug '12

Is there any way to determine what actual font file oXygen uses to render an SVG? It is a very different font that what is used by Firefox for example, and I'd like to know, if possible.

2 1

Using XML Catalogs to resolve location of CSS files
by Mark Baker 06 Aug '12

06 Aug '12

I guess this is an enhancement request, since I can't seem to get it to work. I want to be able to specify the location of a CSS stylesheet using a URL, and then have it resolved to a local copy using an XML catalog. If I actually make the stylesheet available at the specified URL, Oxygen will find and use it. But if it can't find it on the web, it won't load a local copy even though the URL is mapped to the local file system in the catalog. I'm using an existing catalog with system and URI rewriting rules that work fine for loading schemas, and I have verified that the paths are all correct, so I'm assuming the Oxygen does not currently support resolving a CSS URL via a catalog. This would be a very useful feature for me, at least. Any chance of it making it into future editions? Thanks, Mark -- Mark Baker Analecta Communications Inc. 613-614-5881 www.analecta.com

3 2

file name extension: .xml vs. .dita
by Yves Barbion 06 Aug '12

06 Aug '12

Hi group I see that oXygen 14 gives my DITA topics the .dita file name extension when I save a new topic, unless I explicitely add .xml to my file name. Is there a way to specify the "default" file name extension for DITA topics in the Preferences? Thanks. -- Yves Barbion www.scripto.nu

2 1

Behavior regarding conkeyref before keydef
by KAATMAN Matthew 02 Aug '12

02 Aug '12

Hey Everyone, This is a fairly explainable situation and not causing major problems but I'm curious if there is a way to get around it. Here's the scenario: 1. I have a map with a conkeyref in the mainbooktitle. Then in the front matter I define the keydef: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE bookmap PUBLIC "-//OASIS//DTD DITA BookMap//EN" "bookmap/dtd/bookmap.dtd"> <bookmap format="ditamap" id="bookmap_User_Manual_Previ_Color"> <booktitle> <mainbooktitle><ph conkeyref="productinfo/prodname"/></mainbooktitle> </booktitle> <frontmatter> <keydef format="dita" href="user/ProductVariables.xml" keys="productinfo" processing-role="resource-only" type="topic"/> When I first load this map in Oxygen it loads the map title before it reads the keydef which results in a warning: System ID: C:\dita\products\vitek2systems\EN\Vitek2Systems_User_Manual.ditamap Severity: warning Description: [Document]:Could not resolve the target for key reference "productinfo/prodname" Screenshot: http://i.imgur.com/bXnnE.png If I open the map and make any change (Hit space, hit backspace, hit save) it then reads the title correctly. Is there another place I can define my keydef to avoid this? Or any other workaround? Thanks! Matt AVIS : Ce courrier et ses pieces jointes sont destines a leur seul destinataire et peuvent contenir des informations confidentielles appartenant a bioMerieux. Si vous n'etes pas destinataire, vous etes informe que toute lecture, divulgation, ou reproduction de ce message et des pieces jointes est strictement interdite. Si vous avez recu ce message par erreur merci d'en prevenir l'expediteur et de le detruire, ainsi que ses pieces jointes. NOTICE: This message and attachments are intended only for the use of their addressee and may contain confidential information belonging to bioMerieux. If you are not the intended recipient, you are hereby notified that any reading, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this message in error, please notify the original sender immediately and delete this message, along with any attachments.

4 4

Re: [oXygen-user] Find/Replace in Files: unable to find pretty-printed word combinations
by Sorin Ristache 01 Aug '12

01 Aug '12

Hi, We added the support for spanning multiple lines with a regular expression in Find/Replace in Files in Oxygen 14.0. So if you use an older version of Oxygen the regular expression that contains (\s+) will find only the matches that span one line, that is it will not match the end-of-line character. You did not specify your Oxygen version but I think it is older than 14.0. I checked in Oxygen 13.2 and this feature was not present, it is a new feature of version 14.0. If you do not use version 14.0 please upgrade. Regards, Sorin Yves Barbion wrote: > Hi Sorin > > I have checked all the options in the Find/Replace in Files dialog box > and I have also included a screen shot in the attached ZIP file. > > Thank you in advance for your assistance. > > Yves Barbion > www.scripto.nu > > > > On 31-07-2012 12:47, Sorin Ristache wrote: >> Hi, >> >> Please check all the values in the Find/Replace in Files dialog box: >> scope should be "Current DITA map hierarchy", file filter should be >> *.dita (or *.xml), etc. If all values are correct in the dialog box >> please send a sample DITA topic file that should be found by the find >> action but is not found and also specify the search string that you used. >> >> >> Regards, >> Sorin >> >> >> Yves Barbion wrote: >>> Hi Sorin >>> >>> Thank you for your prompt reply, but I'm afraid we're not quite there >>> yet. When I search for "time(\s+)zone" (without the quotes), oXygen >>> does not find it. A similar example is this: >>> >>> <p status="changed">The body of the <keyword >>> >>> conref="_conref_library.xml#topic_qjt_sdx_1f/keyword_wms_s2x_1f"/> >>> consists of >>> the following zones:</p> >>> >>> When I search for "consists of(\s+)the following" or >>> "consists(\s+)of(\s+)the(\s+)following" with the Regular Expression >>> option selected, oXygen will only find the occurrences where there is >>> only a single space between the words. >>> >>> Any other ideas? >>> >>> Thanks. >>> >>> Yves

3 4

Bug Report: Oxygen thinks DocBook <reference> is DITA <reference>
by Barton Wright 01 Aug '12

01 Aug '12

Hello to Oxygen Support, with thanks for such an excellent product. There is a small bug in a reproducible corner case, where Oxygen gets confused by a DocBook 4 <reference> element used at the top level of a file, and tries to validate the file in the DITA context. I’m attaching a zip file containing example files. This was tested with Oxygen 14, but I’ve seen this behavior in previous releases. Steps to reproduce: 1. Create a new DocBook 4 file from the article template in Oxygen. 2. In the new file, replace “DOCTYPE article” with “DOCTYPE reference”, and change both instances of 4.5 to 4.4 (to match the standard we still use). 3. In the new file, replace the entire <article> contents with the contents of the <reference> example from the DocBook Definitive Guide at http://docbook.org/tdg/en/html/reference.html. 4. Add a <referenceinfo> element above the <title> element, containing one <corpauthor> element that contains any string. 5. A file as described above is in the attached zip file as def-guide-reference-example-1.xml. 6. This file validates as a DocBook file in Oxygen, as expected, as well as in XXE (XMLMind XML Editor) and with xmllint. But wait, there’s more: 7. Now create two more new DocBook 4.4 files as described above. Change to “DOCTYPE refentry” and replace the <article> contents with the two <refentry> elements from the first example. 8. Two files as described here are in the zip file as awk.xml and gnu-as.xml. 9. Now replace the <refentry> elements in the main file with XInclude references to the two <refentry> files. A file as described here is in the zip file as def-guide-reference-example-2.xml. 10. This second example validates fine in XXE and with xmllint, both of which can resolve XIncludes in DocBook 4 files. 11. As expected, this file fails to validate in Oxygen because Oxygen cannot natively resolve XIncludes in DocBook 4 files. (We are used to this fact of life, and wish it were otherwise.) But that’s not the problem. Notice the validation failure messages, which begin as follows: [cid:image001.png@01CD6E3C.66BF2B30] 12. Even if you edit this second example to add Oxygen’s xinclude.mod support, the file is still considered to be in the DITA context. 13. Further, copy a valid <refentry> element back into the file so that it has one <refentry> local to the file and two XIncluded <refentry> pages, and validation still fails with the message shown above. 14. Comment out the XIncludes, and Oxygen validation returns to the DocBook context. Conclusion: there is something about the combination of a <reference> top-level element and an <xi:include> element that makes Oxygen ignore the DOCTYPE declaration and instead treat the file as a DITA file. Note again that XXE and xmllint* have no problem with this combination. We grudgingly accept the fact that Oxygen does not support XIncludes in DocBook 4 files unless the xinclude.mod kludge is used. But Oxygen should never consider an otherwise valid DocBook-declared file as a DITA file, despite the use of the <reference> element in both standards. *Our xmllint validation command is: xmllint --xinclude --catalogs --timing --noout --noent –postvalid filename.xml You can ignore a message that SGML_CATALOG_FILES is not set, or just set that to =/etc/xml/catalog. (Tested on Cygwin 1.7 and Linux Mint 11.)

3 4