MobileRead Forums - View Single Post - Custom field 'Plain text, not shown in the tag browser', just like 'Title'

chaley · 07-23-2016, 05:09 AM

When I made the suggestion to add other content types I was mainly thinking about images. I can imagine several reasons someone would want an image (other than the cover) displayed in book details and also want that image to travel with the database.

More esoteric possibilities include:

DaltonST's example of the set of covers for a book.
A "zip" to hold the "extras" that sometimes come with books such as sample programs, separate from the "zip" that is the book itself.
Multiple versions of a book.
Multiple files of the same "format" (epub, pdf, etc)
The table of contents of a proceedings containing the paper that is the "book"
Word(-like) files that contain a user's notes.

The reason I suggested base64 is risk reduction. There are many "clients" that look at comments fields: internal calibre, plugins, third party apps, etc. All of these expect to find text that may or may not be HTML. These clients are almost certainly not prepared to handle non-text data, for example images. If they encounter non-text data a very likely outcome is a crash. Base64 results in valid text. Clients may display something strange, but they won't crash. If the developer cares then the client can be changed to do the right thing with the data.

FWIW: I would prefer a single drop down box that is not editable. That box would contain the content types known by calibre at that moment. Plugins could set the content-type to something else. The reason: if there is both a boolean and a content type then code must check both instead of only one. There is the possibility of mistakes where one is set but not the other. Lastly the meaning isn't always clear. Does plain_text == True + content-type == text/plain mean the same thing as plain_text + content-type == empty? Can I set a content type without setting base64?

Also FWIW: base64 is used in lots of current protocols. For example, email is often stored and transmitted in base64. As DaltonST said, base64 is used in HTML, for example in IMG tags with src="data:image/png;base64,...". One finds it in interchange formats such as XML and JSON when there isn't a convenient text representation of the data.

07-23-2016, 05:09 AM	#36
chaley Grand Sorcerer Posts: 12,488 Karma: 8065348 Join Date: Jan 2010 Location: Notts, England Device: Kobo Libra 2	When I made the suggestion to add other content types I was mainly thinking about images. I can imagine several reasons someone would want an image (other than the cover) displayed in book details and also want that image to travel with the database. More esoteric possibilities include: DaltonST's example of the set of covers for a book. A "zip" to hold the "extras" that sometimes come with books such as sample programs, separate from the "zip" that is the book itself. Multiple versions of a book. Multiple files of the same "format" (epub, pdf, etc) The table of contents of a proceedings containing the paper that is the "book" Word(-like) files that contain a user's notes. The reason I suggested base64 is risk reduction. There are many "clients" that look at comments fields: internal calibre, plugins, third party apps, etc. All of these expect to find text that may or may not be HTML. These clients are almost certainly not prepared to handle non-text data, for example images. If they encounter non-text data a very likely outcome is a crash. Base64 results in valid text. Clients may display something strange, but they won't crash. If the developer cares then the client can be changed to do the right thing with the data. FWIW: I would prefer a single drop down box that is not editable. That box would contain the content types known by calibre at that moment. Plugins could set the content-type to something else. The reason: if there is both a boolean and a content type then code must check both instead of only one. There is the possibility of mistakes where one is set but not the other. Lastly the meaning isn't always clear. Does plain_text == True + content-type == text/plain mean the same thing as plain_text + content-type == empty? Can I set a content type without setting base64? Also FWIW: base64 is used in lots of current protocols. For example, email is often stored and transmitted in base64. As DaltonST said, base64 is used in HTML, for example in IMG tags with src="data:image/png;base64,...". One finds it in interchange formats such as XML and JSON when there isn't a convenient text representation of the data.