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

 
 

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

Submitted by:  Hartmut <hardy>
Submitted on:  Tue 28 Feb 2017 09:41:23 PM UTC  
 
Category: DocumentationSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Inaccurate Result
Status: FixedAssigned to: None
Originator Name: Open/Closed: Closed
Release: 4.2.1Operating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>
Project 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 <ttl>
Project 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

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 <ttl>
Project 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 <ttl>
Project 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>
Project Administrator
Wed 01 Mar 2017 03:58:06 PM UTC, comment #3:

I can also see this on Windows.

OS => any

Philip Nienhuis <philipnienhuis>
Project 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 <ttl>
Project 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>
Project 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 File(s):
   
   
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
  • -unavailable- added by ttl (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by hardy (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 11 Mar 2017 12:30:40 AM UTCrik5Open/ClosedOpen=>Closed
    Sat 11 Mar 2017 12:30:30 AM UTCrik5StatusReady For Test=>Fixed
    Fri 10 Mar 2017 09:16:37 PM UTCttlStatusConfirmed=>Ready For Test
    Wed 01 Mar 2017 03:58:06 PM UTCphilipnienhuisOperating SystemGNU/Linux=>Any
    Wed 01 Mar 2017 12:16:54 AM UTCrik5StatusNone=>Confirmed
    Tue 28 Feb 2017 09:41:23 PM UTChardyAttached 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.1-cleanup1