bugGNU Octave - Bugs: bug #44899, generate_html: emdash hack breaks...

 
 

bug #44899: generate_html: emdash hack breaks normal paragraphs

Submitter:  Colin Macdonald <cbm>
Submitted:  Wed 22 Apr 2015 12:45:49 PM UTC
   
 
Category:  Octave Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 30 Apr 2015 08:25:00 PM UTC, comment #19: 
Julien Bect <jbect>
Fri 24 Apr 2015 11:05:46 PM UTC, comment #18: 

Closing bug report as fixed.

Mike Miller <mtmiller>
Group Member
Fri 24 Apr 2015 08:54:48 PM UTC, comment #17: 

I have tested the modified html_help_text function with TexInfo 4.13, everything seems to work fine.

I still have to introduce a similar hack for TexInfo >= 5 (currently, we get no class="functionfile" attribute with TexInfo >= 5).

This bug report should be closed, or renamed to reflect this new problem.

Julien Bect <jbect>
Fri 24 Apr 2015 01:15:40 PM UTC, comment #16: 

I don't mind testing the patch with Texinfo 4.13, I just can't get to it until the weekend.

Mike Miller <mtmiller>
Group Member
Fri 24 Apr 2015 09:02:36 AM UTC, comment #15: 


> can you test and tell us if it fixes the problem for you ?


Yes it does, tested on TexInfo 5.  Not tested on TexInfo 4.

> Just out of curiosity: Since your document encoding is utf-8 anyway you could just write “—” in your documentation string, right?!


I suppose so.  I have tested that and it works (TexInfo does not translate it into &mdash; simply leaves the utf-8 char in place.)

Colin Macdonald <cbm>
Fri 24 Apr 2015 07:16:21 AM UTC, comment #14: 

I have pushed a changeset that should fix the "&mdash; bug" (as observed by Colin) and at the same time improve the HTML output for TexInfo < 5 (previously, <p> was inserted but no </p>).

@Colin: can you test and tell us if it fixes the problem for you ?

Julien Bect <jbect>
Thu 23 Apr 2015 03:56:07 PM UTC, comment #13: 

@Colin, just out of curiosity: Since your document encoding is utf-8 anyway you could just write “—” in your documentation string, right?!

Oliver Heimlich <oheim>
Thu 23 Apr 2015 09:10:09 AM UTC, comment #12: 

@Carnë: I agree this will be a choice to make if other makeinfo-related issues appear. But, as far as this one is concerned, I haven't seen any issue in the output generated by makeinfo 4.13 that make it necessary to keep this the hack. Perhaps the problem was in even older versions?

Julien Bect <jbect>
Thu 23 Apr 2015 09:04:41 AM UTC, comment #11: 

The easy way out is to simply check the makeinfo version and fail for 4.X. The most work way would be to check the installed version and make use of different hacks depending on the version installed.

Carnë Draug <carandraug>
Group Member
Thu 23 Apr 2015 06:34:22 AM UTC, comment #10: 

I have sent an email to the maintainers list.

Let's wait and see what comes out of it.

Julien Bect <jbect>
Thu 23 Apr 2015 06:25:13 AM UTC, comment #9: 

I have built TexInfo 4.13 and indeed I can see a list of items prefixed with "&mdash; Function File".

But I don't really see any problem with that. I mean, the output looks fine to me in Firefox, with or without the Octave-Forge CSS.

I initially considered using something like this:


## Hack for makeinfo < 5.0
text = regexprep (text, '^&mdash;\s*(Function.*)\s*<br>\s*$', '<dt>$1</dt>');


but then the problem would be to introduce <dl> </dl> markers around the whole block of declarations.

Unless someone is actually able to reproduce the "odd indentation" problem mentioned by Soren, I would suggest to remove the hack.

Julien Bect <jbect>
Thu 23 Apr 2015 01:31:14 AM UTC, comment #8: 

This looks like it does matter for Texinfo prior to version 5. With the hack commented out, the generated HTML contains an em-dash in front of every "Function File" line. The hack removes that from the HTML output. The em-dash is not in the HTML output made with Texinfo 5.2.

I can provide examples if you want, but I recommend downloading and building Texinfo 4.13 and keeping a copy around for comparison. You don't have to "make install" it, just point Octave to the build directory with something like


>> makeinfo_program ("~/src/texinfo-4.13/makeinfo/makeinfo");


Or just decide not to support Texinfo older than 5, may or may not be a good decision, not up to me :) Might want to take a poll of Forge package maintainers to see if that's a reasonable option.

