several references to same footnote/endnote

[Johannes Wilm]

hey guys,

the question of whether it is a typical use case to reference to the same endnote (or footnote) several places within the same text came up recently. I found this discussion on some people who try to do this with latex was quite interesting:

http://tex.stackexchange.com/questions/35043/reference-different-places-to-the-same-footnote

http://tex.stackexchange.com/questions/10102/multiple-references-to-the-same-footnote-with-hyperref-support-is-there-a-bett

I gather a few things from this:

• footnotes/endnotes are handled in the same way
• footnotes/endnotes are constructed as default to only be referenced one place. This is what I had in my latex dominated head already, which is probably why I constructed the prototype editor around this concept.
• Wikipedia does allow several references to the same endnote/footnote (which is the same)
• there are some (kind of complex ways) in latex which will allow you to make a second mark to the same endnote/footnote

--

Johannes Wilm

BookJS Developer

johann...@sourcefabric.org

www.sourcefabric.org

US: +1 520 399 8880

skype: johanneswilm

[Johannes Wilm]

One of the features of the canvas editor is that you can copy/cut/paste part of the main text, and the footnotes/endnotes/margin notes will behave according -- renumbering takes place if needed and so on*. if we want to have multiple references to the same endnotes, then we need to think of another approach. Possibly like Latex: The first footnote is done as in this example, and any subesequent reference to the same footnote/endnote is a link to that node. I am unsure how to make the node lnking survive copy/paste, however. The current Booktype editor cannot handle copy/cut/paste at all.

@Aco: Maybe you have an idea?

*) I heard from Micz that it didn't work in Chrome 25, but at least in Chrome 26 onward it is working. 

[Johannes Wilm]

On Mon, May 27, 2013 at 12:36 PM, Micz Flor <micz...@sourcefabric.org> wrote:

In general, this would be  a beefed up version of the current footnote management: in the same document, numbering automatically. PLUS you can chose if it is a footnote or an endnote of the chapter.

But it would still not allow to decide in total
- if you want footnotes or endnotes for chapter OR book
- if you want numbering per chapter OR numbering for the entire book

Is this correct?

Not quite. The point with this solution is not to create the final HTML that is being used for the final output display. The point is that the footnotes/endnotes are stores in a way similar to XML, so that it is easy to make different types of final outputs  -- either in Objavi Python code, in Booktype Python code or even in javascriptcode that is put in before BookJS is fired to make the PDF (in which case another solution has to be found for epubs).

That final formatting could then decide where the endnotes are to appear and what the numbering scheme is. It could for example make sense to treat footnotes and endnotes as if they were the same when producing epubs, while in PDFs they have two different numbering schemes (fx alphabet and numeric) and are displayed as footnotes and endnotes. 

The final formatter could also decide where the numbering is being restarted: per chapter, per book, per section, etc. and if the end notes are put at the end of the chapter or the end of the book. 

 

To leap into the complete solution, I don't see how footnotes can work without being managed separately in a database.

forgetting about multiple links to the same footnote/endnote for a second, for which I don't have a complete solution in my head right now, I don't think this is the case.

I will be happy to explain this in further detail in a Google Hangout session or alike.

 

-- Micz Flor Co-Founder and Director, Sourcefabric micz...@sourcefabric.org www.sourcefabric.org Sourcefabric Prinzessinnenstraße 20 10969 Berlin, Germany twitter: @Sourcefabric

[Johannes Wilm]

On Mon, May 27, 2013 at 12:36 PM, Micz Flor <micz...@sourcefabric.org> wrote:

...

To leap into the complete solution, I don't see how footnotes can work without being managed separately in a database.

Gideon has earlier hinted at a database based solution, but I was never quite told how that would work.

The database based solution would be that the text of the footnote would be saved in a separate database, right? So what do we do if someone selected three paragraphs of text containing 30 footnote references and deleted them? I assume we would use a mutation watcher to see if footnote references diappear, and if they do, makes calls to the sevrer, asking it to delete the footnotes in the database, right? 

What if some of the same footnotes were referenced from the same chapter and some from other chapters? The footnote database table would have to keep track of what chapters what footnotes are referenced from, so that it can know when it really can delete a specific footnote. Before we do the "footnote 2 has been deleted" call to the server, the cleint needs to check if footnote 2 is referenced to from any other place within that same chapter. If it is, it shouldn't call the deletion procedure.

Is that correct?

[Aco Erkalovic]

On Mon, May 27, 2013 at 6:47 PM, Johannes Wilm <johann...@sourcefabric.org> wrote:

Not quite. The point with this solution is not to create the final HTML that is being used for the final output display. The point is that the footnotes/endnotes are stores in a way similar to XML, so that it is easy to make different types of final outputs  -- either in Objavi Python code, in Booktype Python code or even in javascriptcode that is put in before BookJS is fired to make the PDF (in which case another solution has to be found for epubs).

Not really. There is 0 difference between having <div class="footnote"> and <ul class="footnotes><li class="footnote_33233"> (or whatever is the correct syntax right now). Both of the solutions provide possibility of post processing and creating different output. Which is the case with out new ebook engine. That engine easily creates iPad friendly footnotes from the current scheme. The only difference is really: 1) your solution provides only 1 on 1 relationship 2) in second case, because you can reference one endnote from multiple places, you have to do extra processing to be sure all references are deleted. 

Aco

 

--
Aleksandar Erkalović

Booktype Developer
aleksandar...@sourcefabric.org

www.sourcefabric.org

mobile: +385-(0)91-6425220
twitter: @aerkalov | skype: aerkalov

[Johannes Wilm]

Hey guys,

in the end it doesn't matter all that much to me. If aco thinks he has a better solution, then go for it.

On Mon, May 27, 2013 at 5:46 PM, Aco Erkalovic <aleksandar...@sourcefabric.org> wrote:

On Mon, May 27, 2013 at 6:47 PM, Johannes Wilm <johann...@sourcefabric.org> wrote:

Not quite. The point with this solution is not to create the final HTML that is being used for the final output display. The point is that the footnotes/endnotes are stores in a way similar to XML, so that it is easy to make different types of final outputs  -- either in Objavi Python code, in Booktype Python code or even in javascriptcode that is put in before BookJS is fired to make the PDF (in which case another solution has to be found for epubs).

Not really. There is 0 difference between having <div class="footnote"> and <ul class="footnotes><li class="footnote_33233"> (or whatever is the correct syntax right now). Both of the solutions provide possibility of post processing and creating different output. Which is the case with out new ebook engine. That engine easily creates iPad friendly footnotes from the current scheme. The only difference is really: 1) your solution provides only 1 on 1 relationship 2) in second case, because you can reference one endnote from multiple places, you have to do extra processing to be sure all references are deleted.

In the current solution you cannot copy a pice of text with a footnote connected to it and then paste it somewhere else and have the footnote follow it then and have the numbering auto-updated -- for example into another chapter, or another book or another instance of Booktype on a different server, etc.

Also, the user can currently manually delete the endnote, and the endnotereference will continue to be there. If you then enter another endnote, it will start from 1 again.

This has advantages and disadvantages. It depends a bit on how much one trusts the user: Does one let the user do potentially "stupid stuff" or not? Freedom comes with responsibility.

Given that it is Aco who will run Booktype in the future and who will have to deal with the backend, I think it just makes most sense to follow his approach.

 

 

Aco

 

--
Aleksandar Erkalović

Booktype Developer
aleksandar...@sourcefabric.org

www.sourcefabric.org

mobile: +385-(0)91-6425220
twitter: @aerkalov | skype: aerkalov

[Aco Erkalovic]

On Mon, May 27, 2013 at 11:55 PM, Johannes Wilm
<johann...@sourcefabric.org> wrote:
> In the current solution you cannot copy a pice of text with a footnote
> connected to it and then paste it somewhere else and have the footnote
> follow it then and have the numbering auto-updated -- for example into
> another chapter, or another book or another instance of Booktype on a
> different server, etc.

This is correct. What i have found out after couple of years is that
people copy+paste a lot between 2 different instances of Booktype.
Footnotes all over the servers :)

> Also, the user can currently manually delete the endnote, and the
> endnotereference will continue to be there. If you then enter another
> endnote, it will start from 1 again.

Well..... to be honest, you have created a new moment here. There are
two blocks now, one where the content is and 2nd one where the editing
is happening. If we take the current situation (one footnote can have
many references) to the new model, then it is also possible
(especially with the new editor) to have chapter of the content and
footnote content separate and out of user (he or she will not be able
to delete or touch it). Minimal effort to make it work really. Well...
more like _a must_ and less _it is also possible_. The situation where
one does copy+paste between different instances and maybe chapters
still remains.

I think we should see what is what we want with the footnotes feature
and how you should develop this plugin really.

[Johannes Wilm]

On Mon, May 27, 2013 at 6:48 PM, Aco Erkalovic <aleksandar...@sourcefabric.org> wrote:

On Mon, May 27, 2013 at 11:55 PM, Johannes Wilm
<johann...@sourcefabric.org> wrote:
> In the current solution you cannot copy a pice of text with a footnote
> connected to it and then paste it somewhere else and have the footnote
> follow it then and have the numbering auto-updated -- for example into
> another chapter, or another book or another instance of Booktype on a
> different server, etc.

This is correct. What i have found out after couple of years is that
people copy+paste a lot between 2 different instances of Booktype.
Footnotes all over the servers :)

the last example was not completely serious. The other ones were.

But as I said previosuly, it's mainly a matter of how much or little control you want to give to the user. If you control everything he does and limit him, you can make pretty sure that the outcome is good. However, you may miss some edge cases -- what for example if the user wants to make a footnote reference, but doesn't want a footnote? Or what if he wants the opposite: a footnote, but without the reference to it in the text? Or he wants to reference to a footnote from another page than where he wants it to be placed on? 

The other approach is to make a minimal support mechanism, like the current footnote plugin, and let the user the user do both stupid and smart stuff. That way there is nothing hindering creativity.

I can see advantages to both approaches, and you are the one who has to live with Booktype. So if you want the creative approach -- I think you should go for that. Users will likely complain either way: either because they feel too many constraints... or because not everything is working automatically.

 

> Also, the user can currently manually delete the endnote, and the
> endnotereference will continue to be there. If you then enter another
> endnote, it will start from 1 again.

Well..... to be honest, you have created a new moment here. There are
two blocks now, one where the content is and 2nd one where the editing
is happening.

If we take the current situation (one footnote can have
many references) to the new model, then it is also possible
(especially with the new editor) to have chapter of the content and
footnote content separate and out of user (he or she will not be able
to delete or touch it). Minimal effort to make it work really. Well...
more like _a must_ and less _it is also possible_. The situation where
one does copy+paste between different instances and maybe chapters
still remains.

I think we should see what is what we want with the footnotes feature
and how you should develop this plugin really.

Aco

--
Aleksandar Erkalović
Booktype Developer
aleksandar...@sourcefabric.org

www.sourcefabric.org

mobile: +385-(0)91-6425220
twitter: @aerkalov | skype: aerkalov