tufte css and friends

[Joe Corneli]

I found these, which look like they could provide a nice convention for styling the web page. Some are designed to work with Jekyll so we would presumably be able keep our current workflow without changes.  Some of them would require a further step of processing (which could be automated).

https://edwardtufte.github.io/tufte-css/

http://vieiro.github.io/xmark/

https://github.com/sdruskat/tufte-css-jekyll

http://clayh53.github.io/tufte-jekyll/articles/15/tufte-style-jekyll-blog

https://github.com/schollz/markdown2tufte

[Joe Corneli]

Tufte style now integrated into a demo page here: https://peeragogylabs.github.io/pattern-reduce.html

With this example in mind, I have to say, I think re-using Edward Tufte's layout, and others' technical work making that available in the browser, would *significantly* improve the usefulness and accessibility of the Handbook's content.  In particular, we can now integrate "mini handbooks" into the margin of the page!!  I think this is a game changer and would advocate that we use Tufte layout across both HTML and LaTeX/PDF versions of the book for v4.  EPUB will have to be a bit different, but logically compatible.

(Notice that on a small screen or narrow browser window, the HTML page does a little bit of reflowing and introduces a ⊕ button to access the image, or number to access the numbered note, which then appears inline.)

I'm not sure yet how our workflow and style guide would have to change to accommodate writing in the new style.  Let's not worry too much about that right now -- we can get a bit more demo content ready.

Tech notes:

The demo is based on integrating code from this source: https://github.com/sdruskat/tufte-css-jekyll

Caveat Scriptor!  Github only allows certain plugins, so to get this to build, I had to run Jekyll locally, and copy the HTML files into the root of the directory, and add a .nojekyll file to turn off automatic regeneration of content on the Github side.

- https://stackoverflow.com/questions/13189188/how-do-i-stop-github-from-regenerating-jekyll-site

If you look at the page sources you'll see some of the changes that had to be made for the new display:

https://github.com/PeeragogyLabs/PeeragogyLabs.github.io/blame/master/pattern-reduce.md#L51 : a figure in the margin

https://github.com/PeeragogyLabs/PeeragogyLabs.github.io/blame/master/pattern-reduce.md#L81 : footnotes (which in this case happen to be links) now appear in the margin

It is possible to add both numbered and unnumbered marginal notes.

The relevant Quickstart Guide section seems out of date on Ubuntu 18.04.  To replicate the technical steps done here, you can clone the repo and do this:

sudo apt install jekyll

jekyll build

