Generating PDF output using Pandoc

.gitbook.md

@@ -16,13 +16,13 @@
 
 `npm run gitbook:serve`
 
-## Generate PDF
+## Generate PDF - option 1
 
 ### Prerequisites
 
 1. Install Calibre: https://calibre-ebook.com/download
 
-2. npm install svgexport -g"
+2. npm install svgexport -g
 
 3. Pre-requisites for node-canvas: https://github.com/Automattic/node-canvas/wiki/_pages
 
@@ -32,13 +32,27 @@
 
 A file `book.pdf` will be generated in the root directory
 
-## Known Issues
+### Known Issues
 
 - `npm install` fails for the `gitbook-pdf` dependency. Here is a work-around: https://github.com/GitbookIO/gitbook-pdf/issues/23
 - removed `"gitbook-pdf": "^0.0.2",` as a dependency from package.json. Please manually install `gitbook-pdf` until the issue can be resolved
 - Export PDF does not contain a 
 
+## Generate PDF - option 2
 
+1. Install Pandoc `brew install pandoc`
+
+2. Verify version `pandoc --version` _requires to be vresion 2.0 or higher_.
+
+3. install pdf engine `brew install Caskroom/cask/wkhtmltopdf`. _Version 0.12.4 or higher_.
+
+4. Acquaint yourself with Pandoc `https://pandoc.org/MANUAL.pdf`
+
+    Also see https://github.com/mszep/pandoc_resume#requirements
+
+5. Run the following to generate the PDF using html5 output `pandoc -t html5 -s {input} -o {output} --pdf-engine=wkhtmltopdf`
+
+    Replace {input} and {output} with the file names.
 ## Docker
 
 ### Build

documents/platform-operating-guideline.md

@@ -4,6 +4,7 @@
     - Author: Carol Coye Benson (Glenbrook), Michael Richards (ModusBox)  
     - Date: October 2019
     - Description: 
+
 ---
 
 ## **About the Mojaloop Community Business Document Project**
@@ -130,18 +131,17 @@ Some rules and operational specifications vary by Use Cases and Secondary Use Ca
 
 The Scheme supports certain Identifiers, or payment addresses, for use in making Transfers. The Identifier identifies the Payee whose Transaction Account is credited for the Transfer. Supported Scheme Identifiers are listed in an Appendix to the Business Rules.
 