Mike Miller <mtmiller>
Group Member
Wed 22 Apr 2015 09:59:52 PM UTC, comment #7: 


> By the way, Colin, are you actually using texi2html, or did you
> mean html_help_text ?


Whichever one makes html for octave-forge pages :)  I just grepped for it.

Then I tested:

[text_html, status] = _makeinfo_ (text, "html");

(And then saw that it did not add emdashes)

Colin Macdonald <cbm>
Wed 22 Apr 2015 07:17:28 PM UTC, comment #6: 

plot.m for instance has both @deftypefn and @deftypefnx.

I have tried


html_help_text ('plot', 'plot.html')


and the results looks fine to me.

Julien Bect <jbect>
Wed 22 Apr 2015 07:13:51 PM UTC, comment #5: 

Le 22/04/2015 21:03, Søren Hauberg a écrit :

> Den 22-04-2015 kl. 20:58 skrev Julien Bect:
>> Follow-up Comment #4, bug #44899 (project octave):
>>
>> I don't know exactly which makeinfo bug this hack is supposed to solve.
>>
>> My guess is that the bug has been fixed in recent makeinfo version (mine is
>> 5.2 and, as observed by Colin, the hack doesn't seem to be doing anything
>> useful for me).
>>
>> So, it seems that we have two options here:
>>
>> 1) remove the hack completely,
>>
>> 2) or try to target it more precisely to avoid side effects.
>>
>> The latter option makes sense only if we can figure out what it is exactly
>> that this hack was supposed to fix.
>>
>> Perhaps someone with an older version of makeinfo can try to figure that out ?
>> I'm also CC-ing Soren, who might remember something about this issue.
> If I recall correctly, the issue appears when you have both @deftypefn and @deftypefnx in the same help text; in this case the @detypefnx would be oddly indented in the HTML output. That's something to look out for.
>
> Søren

Julien Bect <jbect>
Wed 22 Apr 2015 06:58:30 PM UTC, comment #4: 

I don't know exactly which makeinfo bug this hack is supposed to solve.

My guess is that the bug has been fixed in recent makeinfo version (mine is 5.2 and, as observed by Colin, the hack doesn't seem to be doing anything useful for me).

So, it seems that we have two options here:

1) remove the hack completely,

2) or try to target it more precisely to avoid side effects.

The latter option makes sense only if we can figure out what it is exactly that this hack was supposed to fix.

Perhaps someone with an older version of makeinfo can try to figure that out ? I'm also CC-ing Soren, who might remember something about this issue.

I propose to wait a little bit and then go for option 1 if don't know how to implement option 2...

Julien Bect <jbect>
Wed 22 Apr 2015 06:47:53 PM UTC, comment #3: 

By the way, Colin, are you actually using texi2html, or did you mean html_help_text ?

Julien Bect <jbect>
Wed 22 Apr 2015 06:46:35 PM UTC, comment #2: 
Julien Bect <jbect>
Wed 22 Apr 2015 05:39:08 PM UTC, comment #1: 

Adding maintainer of the generate_html package

Carnë Draug <carandraug>
Group Member
Wed 22 Apr 2015 12:45:49 PM UTC, original submission:  

In texi2html.m I found this hack which effects all emdashes:


  ## Hack around 'makeinfo' bug that forgets to put <p>'s before function declarations
  text = strrep (text, "&mdash;", "<p class=\"functionfile\">");


E.g., I have the following in my texinfo with ascii emdashes "---":

%% The second form---with no output argument---is different; it
%% attempts to find @strong{all} instances of symbols with the same


This gives the following poor rendered in my browser:


The second form

with no output argument

is different; it attempts to find all instances of symbols with the same


and the HTML is messed up by the hack:


<p>The second form</p><p class="functionfile">with no output argument</p><p class="functionfile">is different; it
attempts to find <strong>all</strong> instances of symbols with the same


So the hack is a bit over-reaching...  Actually AFAICT it does nothing useful because the makeinfo seems to put the Function File inside "<dl><dt>" tags.

Should I remove this hack?

Colin Macdonald <cbm>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by oheim (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by jbect
  • -email is unavailable- added by jbect (Posted a comment)
  • -email is unavailable- added by carandraug (Julien Bect - maintainer of generate_html package)
  • -email is unavailable- added by cbm (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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-04-24 mtmiller StatusNone Fixed
        Open/ClosedOpen Closed
    2015-04-22 jbect Carbon-Copy- Added -email is unavailable-
    2015-04-22 carandraug Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code