bugGNU Octave - Bugs: bug #50422, doc browser: diamond sign and line...

 
 

bug #50422: doc browser: diamond sign and line breaks at random positions

Submitter:  Hartmut <hardy>
Submitted:  Tue 28 Feb 2017 09:41:23 PM UTC
   
 
Category:  Documentation Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Inaccurate Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 4.2.1 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 11 Mar 2017 12:30:30 AM UTC, comment #8: 

The cset works for me!  Since this was reported against 4.2.1 I grafted your cset back to stable as well.  Marking as fixed and closing report.

Rik <rik5>
Group administrator
Fri 10 Mar 2017 09:16:37 PM UTC, comment #7: 

Changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/abb9d0cfdf2f
should fix this issue. As mentioned in comment #6, it corrects the anchor position while displaying the text as html.

Torsten Lilge <ttl>
Group Member
Fri 10 Mar 2017 08:38:55 PM UTC, comment #6: 

It seems that the anchor position in octave.info, e.g. 295238 in


Ref: XREFisvarname295238


are calculated based assuming Latin1 coding (byte count) which is too large in the case of multi-byte characters. I am going to prepare a patch that corrects the text lengths while loading the text and before inserting the anchor-tag at the position given by the info index.

However, if my guess is correct, it would probably be better to fix the way the index of the info files is computed. Where is that done and was there a change recently?

Torsten Lilge <ttl>
Group Member
Fri 03 Mar 2017 10:55:12 PM UTC, comment #5: 

@Rik: This is in parse.cc the function parse_info_map and get_next_node. In the latter, the image tags are extracted from the text. These tags have obviously changed but updateing get_next_node alone does not fix the issue.

Torsten Lilge <ttl>
Group Member
Fri 03 Mar 2017 01:47:59 AM UTC, comment #4: 

@Torsten: Which C++ file is putting in the diamonds, or calculating the anchor position?

Rik <rik5>
Group administrator
Wed 01 Mar 2017 03:58:06 PM UTC, comment #3: 

I can also see this on Windows.

OS => any

Philip Nienhuis <philipnienhuis>
Group Member
Wed 01 Mar 2017 05:53:16 AM UTC, comment #2: 

The diamond and the line break is inserted at the anchor of the reference, which was found and displayed in the tab. When the reference is nearer to the end of the node, the erroneous shift of the anchor is larger than at the beginning. I guess something has changed calculating the position of the anchors of references within a node.

Torsten Lilge <ttl>
Group Member
Wed 01 Mar 2017 12:16:54 AM UTC, comment #1: 

Confirmed.  And it is clearly something about how the 'doc' command operates.  If I type 'doc help' and then use the hyperlinks within the displayed file to go to "Next Section", and then "Previous Section", then the text is displayed correctly.

Rik <rik5>
Group administrator
Tue 28 Feb 2017 09:41:23 PM UTC, original submission:  

This happens with Octave 4.2.1 (and also with 4.2.0) under Linux:

When I open the GUI documentation browser by a command like "doc help", it properly opens and displays the help string for the corresponding command, in this example for "help".

Somewhere in the first line of this help text there is a blue diamond sign displayed. Depending on the doc item, this diamond sign is at arbitrary funny positions, and it seems to always have an unnecessary line break in front of it. Some examples

  • "doc plot" looks quite alright, but has an unnecessary linebreak before the word "plot"
  • "doc help" has the diamond sign (and line break) between "hel" and "p"
  • "doc fftw" has the diamong sign (and line break) between "fftw (" and "planner"


I will attach some screenshots to show this.


Hartmut <hardy>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #39853:  doc plot.png added by hardy (16KiB - image/png)
file #39854:  doc help.png added by hardy (11KiB - image/png)
file #39855:  doc fftw.png added by hardy (23KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by hardy (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-03-11 rik5 Open/ClosedOpen Closed
    2017-03-11 rik5 StatusReady For Test Fixed
    2017-03-10 ttl StatusConfirmed Ready For Test
    2017-03-01 philipnienhuis Operating SystemGNU/Linux Any
    2017-03-01 rik5 StatusNone Confirmed
    2017-02-28 hardy Attached File- Added doc plot.png, #39853
        Attached File- Added doc help.png, #39854
        Attached File- Added doc fftw.png, #39855

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code