-_<ul>For each scheme supported identifier, this document should specify what the identifier is and how it is resolved (how it is determined which Payee DFSP is responsible for the transaction account associated with that identifier.</ul>_
+    _For each scheme supported identifier, this document should specify what the identifier is and how it is resolved (how it is determined which Payee DFSP is responsible for the transaction account associated with that identifier._
 
 #### 1.4.1 Example: The MSISDN Identifier 
 
-_<ul>Each scheme will have its own guidelines for each identifier; the provisions below could vary significantly depending on choices made.</ul>_
+    _Each scheme will have its own guidelines for each identifier; the provisions below could vary significantly depending on choices made._
 
 - MSISDN's are mobile numbers which are globally unique. MSISDN's are the Transaction Account Identifier for DFPSs who are Mobile Network Operators and who are providing Transaction Accounts to their customers.
 
 - Use of the MSISDN as a Payee Identifier is limited to Transaction Accounts provided by DFSPs who are the Mobile Network Operator responsible for that MSISDN.
 
-    _<ul>Note: if MSISDN's are used for other Transaction Accounts, they are
-aliases, and a separate protocol for resolving them must be specified.</ul>_
+    _Note: if MSISDN's are used for other Transaction Accounts, they are aliases, and a separate protocol for resolving them must be specified._
 
 -   A Party Request for an MSISDN is resolved by a MSISDN directory service determined by the Scheme. The Scheme may specify directory service maintenance obligations for Mobile Network Operator DFSPs from time to time.
 
@@ -519,13 +519,13 @@ following sections:_
 
 ## 8. Appendix: Scheme Supported Use Cases and System Parameters
 
-_<ul>This is the same table as appears in the Business Rules document, but it has added the systemic codes necessary for the Platform to recognize a transaction as belonging to a given use case or secondary use case. A scheme would only define Secondary Use Cases if it wanted to write rules and/or specify fees that are unique to that Secondary Use Case</ul>_
+_This is the same table as appears in the Business Rules document, but it has added the systemic codes necessary for the Platform to recognize a transaction as belonging to a given use case or secondary use case. A scheme would only define Secondary Use Cases if it wanted to write rules and/or specify fees that are unique to that Secondary Use Case_
 
-_<ul>This table is an example of a table of Use Cases and Secondary Use Cases that a scheme might support.</ul>_
+_This table is an example of a table of Use Cases and Secondary Use Cases that a scheme might support._
 
 | Use Case Code | Use Case | Secondary User Case | Required Data Elements | Other Methods of Use Case Determination |
-| --- | --- | --- | --- | --- |
-| 1.0 | P2P | Person to Person | API Setting <br>Scenario=Transfer</br> <br>Initiator = Payer</br> <br>Initiator Type = Consumer</br> <br>Recipient Type = Consumer</br> | |
+| :--- | :----- | :--------- | :-------------------------- | :------------------------------------------- |
+| 1.0  | P2P  | Person to Person | API Setting <br>Scenario=Transfer</br> <br>Initiator = Payer</br> <br>Initiator Type = Consumer</br> <br>Recipient Type = Consumer</br> | |
 | 1.1 | P2P | Wallet to wallet | Transaction Account Type for Payer DFSP is Wallet and for Payee DFSP is Wallet |
 | 1.2 | P2P | Bank to bank | Transaction Account Type for Payer DFSP is Bank and for Payee DFSP is Wallet |
 | 1.3 | P2P | Wallet to bank | Transaction Account Type for Payer DFSP is Wallet and for Payee DFSP is Bank |

documents/scheme-business-rules.md

@@ -4,6 +4,7 @@
     - Author: Carol Coye Benson (Glenbrook)
     - Date: October 2019
     - Description:     
+
 ---
 
 ## **About the Mojaloop Community Business Document Project**
@@ -352,7 +353,6 @@ Section Headings and bulleted entries underneath section headings are actual pro
 - The investigation and report, as well as remedies that may be required will be held confidential to the extent permitted by Applicable Law.
 
 ### 8.2 Risk Management Policies
-------------------------
 
 <ul><i>This section assumes that the development of risk management policies by the Scheme and its participants will be evolving. This section contemplates that some of these policies will (eventually) be in the Rules; others will not</i></ul>
 
@@ -436,8 +436,8 @@ Scheme Services include:
 
 <ul><i>A scheme would only define Secondary Use Cases if it wanted to write rules and/or specify fees that are unique to that Secondary Use Case</i></ul>
 
-| | Use Case | Secondary Use Case |
-| --- | -------- | ------------------ |
+|       | Use Case   | Secondary Use Case          |
+| :---: | :--------: | :-------------------------- |
 | 1.0 | P2P | Person to Person |
 | 1.1 | P2P | Wallet to wallet |
 | 1.2 | P2P | Bank to bank |

documents/scheme-key-choices.md

@@ -4,6 +4,7 @@
     - Author: Carol Coye Benson (Glenbrook)
     - Date: October 2019
     - Description: 
+
 ---
 
 ## **About the Mojaloop Community Business Document Project**
@@ -226,15 +227,13 @@ Any scheme implementing credit-push payments needs to specify how the payer and
 
     - A scheme may also use a broadcast method to determine the DFSP responsible for a given payment address ("do you claim this address"), but needs to develop a protocol to manage conflicts if more than one DFSP "claims" the address.
 
-- It is important to note that the resolution method can different for each type of supported payment address. Some supported payment address types may also be accompanied by particular data sets: for
- example, when a payment is being made in payment of an invoice, the payment address may be some type of alias, and that use of that alias may be tied to accompanying invoice data. Dynamic QR codes, as an example, will create a "request to pay" that may contain the scheme-supported merchant ID (an alias) and accompanying transaction data detail.
+- It is important to note that the resolution method can different for each type of supported payment address. Some supported payment address types may also be accompanied by particular data sets: for example, when a payment is being made in payment of an invoice, the payment address may be some type of alias, and that use of that alias may be tied to accompanying invoice data. Dynamic QR codes, as an example, will create a "request to pay" that may contain the scheme-supported merchant ID (an alias) and accompanying transaction data detail.
 
 The Open API specification and the Mojaloop reference code support a wide range of different address types: mobile number, bank account, national ID, aliases ("Quickshop\@abc"), etc.
 
 ### 7.1 L1P Alignment -- Payments Addressing 
 
-Secure, easy payment addressing relates to two important concepts in Level One: convenience for the end-user and "openness". The latter is particularly important to enable competition and rapid scaling of a
-payment system. As schemes (Level One and otherwise) worldwide struggle to determine how to best solve the question of payments addressing, a few best practices appear to be emerging:
+Secure, easy payment addressing relates to two important concepts in Level One: convenience for the end-user and "openness". The latter is particularly important to enable competition and rapid scaling of a payment system. As schemes (Level One and otherwise) worldwide struggle to determine how to best solve the question of payments addressing, a few best practices appear to be emerging:
 
 - Although the use of the mobile number, in particular, as an address has an obvious appeal, there appears to be a trend to use aliases -- identifiers with no additional meaning. This is demonstrated in India with the UPI system and in Australia's new real-time system, where the identifier is referred to as the PAYID.
 

documents/scheme-participation-agreement.md

@@ -4,6 +4,7 @@
     - Author: Carol Coye Benson (Glenbrook) 
     - Date: October 2019
     - Description: 
+
 ---
 
 ## **About the Mojaloop Community Business Document Project**

documents/scheme-uniform-glossary.md

@@ -4,6 +4,7 @@
     - Author: Carol Coye Benson (Glenbrook)
     - Date: October 2019
     - Description: 
+
 ---
 
 ## **About the Mojaloop Community Business Document Project**
@@ -32,8 +33,8 @@ This is a glossary of terms used in the Mojaloop Business Community Document Pro
 
 # Uniform Glossary Template
 
-| **Term** | **Definition** |
-| --- | --- | 
+| Term   | Definition                                                                                      |
+| :----- | :---------------------------------------------------------------------------------------------- | 
 | Access Channel | Places or capabilities that are used to initiate or receive a payment. Access channels can include bank branch offices, ATMs, terminals at the POS, agent outlets, mobile phones, and computers. |
 | Account Lookup | A process that determines the DFSP responsible for a Transaction Account |
 | Account Lookup System | Account Lookup System is an abstract entity used for retrieving information regarding in which FSP an account, wallet or identity is hosted. The Account Lookup System itself can be hosted in its own server, as part of a financial switch, or in the different FSPs. |

package.json

@@ -1,6 +1,6 @@
 {
   "name": "mojaloop-business-docs",
-  "version": "8.5.3",
+  "version": "8.7.0",
   "description": "Mojaloop Business Documentation GitBook Project",
   "dependencies": {
     "express": "4.17.1",