How to work with wiki-to-print?: Difference between revisions

From creative crowd wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
__TOC__
__TOC__


Wiki-to-print is a collaboratively publishing environment in which PDFs can be written, edited and designed by multiple people simultaneously.


Wikis are great for (a-sync) collaborative writing and editing, which is why the MediaWiki software is a part of wiki-to-print. Alongside this, concepts such as [https://www.mediawiki.org/wiki/Transclusion transclusion] are useful in allowing you to collate a publication from many differently authored pages by referring to them in hypertext. Simply put, transclusion is including a part of a document into another one by hypertext reference, rather than copying it. Pages (or parts of them) can be transcluded into another wiki page, as so:
Wikis are great for (a-sync) collaborative writing and editing, which is why the MediaWiki software is a part of wiki-to-print. Alongside this, concepts such as [https://www.mediawiki.org/wiki/Transclusion transclusion] are useful in allowing you to collate a publication from many differently authored pages. Simply put, transclusion is including a document into another one by hypertext reference, rather than copying it. Pages (or parts of them) can be transcluded into another wiki page, in this way:


<code>
<code>
Line 8: Line 9:
</code>
</code>


Wiki-to-print uses the <code>Pdf</code> namespace to make an environment in which PDFs can be written, edited and designed by multiple people simultaneously. After creating a wiki-to-print environment in the <code>Pdf</code> namespace, some useful wiki-to-print features are automatically added that allow you to render a wiki page into a HTML page and PDF document.  
Transclusion is used in wiki-to-print to make one "unfolded" page that loads all the different pages of the PDF. Transclusion allows you to change the order of the texts quickly and add other elements such as a cover page or colophon. Furthermore, transclusion is useful for collaborative editing. Any changes that editors make to transcluded pages will automatically update wherever they are unfolded.


So once you have made a new wiki-to-print environment, a range of <span style="color: magenta; background-color: linear-gradient(to bottom,rgba(167,215,249,0) 0,fuchsia 100%);">pink</span> buttons are added to the navigation bar, which include:
Wiki-to-print uses the <code>Pdf</code> namespace for these unfolded pages. Once you make a new wiki-to-print environment, a range of <span style="color: magenta;">pink</span> wiki-to-print buttons are added to the navigation bar, which add features for creating the layout.
 
Below is a list of the wiki-to-print buttons:


===CSS!===
===CSS!===


Here you can add the style for your print layout.
Here you can add the CSS styling rules for your layout.


The Talk pages in the <code>Pdf</code> namespace are turned into CSS stylesheets for each particular wiki-to-print environment. So, once you have created a new wiki-to-print environment, an empty CSS stylesheet is also made.  
The Talk pages in the <code>Pdf</code> namespace are turned into CSS stylesheets for each particular wiki-to-print environment. So, once you have created a new wiki-to-print environment, an empty CSS stylesheet is made automatically.  


===View HTML===
===Preview HTML===


Here you can inspect the HTML and CSS of your page.
Here you can preview the HTML and CSS of your page.


If you want to preview the content as HTML, you can do this by clicking this button. This can be helpful to do when, for example, something unexpected happened in your layout and you want to figure out what is happening. You can also see the CSS alongside the rendered HTML in the same browser window.
This can be helpful to do when, for example, something unexpected happened in your layout and you want to figure out what is going on.  


===View PDF===
===Preview PDF===


Here you can preview your PDF.
Here you can preview your PDF in a new browser tab.


Clicking this button allows you to preview the content as a PDF in a new browser tab. Here, your content and the page layout you specified in your CSS are rendered by the JavaScript library Paged.js to look like a PDF. If you are satisfied with this, you can export the PDF from this browser tab simply by pressing <code>ctrl/command + p</code>. If you have any problems seeing the layout, it's useful to check that your content and CSS is written correctly by viewing and inspecting how the HTML is rendered.
Your content and the page layout you specified in your CSS are rendered by the JavaScript library Paged.js to look like a PDF. If you are satisfied with this, you can export the PDF from this browser tab simply by pressing <code>ctrl/command + p</code>.


===Update text===
==GOLDEN SWEATY TIPS==


Here you can update your text after making changes.
===CSS===
* Use pixels in your stylesheet, this will (hopefully) avoid some Paged.js quirks that we have been fighting with, see: [[Error_log#Disappearing_sentences]]
* Use a pad to write the CSS and work on it together; you can import the pad using "@import" and the "/export/txt" export function: <code>@import url("https://pad.domainname.ext/mypad/export/txt");</code>
* You can manually force pages to break by creating a class that has the property "page-break-after: always;", and add it to the wiki pages wherever needed
* We often use one div to force extra page breaks: <code><div class="page-break"></div></code> and we copy/paste this when we need to add one
* The wiki adds id's to all the headers, which is super nice because it makes it possible to use Paged.js's target counters: https://pagedjs.org/documentation/-cross-references/#target-counter(); See this page for an example where this is used: https://cc.vvvvvvaria.org/wiki/Pdf:APRJA_Minor_Tech
* It depends on the layout, but often image sizes are best specified one-by-one, rather than globally. We often give exact pixel widths in the image element, for example <nowiki><code>[[File:image.jpeg|thumb|480px|image caption]]</code></nowiki>
* We don't try to go into micro-typography too much, it drives us crazy :) as it exponentially increases the workload
* Footnotes are rendered by the wiki with a small backlink-arrow, which is a super nice feature to keep in the PDF
* Fonts need to be hosted at the same server or domainname, to avoid cross-origin errors


Any changes to text in your wiki-to-print environment (such as in content, or CSS) need to be updated before you can view them in the PDF. This also applies to any pages that are transcluded into your wiki-to-print environment. Clicking this button opens a new browser tab, as a sign that you have now updated the text. You can safely close it afterwards.
===exporting===
* Different browsers (such as Chrome/Chromium, Firefox etc.) render PDFs differently, even if you're using the same version! For final final final versions, proof from PDFs, not from screen!
* Firefox renders images in low quality, the Paged.js developers recommend using Chrome/Chromium
* Your PDF will be saved in RGB, you can convert it to CMYK with Ghostscript. We use OSP's [http://osp.kitchen/tools/pdfutils/ PDFUtils repository]
* Zooming in/out in the browser may lead to suddenly disappearing lines; it's recommended to keep it 100 (percent) when working with Paged.js.
* Paged.js previews the PDF as double-page spreads, but the browser will save it as a single page document. You may also notice some slight differences in resolution and crispness of fonts between the browser and your PDF e-reader


===Update Media===
===docs===
* The Paged.js documentation is pretty good: https://pagedjs.org/documentation/, you can find useful examples for using generated page numbers in toc's and other things
* The Coko Foundation's Mattermost has a dedicated Paged.js channel! You can find the makers and other users of Paged.js there, who may help you out in a pickle: https://mattermost.coko.foundation/coko/channels/pagedjs


Here you can update your text + media after making changes.
===wiki-to-print===
* More than one person editing a wiki page at the same time leads to version conflicts... And one of you loses their edits :|
* It's possible to use the <code>View HTML</code> button to make an HTML page. It's something that changes the scope of wiki-to-"print" into wiki-publishing, which we never tried but think is exciting :)


Any changes to media in your wiki-to-print environment (such as new images you upload) need to be updated before you can view them in the PDF. This also applies to any pages that are transcluded into your wiki-to-print environment. Clicking this button opens a new browser tab, as a sign that you have now updated the media. You can safely close it afterwards.


[[Category:Wiki-to-print]]
[[Category:Wiki-to-print]]

Revision as of 14:56, 22 August 2023

Wiki-to-print is a collaboratively publishing environment in which PDFs can be written, edited and designed by multiple people simultaneously.

Wikis are great for (a-sync) collaborative writing and editing, which is why the MediaWiki software is a part of wiki-to-print. Alongside this, concepts such as transclusion are useful in allowing you to collate a publication from many differently authored pages. Simply put, transclusion is including a document into another one by hypertext reference, rather than copying it. Pages (or parts of them) can be transcluded into another wiki page, in this way:

{{:name of page to be transcluded}}

Transclusion is used in wiki-to-print to make one "unfolded" page that loads all the different pages of the PDF. Transclusion allows you to change the order of the texts quickly and add other elements such as a cover page or colophon. Furthermore, transclusion is useful for collaborative editing. Any changes that editors make to transcluded pages will automatically update wherever they are unfolded.

Wiki-to-print uses the Pdf namespace for these unfolded pages. Once you make a new wiki-to-print environment, a range of pink wiki-to-print buttons are added to the navigation bar, which add features for creating the layout.

Below is a list of the wiki-to-print buttons:

CSS!

Here you can add the CSS styling rules for your layout.

The Talk pages in the Pdf namespace are turned into CSS stylesheets for each particular wiki-to-print environment. So, once you have created a new wiki-to-print environment, an empty CSS stylesheet is made automatically.

Preview HTML

Here you can preview the HTML and CSS of your page.

This can be helpful to do when, for example, something unexpected happened in your layout and you want to figure out what is going on.

Preview PDF

Here you can preview your PDF in a new browser tab.

Your content and the page layout you specified in your CSS are rendered by the JavaScript library Paged.js to look like a PDF. If you are satisfied with this, you can export the PDF from this browser tab simply by pressing ctrl/command + p.

GOLDEN SWEATY TIPS

CSS

  • Use pixels in your stylesheet, this will (hopefully) avoid some Paged.js quirks that we have been fighting with, see: Error_log#Disappearing_sentences
  • Use a pad to write the CSS and work on it together; you can import the pad using "@import" and the "/export/txt" export function: @import url("https://pad.domainname.ext/mypad/export/txt");
  • You can manually force pages to break by creating a class that has the property "page-break-after: always;", and add it to the wiki pages wherever needed
  • We often use one div to force extra page breaks:
    and we copy/paste this when we need to add one
  • The wiki adds id's to all the headers, which is super nice because it makes it possible to use Paged.js's target counters: https://pagedjs.org/documentation/-cross-references/#target-counter(); See this page for an example where this is used: https://cc.vvvvvvaria.org/wiki/Pdf:APRJA_Minor_Tech
  • It depends on the layout, but often image sizes are best specified one-by-one, rather than globally. We often give exact pixel widths in the image element, for example <code>[[File:image.jpeg|thumb|480px|image caption]]</code>
  • We don't try to go into micro-typography too much, it drives us crazy :) as it exponentially increases the workload
  • Footnotes are rendered by the wiki with a small backlink-arrow, which is a super nice feature to keep in the PDF
  • Fonts need to be hosted at the same server or domainname, to avoid cross-origin errors

exporting

  • Different browsers (such as Chrome/Chromium, Firefox etc.) render PDFs differently, even if you're using the same version! For final final final versions, proof from PDFs, not from screen!
  • Firefox renders images in low quality, the Paged.js developers recommend using Chrome/Chromium
  • Your PDF will be saved in RGB, you can convert it to CMYK with Ghostscript. We use OSP's PDFUtils repository
  • Zooming in/out in the browser may lead to suddenly disappearing lines; it's recommended to keep it 100 (percent) when working with Paged.js.
  • Paged.js previews the PDF as double-page spreads, but the browser will save it as a single page document. You may also notice some slight differences in resolution and crispness of fonts between the browser and your PDF e-reader

docs

wiki-to-print

  • More than one person editing a wiki page at the same time leads to version conflicts... And one of you loses their edits :|
  • It's possible to use the View HTML button to make an HTML page. It's something that changes the scope of wiki-to-"print" into wiki-publishing, which we never tried but think is exciting :)