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

Fix Footnote link spacing #399

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
2 participants
@martynchamberlin
Contributor

martynchamberlin commented Dec 15, 2016

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

This comment has been minimized.

Contributor

martynchamberlin commented Dec 15, 2016

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

@gettalong

This comment has been minimized.

Owner

gettalong commented Dec 15, 2016

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

@gettalong gettalong self-assigned this Dec 15, 2016

@martynchamberlin

This comment has been minimized.

Contributor

martynchamberlin commented Dec 15, 2016

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

This comment has been minimized.

Owner

gettalong commented Dec 17, 2016

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

@martynchamberlin

This comment has been minimized.

Contributor

martynchamberlin commented Dec 17, 2016

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

@martynchamberlin

This comment has been minimized.

Contributor

martynchamberlin commented Jan 5, 2017

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

@gettalong

This comment has been minimized.

Owner

gettalong commented Jan 6, 2017

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

@gettalong

This comment has been minimized.

Owner

gettalong commented Jan 7, 2017

Thanks for your contribution - will be released today.

@gettalong gettalong closed this Jan 7, 2017

@martynchamberlin martynchamberlin deleted the martynchamberlin:patch-1 branch Jan 7, 2017

@martynchamberlin

This comment has been minimized.

Contributor

martynchamberlin commented Jan 7, 2017

Lovely!

KnairdA added a commit to KnairdA/blog.kummerlaender.eu that referenced this pull request Jan 17, 2017

Use `pandoc` as markdown processor
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