Skip to content

Fix Footnote link spacing #399

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

martynchamberlin
Copy link

There is a white space in the DOM from the end of the footnote to the beginning of the <a> tag that serves as a reversefootnote. I'd love to be able to replace this white space to &nbsp;. What this would effectively do is ensure that the backlink could never get pushed down to its own line in the footnote. If there wasn't enough room for it on the previous line, then since it'd be connected to the final word in the footnote, then it would push both the final word and the link to the next line.

Perhaps illustrations would help. Here's the old way:

And here's the new way:

See how much better the latter looks?

@martynchamberlin
Copy link
Author

I'll update the tests if we get the green light on this!

@gettalong
Copy link
Owner

What if there are more than one backlinks? Should there also be a non-breaking space instead of a normal space?

@martynchamberlin
Copy link
Author

Ah good call. Yes, that should be a non-breaking space as well. I have changed both scenarios and also updated all of our test templates.

@gettalong
Copy link
Owner

Thanks for the changes - I will include them with the next release! One more thing: Please merge your commits into one.

@martynchamberlin
Copy link
Author

@gettalong Excited to hear! I've squashed my second commit. Thanks.

@martynchamberlin
Copy link
Author

@gettalong Just curious when may we expect the next release? Sometime this Jan?

@gettalong
Copy link
Owner

@martynchamberlin Yes, in the next few weeks when I have time.

@gettalong
Copy link
Owner

Thanks for your contribution - will be released today.

@gettalong gettalong closed this Jan 7, 2017
@martynchamberlin martynchamberlin deleted the patch-1 branch January 7, 2017 18:12
@martynchamberlin
Copy link
Author

Lovely!

KnairdA added a commit to KnairdA/blog.kummerlaender.eu that referenced this pull request Jan 17, 2017
The trigger but not the actual reason for this replacement of `kramdown` with `pandoc` was a strange generation issue with `kramdown`'s latest release.

All recent articles failed to generate anything more than an empty page. A quick check of the resulting HTML for those articles offered nothing out of the ordinary. After taking a close look at the articles in question I narrowed the set of failing articles down to those containing footnotes - tangentially I only started using footnotes a couple of articles ago i.e. this explained this part of the issue.

Some debugging of `InputXSLT` offered the following problem: `Xerces-C` generated an error message and stopped processing XML inputs containing `nbsp` non-blocking space characters in the implementation of the `external-command` function. This change in `kramdown`'s output can be traced back to enhancement issue [399](gettalong/kramdown#399). Obviously this is not a problem in `kramdown` but an issue in the way this static site generator is wrapping HTML inputs.

This problem should be solvable by adding appropriate namespace and doctype declarations to the markdown-generated HTML output. Instead I opted to perform the change to `pandoc` I had already planned for quite some time.

The choice fell on `pandoc` as it offers some additional markdown features as well as allowing for conversion to a rich set of document formats. i.e. features like printing articles as PDF using LaTeX are trivial to implement if `pandoc` is the markdown processor of choice. Furthermore page compilation is noticeably faster using `pandoc`.

One might note that this switch only solved the original issue by coincidence: Should `pandoc` start to generate non-blocking space characters the same problem will occur. But I have hopes that such a change would be configurable via `pandoc`'s plethora of configuration options. As this static site generator assumes everything to be XHTML I see no reason why I should not continue to treat HTML inputs as XML.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants