Re: canvas based footnote editor

[Johannes Wilm]

Hey guys,

I have extended it a bit. Check this example: http://johanneswilm.github.io/canvasContentEditable/

It lets you create new footnotes and update the contents of footnotes. Even most of the key movememts in Firefox work -- with the exception that you cannot move the cursor before elemnts at the very start or end of paragraphs. In Chroomium everythign works: http://johanneswilm.github.io/canvasContentEditable/

On Fri, Apr 26, 2013 at 10:51 AM, Johannes Wilm <johann...@sourcefabric.org> wrote:

Hey,

inspired by the canvas based editor I found yesterday, I created this little demo. It uses Canvas elements for the footnotes. The good thing about those is that they are html stub elements, which means that one doesn't need any keystroke interception to make Chromium and Firefox work correctly in concerns of deleting them, etc.

However, you will notice that firefox doesn't move the cursor quite correctly and that it's impossibel to go beyond the last element. So som key stroke interception would still have to take place, even with this hack.

To see this example in action: open the file in Chromium or firefox. Click on the text so that the cursor shows, and move it back and forth through the text. Then delete one or several of the footnotes with backspace or delete in the body and notice how the footnote disappears.

Check it out and let me know what you think!

--

Johannes Wilm

BookJS Developer

johann...@sourcefabric.org

www.sourcefabric.org

US: +1 520 399 8880

skype: johanneswilm

--

Johannes Wilm

BookJS Developer

johann...@sourcefabric.org

www.sourcefabric.org

US: +1 520 399 8880

skype: johanneswilm

[Johannes Wilm]

Hey,

another little extension. I found out that while Firefox has problems moving the cursor inbetween two CANVAS elements or canvas elements at the start or end of paragraphs, it doesn't have the same problem when it comes to IMGs. So I now copy the canvas output data over into an IMG element before adding it to the DOM. The result is that the cursor can move around exactly the way we need it to!

The downside is that this is an even dirtier hack than the last one.

Chromium even handles copy/paste/cut automatically. For Firefox some extra JS wuld be needed and I didn't bother about that for this example.

Unless one of you comes up with a good reason why we should do this, it seems to me that this is the preferable solution. If we need to support IE, we would of course need to check it there as well.

http://johanneswilm.github.io/canvasContentEditable/

[Adam Hyde]

so....i like this...is it also a good way to manage citations?

adam

[Johannes Wilm]

As far as the display part of the citation management system that fidus writer has, I would currently also say that it should switch to this approach. It means however that citations cannot go over line breaks. Takuto, the FW developer, would know if that is a problem, but I don't think it should be.
I am a little less certain about equations/mathjax. They have an SVG output option, but I haven't investigated more in that direction. I don't know if the cursor behaves the same with SVGs as with IMGs.
An issue that needs to be resolved would have to be how copying to another app would work. One would likely need to do the same as Google Docs, intercept the event, copy stuff off-screen, etc. .

[Johannes Wilm]

Printing is a problem, as the canvas element has too low a resolution. I've tried to upscale it, but the anti-alias doesn't seem to work quite right when downscaling it for screen display. Also, if you make a PDF for on-screen reading, the footnote numbers will not be searchable. 

Using SVGs instead of IMGs would solve this, but unfortunately Chromium has a bug in relation to moving the cursor around SVGs and Firefox has another bug which makes the cursor visually disappear at times when "jumping" across an SVG.

What one possibly could do would be to intercept the print event and temporarily exchange all the footnote number IMGs with text for the duration of the print, and then put the IMGs back afterward.

The problem is again that this is turning into an ever more dirty hack around some fundamental issues with contenteditable.

[Johannes Wilm]

I tried the print idea. Looks good in mozilla/chrome to me. Please try it out (add and change some footnotes, then use the print preview function in Chrome/Firefox, select the text in the resulting PDF)

Btw, should I maybe limit the circle of people I write this stuff to? 

[Adam Hyde]

keep it coming i think...its very interesting

On Mon, Apr 29, 2013 at 2:39 AM, Johannes Wilm

[Johannes Wilm]

ok,

well this is probably as far as I will get with this as a prototype: http://johanneswilm.github.io/canvasContentEditable/

advantages of thsi approach in comparison with others is that the issues with moving the cursor are absent and you don't have to write about 2500+ lines of code to move the cursor.

disadvantages are:

- it's a hack that happens to work on Chrome and Firefox and hasn't been tested in MsIE. Will most likely also work in Safari

