Generated.

[homepage.git] / blog / UsingQR____Electronic__paper_invoices_using_JSON_and_QR_codes.html

diff --git a/blog/UsingQR____Electronic__paper_invoices_using_JSON_and_QR_codes.html b/blog/UsingQR____Electronic__paper_invoices_using_JSON_and_QR_codes.html
index 2e831ee25f8d6160fe227d92ba7d401ce741fd6f..9b5128f196ee881d65f4b864aa035b2a25ed23a1 100644 (file)
--- a/blog/UsingQR____Electronic__paper_invoices_using_JSON_and_QR_codes.html
+++ b/blog/UsingQR____Electronic__paper_invoices_using_JSON_and_QR_codes.html
@@ -40,7 +40,7 @@ a QR code with the key information of the invoice in JSON format.
 This is the typical content of a QR code following the UsingQR
 specification (based on a real world example, some numbers replaced to
 get a more bogus entry).  I've reformatted the JSON to make it easier
-to read.  Normally this is all on one long line:
+to read.  Normally this is all on one long line:</p>
 
 <p><img src="http://people.skolelinux.org/pere/blog/images/2016-03-19-qr-invoice.png" align="right"><pre>
 {
@@ -86,7 +86,7 @@ risk, but if this happen there is some legal defense in the fact that
 the people behind the format claimed it was safe to do so.  At least
 with patents, there is always
 <a href="http://www.paperspecs.com/paper-news/beware-the-qr-code-patent-trap/">a
-chance of getting sued...</a>
+chance of getting sued...</a></p>
 
 <p>I also asked if they planned to maintain the format in an
 independent standard organization to give others more confidence that