WikiJournal Preprints/Multi-format Publishing on GitHub

WikiJournal Preprints
Open access • Publication charge free • Public peer review

This article is an unpublished pre-print not yet undergoing peer review.

To submit this article for peer review, please:
Submit authorship declaration form

Article information

Abstract

The paper explores the challenges of using GitHub as a platform for multi-format publishing. GitHub is being tested as a publishing platform as it offers a versioned, collaborative, storage location, with: the ability to serve verified master sources for a publication, a collaborative publication management environment for flexible workflows, web serving, and an API/file serving facility that allows different systems to interact with the publication. This system interaction and interoperability is important for many reasons, for example to allow the author to never touch GitHub/Lab and stay in a WYSIWYG editor that is 'inside their comfort zone' and be focused on their ideas.

A specific 'techstack use case is examined in the paper where a number of existing software platforms are utilized: Fidus Writer, Vivliostyle, and Jekyll/Hugo.

The use case features provide an example where a source is delivered to GitHub/Lab (JSON/HTML/EPUB/XHTML based); multi-format conversion is made to - MD (Scholarly MD), HTML, EPUB, BiB, Screen PDF, PoD PDF; an interoperable book source is served to the 'format multiverse' (multiverse is used here as there are whole domains tied to formats where the book should made available) - R, MD+++, RDF, XML, etc; use CSS Typesetting with sharded outputs; convert to Moodle/LMS; deliver to multi-channel distribution; multi-format outputs are synchronised; enable source to be interfaced via Open Science services - content and data science types; and to use metadata and PIDs across publications.

Not all of the use case features can be achieved and the reasons for this will be described.

First Heading

Image caption text goes here (attribution: name of image creator, CC-BY 3.0)

Manuscript text goes here

Subheading

e-book

Assumptions

Target outputs for e-books. The initial assumption is for: a) basic EPUB 3.0; b) basic Amazon Kindle kf8, and c) standard Vivliostyle targeted web-buch layout for ereaders using Chrome Browser.

Media queries: The initial assumption is to use CSS Media Query where simple ereaders that cannot read media queries read the simple CSS set, then other devices that can read media query pick up targeted media query CSS.

CSS Page Templates in ePUB 3.0: Do basic ereader devices use this, is it usable on Kindle, is there a good guide available?^[1]

Validators: which ones to use and how to use them.

Benchmark ebooks: one for a, b, and c. Also a generic benchmark. Can you supply examples?

German language: Hyphenation; using forced justification or not?

Third Heading, etc

Questions:

Using GitHub Pages as a web server to produce a 'website' version of a book where the book can be produced as HTML and not Markdown. The reason for wanting to use HTML is that Markdown cannot handle tables, maintaining image and table sequential numbers across chapters has to revert to HTML. This Markdown issues might be able to be resolved at a later date but prove to add a workload overhead that is greater than using HTML. Additionally we are not authoring in Markdown and only need it as an output to then generate HTML so the use of Markdown is redundant.

Additional information

Acknowledgements

Any people, organisations, or funding sources that you would like to thank.

Competing interests

Any conflicts of interest that you would like to declare. Otherwise, a statement that the authors have no competing interest.

Ethics statement

An ethics statement, if appropriate, on any animal or human research performed should be included here or in the methods section.

References

↑ "CSS Page Templates in ePUB 3.0". EPUBSecrets. 2012-03-05. Retrieved 2020-05-02.

[2] "CSS Page Templates in ePUB 3.0". EPUBSecrets. 2012-03-05. Retrieved 2020-05-02.

[1]