- it only works for content that stays within one line and is text

- in its current version it only works with content that has the same styling throughout (all bold or none bold, all small caps or none small caps, all italic/none italic, etc.)

- line height has to be set manually for the document (normal is roughly equal to 1.2)

- handling copy to clipboard would have to be handled if people want to copy their content from this editor to another system (like Libreoffice)

- fotn styling is still slightly different in the print version in comparison to on-screen version. You can try this out in Firefox. clik CTRL+P and watch as the footnote markers transform slightly while the print dialog is open and back once it's gone. I cannot figure out why this happens and I'm not sure if/how this can be avoided.

So now we should have someone make a decision whether it is worth to explorte more in this direction or not.

[Adam Hyde]

personally i think this is interesting but maybe not the right
direction as of yet. more important are margins and other bookjs
thingies

adma

On Mon, Apr 29, 2013 at 9:08 AM, Johannes Wilm

[Johannes Wilm]

Ehm Adam,

margins will not go anywhere for a good while before some relative positioning things have been fixed. My estimate based on previous fixes would be that this could possibly be ready by about December or January.

This is very important for footnotes. Without either this or one of the other proposed solutions I have presented, we will not be able to support footnotes in Booktype -- ever.

[Johannes Wilm]

btw -- when you "margins" you mean "margin notes" right?

In order to be able to enter margin notes within the editor, you will run into the same problems as with footnotes in terms of cursor movement.

[Adam Hyde]

yes margin notes. jan/dec seems to be a long way a way...whats next on
the road map?

adam

On Mon, Apr 29, 2013 at 12:13 PM, Johannes Wilm

[Johannes Wilm]

It's not me working until Jan/Dec. I am just estimating based on the patches that came into Webkit/Blink recently that were based on my reports from July 2012.

Current point is table of figures, and it should be quickly done.

But it would seem a little like waste if we don't get to use features such as footnotes, or top floats that are in BookJS already (Fidus Writer has footnote support already). This is why I would think it would make sense to spend the time to make a footnote plugin for the new Booktype editor ASAP. Also, some thoughts should be put into how we will make use of the top float option in the renderer.

Also the table of figures part will not be usable by Booktype users as long as there is no formal figure support (a way of inserting a standardized div which includes a picture/figure with a caption and optionally a short title which is "undestructable" by the user). It will be yet one more feature that Booktype users won't get to use.

[Johannes Wilm]

After this mornings BT meeting, I see the need to clarify this line:

"- it only works for content that stays within one line and is text"

This only applies to the part that is within the body text. So in the case of footnotes, this is the footnote number that is displayed in the body text. There are no length restrictions placed on the footnote itself.

This may seem like a weird point to be making as you wioll need about a quadrilion squared footnotes within a document before the footnote number will no longer fit within a signle line of text.

This is more important in other contexts -- for example figuires with captions. Those captions may go over more than one line. There may be ways of using this same technique even then, but there will be some more programming to it than what we currently have.

This prototype code should be about 50% of what is needed to get a working footnote mechanism in Booktype that can work together with the footnote support that is already present in BookJS and will only have to ber adjusted slightly to work with this. That should do it for PDF output.

In my opinion, what is needed now though is a decision of which editor we go for, so that this can be converted from a prototype to a plugin in such an editor. Then it can always be expanded to do more complex things later on, or a different technique has to be used for figures with captions.

[Adam Hyde]

we made the decision 7 months ago for WYSIWHAT (ALOHA)...this still
looks good and there is work being done on it...why are re
re-evaluating?


adam

[Johannes Wilm]

Hey Adam,

as you mentioned yourself recently -- Aloha hasn't really evolved lately. And as the other email showed, the contributors of thew WYSIWHAT branch are killing it right now, even though we don't want them to do that.

Also, TinyMCE 4 may just have more people behind it, and it didn't exist back then.

But I am still open to either one. In the end, you guys are the ones who will have to live with Booktype in the long run and I'm happy to build a footnote plugin for whatever you feel more comfortable with.

[Johannes Wilm]

Hey guys,

thanks to Victor Carranza I just had access to a windows machine and can report back that this solution also works in Internet Explorer 10. So it produces canvas elements, which are turned into images, which the cursor then managed to move around as if they were individual letters. Perfect!

The fucntions I used to insert new footnotes are not compatible, but I guess that incompatibility is why one uses the rangy library for cursor based insertions and other advances stuff rather than direct javascript.