cp  _site/*.html .

<commit>

To preview content locally, just do:

jekyll serve -w

I'll update this section once I'm sure of the details.

https://github.com/Peeragogy/peeragogy-handbook/wiki/Quickstart-guide#previewing-locally

[skreutzer]

Hmm, the Tufte layout + alternative ETBook font (as the original font is proprietary) are under the X11 license, which would render a printed book, electronic PDF and e-book (distribution-wise) effectively X11 licensed as well, because it might be impossible or not feasible to strip the layout away from it again. The requirement would be to include the copyright notice of Tufte CSS and ETBook (, which is not CC0 any more (somewhere) for the combined work, as a whole). What to do about it, not use Tufte CSS, go X11, ignore, other?

For Jekyll and checking in generated HTML just to use GitHub Pages for "serverless" hosting, I don't know, that's a little bit strange, but OK.

[Joe Corneli]

Regarding licensing, the licensing for these presentational  components shouldn't affect the licensing for content.  (For example, Jekyll itself will have some license, Github is proprietary, etc.)  In my view we should take whatever steps needed to preserve the waiver as our standard for content, including separating out the content and presentation further.  Note that I did have to make a couple of changes to the Tufte CSS, so we'll want to hang on to those somewhere (and release a modified version of that package under X11 or release a small CC Zero patch to be added in.)

For comparison, in the print case, https://ctan.org/pkg/tufte-latex?lang=en is Apache licensed, and we'd want to acknowledge the *use* of this, along with the XeLaTeX engine, but this shouldn't affect the copyright or licensing status of "the book" itself.

Apart from licensing: I'm concerned that we will run into a workflow challenge if we try to write everything in standard Markdown.  The Tufte-enhanced version uses lots of other special markup.  I'm not sure what format would be best to standardize on, but we want something that is easy to write.  We'll need to discuss this more widely.

On Mon, 24 Feb 2020 at 16:34, 'skreutzer' via Peeragogy <peer...@googlegroups.com> wrote:

Hmm, the Tufte layout + alternative ETBook font (as the original font is proprietary) are under the X11 license, which would render a printed book, electronic PDF and e-book (distribution-wise) effectively X11 licensed as well, because it might be impossible or not feasible to strip the layout away from it again. The requirement would be to include the copyright notice of Tufte CSS and ETBook (, which is not CC0 any more (somewhere) for the combined work, as a whole). What to do about it, not use Tufte CSS, go X11, ignore, other?

For Jekyll and checking in generated HTML just to use GitHub Pages for "serverless" hosting, I don't know, that's a little bit strange, but OK.

--
You received this message because you are subscribed to the Google Groups "Peeragogy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to peeragogy+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/peeragogy/3865e980-e98d-4bd4-ac91-6be6050ba829%40googlegroups.com.

[skreutzer]

The licensing of the layout is of course separate from the licensing of the text. The use of Jekyll too is without effect because Jekyll isn't distributed together with the work, nor the licensing of the GitHub SaaS code for hosting. With the PDF, physical print copies and an e-book (the latter for the reason of font embedding) however, it's different, because I would assume that these are a "combined work" where you are using + distributing the layout and font under their licenses, and you can't separate or strip out the parts that are licensed under X11, so a user indeed still receives the text part under CC0, can share and modify it under the conditions of CC0, if the layout and font is removed (typing the text off, OCR, removing the layout parts from the EPUB for subsequent redistribution, which renders the included layout a little bit pointless but anyway), but for the files we provide and may subsequently distributed/modified by users and third parties, these do include the layout and font and therefore practically speaking have to satisfy both the requirements of CC0 as well as X11, because in these cases, the two parts of the work are not distributed separately (so for any practical use case, an end user might not encounter the Jekyll or GitHub dependencies with their licenses, but would those of the layout and font). On the license waiver page for the text and in the metadata of an EPUB, it would/should need to say that layout + font is copyrighted + licensed under X11 by its contributors, together with text + images under CC0, and an end user has to agree to both, for the work as presented. Note that in print, I think the current status is that the use of a font on the page is not copyrightable, but a layout may (especially as the people who did the Tufte layout claim copyright in order to establish X11 licensing, which may target the "expression" of their CSS code, but almost certainly is intended to expand to the layout as well, where no reliable assumptions can be made what would be considered an infringement and if the creators/designers would enforce their copyright, just in any case, their work isn't under CC0, and CC0 and X11 aren't the same, therefore it's another legal complication caused by stupid print-era copyright regulation incompatible with the digital age and inadequate "open" licensing practices, for which solutions may or may not exist). Same would apply for the Apache license for the layout for LaTeX, if the web X11 variant doesn't get ported to LaTeX. It could be that the X11 is vague/ignorant enough that the required license notification could be included somewhere in an e-book, but not displayed, which might not be entirely "safe" to do it this way, but wouldn't work for printed books and PDFs for the layout (minus font embedding in PDF/EPUB). Anyway, this isn't legal advice, just my current understanding of how the copyright law works and what the authors/creators stated as their demands/intentions. I think I'm personally much affected because I'm not a handbook content contributor. Contributors might not mind that their CC0 text becomes part of packages that also have a X11 requirement, and there can still be variants without the Tufte layout. Just for uploading to distributors and printing, as well as the end user + third parties, they wouldn't be allowed to remove the X11 license notification for redistribution which includes Tufte layout + font, which they are permitted for earlier handbook versions and continue to be for the CC0 text up to copyfraud/re-licensing and proprietary use, which the X11 would prevent now for these combined works, and if I'm not mistaken, it was an important point and legal feature to specifically allow proprietary use and copyfraud (in the hope to encourage wider spread). The Tufte contributors with their work obviously are not in favor of this for their part.

Technically, I haven't looked into the whole Tufte thing yet, don't remember if fonts get extracted and packaged to EPUB if referenced in CSS (if that's what the Tufte CSS is doing), which all may come easy/cheap or maybe not. I did see that they rely on some additional markup, and most concerning, that it's partially HTML5. EPUB3 was (still is?) at the forefront of HTML5 and relies on it in some sense, included it even before the spec became more static (but now these Web people don't even want to have specs and versions any more), but then EPUBs are (and reasonably so) expected to be valid (plus I'm not going to do anything around broken XML HTML5, and don't want to invest much into proper/full XHTML5 or XHTML5 Polyglot, especially with W3C, WHATWG, browser vendors actively sabotaging and degrading Web technology), so let's see if it works out for the Tufte layout, or if it enters into a dirty, stupid mess. For Markdown, I don't know, arrived at the concept that it's just a textual interface for writing (not a very good one as its supposed simplicity easily breaks down where people want to do all kinds of more complex expressions in it, which requires non-intuitive syntax) where the process also gets confused with markup/layouting/typesetting/semantics, so writing + semantic markup could be separate concerns or maybe more importantly, the Markdown plain-text syntax writing/markup interface shouldn't be confused with a proper data format that actually comes with real semantics and stuff, so maybe there could be a conversion from Markdown to ideally (namespace-mixed?) XML or something, maybe with an extra parser/pass that handles our own "extensions" (not to the Markdown "format", but our variant of Markdown as a writing interface/convention), like Mediawiki with the Wikitext writing interface (targeting HTML output, still confused with a data format but anyway) uses server-side template plugins/parsers to do all kinds of special, custom processing that's not necessarily supported elsewhere or standardized beyond their own domain. If we would go down that route, OK, the question might be asked of why to continue to bother with Markdown to begin with, or if something else could be used, some other textual writing interface/convention, or maybe (as it could be, but rarely is) one or several ordinary or specialized GUI(s). In any case, I currently don't have a Markdown parser of my own (somebody said it's difficult to parse, maybe because of strange and exceptional random nested symbols that need to be taken care of), and only using Pandoc because you guys had that on board already, previously. Isn't YAML headers in there already too? And XML (HTML fragments) is in the "Markdown" source files just as well (barely retaining that during the use of Pandoc by going Markdown to HTML first and then to LaTeX or whatever, in the hope that XML never conflicts with Markdown special characters). As said, don't know about how I would go about this technically, not overly concerned yet, in contrast to the legal questions because there's always the risk that no amount of effort might be able to resolve issues caused in the latter realm.