[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [eLyXer-users] elyxer.py bug

From: Jose Ramon Alvarez Sanchez
Subject: Re: [eLyXer-users] elyxer.py bug
Date: Sat, 23 Feb 2013 22:50:59 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Hi all,
I think that it was not intended in eLyXer to have at the same time 
both "hover" and "end" options for footnotes. The footnote contents
was built by creating a common anchor for all (hover, end and margin),
so if "endfoot" and other one (hover or margin) is used at the same 
time, then the first anchor in html will be the one for the hover
note near the marker, and the same anchor in the endfootnote is never
reached. This produces the behavior described by Tim.

It could be usefull for me also to have both options for footnotes.
I checked the source file and found a few changes that fix the bug
and make it work with more than one option (even with the three). 

Your copy of elyxer.py attached is somehow corrupted (unicode conversion),
so i only can tell you the changes you (or the husband of your colleague)
must do to your copy of elyxer.py. Beware the indentation, important to 
Python, can be lost in email list:

1. Insert in class Footnote  (around line 6057) a new member function
   "createlabel" with the following lines:

     def createlabel(self, marker):
       "Create the label for a footnote. Used in hoverfoot and marginfoot."
       self.order = marker.order
       self.contents = [Constant(self.getmark())]
       space = Constant(u' ')
       self.contents = [space] + self.contents + [space]
       return self

2. Modify the member "process" in class Footnote (around line 6114) 
   substituting it all by the following lines:

       def process(self):
         "Add a counter for the footnote."
         "Can be numeric or a letter depending on runtime options."
         marker = FootnoteMarker().create()
         anchor = FootnoteMarker().createanchor(marker)
         label = FootnoteMarker().createlabel(marker)
         notecontents = list(self.contents)
         self.contents = [marker]
         if Options.hoverfoot:
           self.contents.append(self.createnote([label] + notecontents, 'span 
         if Options.marginfoot:
           self.contents.append(self.createnote([label] + notecontents, 'span 
         if Options.endfoot:
           EndFootnotes.footnotes.append(self.createnote([anchor] + 
notecontents, 'div class="EndFoot"'))

In any case, as Alex has moved now the sources to github, I will try
to set a fork there to do these changes in the correct file 
(src/elyxer/gen/notes.py) and propose him a pull-request for the next

Best regards,
Jose R.

On Mon, Feb 04, 2013 at 03:44:31PM +0000, Kaye, Timothy S. wrote:
> Dear everyone,
> I have found a bug in elyxer which I don't have the expertise to fix, and 
> which Alex doesn't have the time to fix. It concerns the way that elyxer 
> produces footnotes.
> As you know, elyxer can produce marginal footnotes and hovering footnotes, 
> both of which work fine. And then there are endnotes, which is where the 
> problem lies (but only when used in conjunction with hovering footnotes).
> What should happen is that, when the user clicks on a footnote number, s/he 
> is taken to the footnote itself. Currently, what happens is that the screen 
> scrolls only far enough to put the clicked number at the top of the page. 
> (The function to return to the right place in the main text from the footnote 
> works fine.)
> I am attaching Alex's working example for you to see this, together with the 
> latest version of elyxer.py that I have. (You might need to reduce the width 
> of your browser to see it.) You need to type:
> $ ./elyxer.py --footnotes hover,end,number footnotes-1-6.lyx output.html
> If the endnote function is run alone, however, there there is no problem. See:
> $ ./elyxer.py --footnotes end,number footnotes-1-6.lyx output.html
> So the hover function is somehow interfering with the endnotes function. 
> Unfortunately, I really need them both.
> Alex identified the problem as being "the code for the hovering footnote:
>   <a href="#0.3_footmarker-A" name="0.3_footnote-A">[A]</a>
> it defines the anchor for the footnote and a link back to the marker."
> The husband of a colleague, who knows some Python but not enough to fix the 
> problem, has worked out what the fix needs to achieve. In the screenshot 
> attached, the yellow highlight is the footnote link (which is supposed to 
> link to the bottom of the page). The pink highlight is the hover footnote 
> link which, instead of also linking to the bottom of the page, is linking 
> back to the main footnote.
> He suggests that we need to flip the words "note" and "marker" in the pink 
> highlight to change this. Apparently, this means replacing every occurrence 
> of:
> <span class="HoverFoot"><span class="SupFootMarker"> <a class="Link" 
> name="footnote-
> with:
> <span class="HoverFoot"><span class="SupFootMarker"> <a class="Link" 
> name="footmarker-
> He continues:
> "You have to use that whole string starting with "HoverFoot" to ensure you're 
> changing just the hovering footnote links and not the main ones. In the 
> sample document, there are 9 footnotes so this find/replace should happen 9 
> times. Now to fix the second part (the anchor name) we need to replace:
> href="#footmarker-
> with:
> href="#footnote-
> BUT ONLY FOR THE FIRST X OCCURRENCES where X is the number of footnotes. If 
> you replace beyond that, you'll be breaking the links in the end footnotes at 
> the bottom of the document.
> And now both the regular and hover footnotes should properly jump to their 
> corresponding footnote at the end of the document. My "fixed" sample output 
> is attached."
> Alex tells me that the development version of eLyXer at  
> https://github.com/alexfernandez/elyxer is much friendlier than the 
> monolithic version that we all use but, as I say, neither my colleague's 
> husband nor I have the expertise to fix this.
> I am currently working on a project where I really need to have both hovering 
> footnotes and endnotes working together as intended. Does anyone out there 
> have the time and expertise to take a look, please? I really would be 
> enormously grateful!
> Thanks for reading to the end of this rather long email!
> Tim
> Dr. Tim Kaye
> Professor of Law
> Stetson University College of Law
> 1401 61st Street South
> Gulfport
> Florida 33707
> Tel: +1 (727) 562 7347
> Email: address@hidden <mailto:address@hidden>
> http://ssrn.com/author=1016621
> http://www.law.stetson.edu<http://www.law.stetson.edu/>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]