Incorrect character offset when launching from command-line

[earlhood-eps]

I am trying to invoke Oxygen editor from the command-line to a specific character offset in the file. For example:

Code: Select all

oxygen.bat file:/C:/path/to/file.xml#char=3367

The problem is oxygen does not position the cursor at the correct location. Based on my observation, it appears that oxygen ignores EOL characters in determining the character offset to place the cursor at. This behavior is inconsistent when I use text editors like VIm, Notepad++, and Emacs, where these editors will open the file to correct offset position.
Oxygen's behavior is problematic as I am working on a tool that processes XML data, where reports contain character offset into the data, with the offset obtained directly from the XML parsing engine or a raw text parsing engine. Since it appears Oxygen does not compute offsets correctly, or in a manner that is inconsistent in basic file I/O behavior, I have no reliable way to auto-launch Oxygen to the correct location in the file.
I am using Oxygen Editor 24.1.
Any help or guidance provided will be appreciated.

[Radu]

Hi,

From what I tested Oxygen does take line separators into account to some degree.
Some files especially on Windows contain as line separator two characters (carriage-return CR and line-feed LF). On Linux or Mac saved files contain only the line-feed (\n) character.
When files are opened in Oxygen, Oxygen will only keep the LF "line-feed" character and disregard the CR (carriage return). When files are saved from Oxygen depending on line separator settings in the Oxygen Preferences->"Global", Oxygen will save the file using Linux-style line separators (LF) or Windows style line separators (CR LF).
So if your XML files have both Windows style CR and LF as line separators and the offset was computed to take the CR into account, as when Oxygen loads the XML file it disregards the CRs which would mean that it will not count them as characters when the offset where to place the caret is computed.
If you go in the Oxygen Preferences->"Global" page, uncheck the "Detect the line separator on open" checbox and choose to use Linux style separators, then open the XML document, make a small change to it and save, Oxygen should save it using only LF characters for line separators. Once the XML file has only LF characters for line separators, the character offset (reported probably by another application) and then position where Oxygen places the caret should synchronize.

Regards,
Radu

[earlhood-eps]

Thanks for the response an explanation. I have confirmed that Windows EOLs (\r\n) trigger the offset problem, while Unix EOLs (\n) do not. IMO, this is bad behavior as Oxygen behaves like no other tool with regard to offset. It is completely impractical to require Windows users of the tool I am working on to use Unix EOLs (just linefeed) for all there XML documents, especially when such documents could be manipulated by different XML editors.

I think I will submit a bug report.

[Radu]

Hi Earl,

I agree this is a bug in Oxygen. We got your bug report and I added an internal issue for it:
EXM-50621 Open document from command line at certain offset problems with CR and LF line separators

About this note in your email:

Note, the offsets reported by the tool come directly from the XML parser (XercesJ in this case).

From my experience working with the Xerces parser, its reported error messages are line:column based, and most parsers report errors the same way with line/column information. Oxygen's command line allows opening a file at a specific line and column:

Code: Select all

oxygen.bat  file:samples/personal.xml#line=4column=5

and in this case the fact that right now we ignore \r's does not matter and the localization should be correct.

Regards,
Radu

[earlhood-eps]

At the Java API layer, you can get character offset along with line and column number. I focused on character offset for testing purposes as other tools we have that process data may only report character offset only. I used XercesJ as a control for testing purposes on how editors behave when launching based on an offset parameter, and to compare how one XML parser computes offsets to how Oxygen interprets them.

As an aside, I greatly appreciate that Oxygen supports the ability at the command-line to open a file to a specific location. It is only recently where I may only have character offset available (no element path and no line:column), hence the genesis of this thread. In most cases, I can get the element index path to pass to Oxygen on open, and as fallback, line:column, where Oxygen works great. It is only when using 'char' offset as the location via oxygen.bat I discovered the problem discussed in this thread.

[Radu]

Hi Earl,

Right. The internal issue I added for not skipping CRs is not that easy to fix, all our XML-related actions which act on the edited XML document assume there are no longer any Windows style CRs in the content, so I cannot give you a definite estimate on if or when it will be fixed.
As you said you have the workarounds with line:column and xpath location and you should use those instead.

Regards,
Radu