Fix Footnote link spacing#399
Closed
martynchamberlin wants to merge 1 commit into
Closed
Conversation
Author
|
I'll update the tests if we get the green light on this! |
Owner
|
What if there are more than one backlinks? Should there also be a non-breaking space instead of a normal space? |
077d802 to
bd9e7aa
Compare
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. |
Owner
|
Thanks for the changes - I will include them with the next release! One more thing: Please merge your commits into one. |
Fix tests
8f52b31 to
4b22b6d
Compare
Author
|
@gettalong Excited to hear! I've squashed my second commit. Thanks. |
Author
|
@gettalong Just curious when may we expect the next release? Sometime this Jan? |
Owner
|
@martynchamberlin Yes, in the next few weeks when I have time. |
Owner
|
Thanks for your contribution - will be released today. |
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 . 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?